BLOCKCHAIN SYSTEMS AND METHODS FOR REMOTE MONITORING

Abstract

Methods and systems are provided to generate and obtain data from mobile medical devices such as nebulizers and mobile monitors such as pacemakers and to store provenance parameters for the data in a distributed ledger for use in verifying the source and accuracy of the data. The methods and systems may further be used to reduce readmittance rates at healthcare facilities.

Claims

1-27. (canceled)

28. A system for remote management of patient compliance, comprising: a mobile medical device, comprising: i) a processor; ii) a non-transitory computer readable memory in communication with the processor; iii) a data source in communication with the processor; iv) a reference to predetermined network coordinates stored in the memory; v) use instructions for treating a medical condition stored in the memory, and vi) program code stored in the memory, the program code executable by the processor to perform data communication operations, the data communication operations comprising: a) processing signals from the data source to obtain device data; b) inserting dual payloads and device signatures applied to the dual payloads into network packets, first payloads of the dual payloads comprising at least portions of the device data, second payloads of the dual payloads comprising hashes of the at least portions of the device data and device signatures applied to the hashes; and c) pushing the network packets to the predetermined network coordinates in response to internally-generated prompts.

29. The system of claim 28, wherein the system further comprises: a computing infrastructure comprising: i) the predetermined network coordinates; ii) a privacy-compliant database configured to receive the device data; and iii) a list of public keys containing a public key for the mobile medical device, the public key for the mobile medical device effective to recover the hashes from the device signatures applied to the hashes; and iv) at least one access point for communication with a distributed ledger network, the at least access point configured to push instructions to a distributed ledger to add the hashes to the distributed ledger without any patient identification information.

30. The system of claim 29, the computing infrastructure further comprising program code stored in a non-transitory computer readable memory, the program code executable by a processor to perform remote monitoring of the device data received by the privacy-compliant database.

31. The system of claim 30, wherein the remote monitoring comprises: adjusting a schedule for one or more of the pulling, downloading, and processing if the determined risk of readmission exceeds a first threshold; and optionally triggering an intervention protocol if the determined risk of readmission exceeds a second threshold.

32. The system of claim 30, wherein the remotely monitoring further comprises: a) pulling the hash and the device signature applied to the hash from the distributed ledger; b) authenticating the hash by recovering the hash from at least the device signature applied to the hash; c) verifying the accuracy of the downloaded at least a portion of the device data against the pulled hash; and d) processing the at least a portion of the device data in combination with the use instructions to obtain the at least one patient compliance parameter.

33. The system of claim 32, wherein the at least one patient compliance parameter comprises a measure of patient compliance with the use instructions.

34. The system of claim 33, wherein the at least one patient compliance parameter comprises: a measure of patient non-compliance with the use instructions, a cumulative number of missed treatments by the mobile medical device, a cumulative quantity of medication dispensed by the mobile medical device, a probability of readmission of the patient to a healthcare facility to treat the medical condition, an estimate of an excess readmission rate, or any combination thereof.

35. The system of claim 28, wherein the dual payloads are recovered from the device signatures applied to the dual payloads using a public key.

36. The system of claim 35, wherein the public key is created by a manufacturer of the mobile medical device.

37. The system of claim 28, wherein the mobile medical device further comprises a private key embedded in an onboard key signing chip.

38. The system of claim 37, wherein the communication operations further comprise using the private key to generate the device signatures applied to the hashes.

39. The system of claim 28, wherein the second payloads contains no patient identification information.

40. The system of claim 28, wherein the second payload comprises one or more instructions for inserting the hash into a distributed ledger.

41. The system of claim 40, wherein the one or more instructions are recovered from the device signature applied to the hash.

42. The system of claim 29, wherein the computing infrastructure further comprises: i) a further processor; ii) a private key; and iii) instructions executable by the further processor to use the private key to generate digital signatures applied to the device signatures applied to the hashes.

43. The system of claim 42, wherein the mobile medical device comprises a key signing chip that generates the private key.

44. The system of claim 28, wherein the device data comprises a log of mobile medical device usage data including one or more of time-of-use, frequency of use, and use-duration data for the mobile medical device.

45. The system of claim 44, wherein the log of mobile medical device usage data comprises at least one of time, duration, and frequency of usage of the mobile medical device.

46. The system of claim 28, wherein a first threshold is triggered when the log of mobile medical device usage indicates non-compliant usage, lack of usage, and/or overusage of the mobile medical device by the intended user.

47. The system of claim 28, comprising further mobile medical devices that are drug delivery devices, wherein the mobile medical device gathers and transmit data from the further mobile medical devices.

48. The system of claim 28, wherein the mobile medical device comprises a sensor or a dispenser.

49. The system of claim 48, wherein the mobile medical device comprises a mechanical actuator.

50. The system of claim 49, wherein the mechanical actuator is configured for operation by the patient.

51. The system of claim 28, wherein the mobile medical device is a nebulizer.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0158] FIG. 1: A schematic illustration of processing a dual payload from a data source.

[0159] FIG. 2: A schematic illustration of mobile device registration.

[0160] FIG. 3: A schematic illustration remote patient compliance monitoring incorporating dual payload processing and a distributed ledger.

[0161] FIG. 4: A schematic illustration remote patient compliance monitoring incorporating dual payload processing, a distributed ledger and a compliance reporting service.

[0162] FIG. 5: A schematic illustration remote patient compliance monitoring.

[0163] FIG. 6: A schematic illustration remote patient compliance monitoring incorporating a distributed ledger.

[0164] FIG. 7: A schematic illustration remote patient compliance monitoring incorporating a distributed ledger and a compliance reporting service.

[0165] FIG. 8: Schematic view of a blockchain having a starting block and a series of transactional blocks.

[0166] FIG. 9: Schematic view of a blockchain being assembled.

[0167] FIG. 10: Schematic view of a distributed ledger ecosystem.

DETAILED DESCRIPTION

[0168] In the description herein, the US Health Insurance Portability and Accountability Act (HIPAA)-compliant databases and frameworks are described as exemplary privacy-complant databases. However, the invention is not limited to HIPPA-compliant databases, but, rather, can be applied to any privacy-compliant databases, such as Europe's General Data Protection Regulations (GDPR), Japan's Act on the Protection of Personal In-formation (APPI), Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), Austrailia's Privacy Act 1988, and the like.

[0169] A schematic illustration of a framework (for example a HIPAA-compliant framework) for storing data and data provenance parameters is shown in FIG. 1. A data source 100 pushes a network packet 102 to a server 104, the network packet 102 comprising a header 106 with destination coordinates for the server 104, a dual payload 108 and a digital signature 110 applied to the dual payload 108. The dual payload 108 includes: a first payload 112 comprising de-identified (or anonymous or device-identified) data without any personal identification information, and a second payload 114 comprising a message containing a hash of the de-identified (or anonymous or device-identified) data, wherein the message is a set of instructions recognizable by a distributed ledger network 116 to encode the hash in a distributed ledger. Following receipt of the network packet 102 by the server 104, the server 104 verifies the digital signature by verifying that a public key for the data source is present in a proprietary list 118 of public keys assigned to authorized data sources, extracts the de-identified (or anonymous or device-identified) data and the message from the dual payload 108, inserts the de-identified (or anonymous or device-identified) data into a HIPAA-compliant database 120, and pushes the message (without any patient identification information) to a peer 122 of the distributed ledger network 116.

[0170] The data source 100 may be a mobile medical device, for example a hand-held nebulizer equipped with a cellular radio. The mobile medical device may comprise a processor, a memory, one or more private cryptographic keys, and necessary program code in order to compute the hash and the digital signature, and to form the network packet. The network packet 102 may traverse one or more of a cellular network, the public Internet, and an enterprise network to reach the server. The data source 100 and the server 104 may negotiate a network connection for communication of the network packet. The network connection may comprise one or more of a Transmission Control Protocol (TCP) connection, a User Datagram Protocol (UDP) connection, a Bluetooth connection, a Wi-Fi connection, a cellular network connection, or a connection according to a different network protocol. The network connection may be encrypted, for example the connection may be encrypted according to Transport Layer Security (TLS) protocol. The network packet 102 may comprise additional headers to enable transport according to one or more protocol for navigating one or more of a cellular network, the public Internet, and an enterprise network to reach the server. The proprietary list of public keys 116 may specify public keys for data sources that have been registered by one or more patients who have provided an executed HIPAA release form and a registration code for the data source 100. The message may contain a digital signature provided by the data source 100 and required by the distributed ledger network 116. One or more of the server 104, the database 120, the peer 122 of the distributed ledger network, and the entire distributed ledger network 116 may be contained in one or more enterprise networks (for example one enterprise network). The digital ledger network 116 may be a private distributed ledger. The digital ledger network 116 may be a public distributed ledger. The peer 122 may execute a smart contract in response to receiving the message.

[0171] FIG. 1 describes certain exemplary embodiments, but other variations fall within scope of the disclosure. In certain embodiments, for example, the server 104 may provide an additional digital signature to authorize the digital ledger network 116 to encode the hash. In certain embodiments, for example, the network packet 102 may be exclusive of the digital signature 110 applied to the dual payload 108 and the verification of the of the digital signature 110 may not be performed.

[0172] Certain embodiments (for example the embodiment disclosed in FIG. 1) may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a mobile medical device. In certain embodiments, for example, the mobile medical device may be a nebulizer. In certain embodiments, for example, the nebulizer may be configured to nebulize a therapeutically effective unit dose of a medication (for example a medication for treatment of COPD or asthma). In certain embodiments, for example, the nebulizer may be an air-driven jet nebulizer (for example a nebulizer connected to an air compressor such as a Pari LC Jet Plus Nebulizer connected to a Pari Master or a Pari VIOS compressor). In certain embodiments, for example, the nebulizer may be a vibrating mesh nebulizer. In certain embodiments, for example, the vibrating mesh nebulizer may be handheld. In certain embodiments, for example, the vibrating mesh nebulizer may comprise a removable and/or disposable medicine cup. In certain embodiments, for example, the nebulizer may be a hand-held, battery-powered nebulizer (for example a hand-held, battery powered, vibrating mesh nebulizer). In certain embodiments, for example, the vibrating mesh nebulizer may nebulize all but no more than 0.05 mL of the sterile nebulization solution (for example, the vibrating mesh nebulizer may retain less than 0.05 mL residual sterile nebulization solution following administration of the therapeutically effective dosage regimen), for example all but no more than 0.02 mL of the sterile nebulization solution. In certain embodiments, for example, the nebulizer may be an ultrasonic nebulizer. In certain embodiments, for example, the nebulizer may be a breath-actuated nebulizer. In certain embodiments, for example, mobile medical device may inhaler. In certain embodiments, for example, the inhaler may be an actuated droplet inhaler (for example a Respimat inhaler). In certain further embodiments, for example, the inhaler may comprise a 4.5 mL plastic container crimped into an aluminum cylinder.

[0173] In certain embodiments, for example, the mobile medical device may be a continuous positive airway pressure (CPAP) device. In certain embodiments, for example, the mobile medical device may be a bilevel positive airway pressure device. In certain embodiments, for example, the mobile medical device may be a glucometer. In certain embodiments, for example, the mobile medical device may be a pulse oximeter. In certain embodiments, for example, the mobile medical device may be an oxygen delivery system. In certain embodiments, for example, the mobile medical device may be a blood pressure monitor/cuff.

[0174] Certain embodiments (for example the embodiment disclosed in FIG. 1) may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a digital signature. In certain embodiments, for example, the digital signature for a message (for example a message comprising data) may be obtained as the output of a signing algorithm that has received the message and a cryptographic private key as inputs. In certain embodiments, for example, the message may be authenticated, or the digital signature may be verified, by verifying the digital signature applied to the message (for example by recovering the message from the digital signature (or, equivalently, by verifying the authenticity of the message) by inputting the message, the digital signature, and a cryptographic public key through one or more signature verifying algorithms). In certain embodiments, for example, the signing algorithm and the signature verifying algorithm may be selected from the group consisting of an RSA (Rivest-Shamir-Adleman)-based signature scheme (for example RSA-PSS (Probabilistic Signature Scheme), the Digital Signature Algorithm (DSA), the Elliptic Curve DSA (ECDSA), the Edwards-curve Digital Signature Algorithm, Ed25519, the ElGamal signature scheme, the Schnorr signature algorithm, the Pointcheval-Stern signature algorithm, the Rabin signature algorithm, a pairing-based algorithm (for example, the Boneh-Lynn-Shacham signature scheme), and an aggregate signature algorithm. In certain embodiments, for example, the cryptographic public key is generated with the cryptographic public key using a key generation algorithm.

[0175] Certain embodiments (for example the embodiment disclosed in FIG. 1) may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a hash (or, equivalently, hashed value). In certain embodiments, for example, the hashed value may be obtained by passing data through a hashing algorithm. In certain embodiments, for example, the hashing algorithm may be selected from the group consisting of BLAKE-256, BLAKE-512, BLAKE2s, BLAKE2b, Elliptic Curve Only Hash (ECOH), the Fast Syndrome-based (FSB) hash, GOST, Grostl, HAS-160, HAVAL, JH, the Message Digent-2 (MD2) algorithm, MD4, MD5, MD6, RadioGatún, the RACE Integrity Primitives Evaluation Message Digest (RIPEMD), RIPEMD-128, RIPEMD-160, RIPEMD-320, the Secure Hash Algorithm-1 (SHA-1), SHA-2, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral Hash, Streebog, SWIFFT, Tiger, Whirlpool-0, Whirlpool-T, and Whirlpool.

[0176] Certain embodiments (for example the embodiment disclosed in FIG. 1) may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a distributed ledger, subcomponents and/or ancillary components of a distributed ledger, communications to/from a distributed ledger, smart contracts operating in an ecosystem comprising the distributed ledger, and/or optional distributed ledger applications (for example a wallet such as a mobile wallet). A distributed ledger is a distributed database that maintains information, e.g., a list of data records, computer program code (for example an executable program such as a smart contract), etc. In certain embodiments, for example, the information may comprise financial information, such as a designated portion of one or more financial accounts. The security of the information maintained within a distributed ledger may be enhanced by the fact that the ledger is distributed across plural nodes, which nodes may be one or more systems, machines, computers, databases, data stores or the like operably connected with one another. In certain embodiments, for example, each of the nodes or multiple nodes may be maintained by different entities. A distributed ledger may works without a central repository or single administrator. One well-known application of a distributed ledger is the public ledger of transactions for cryptocurrencies such as used in Bitcoin. In the case of Bitcoin, the data records recorded in the distributed ledger are enforced cryptographically and stored on the nodes of the distributed ledger.

[0177] In certain embodiments, for example, a distributed ledger may provide a number of advantages over traditional databases. In certain embodiments, for example, information may be added to the distributed ledger in blocks, wherein the blocks are added in an ordered sequence (or chain). In certain embodiments, for example, the chain of blocks (i.e., the blockchain) may be maintained to provide a history of the information added to the distributed ledger. In certain embodiments, for example, each added block may store a reproducible signature (for example a hash) indicative of a previous state of the blockchain, whereby any alteration of information in a previously-added block in the blockchain will be detected because the resulting signatures in subsequent blocks would not match previously stored signatures. In certain embodiments, for example, records in the distributed ledger may secure trusted data by hashing the data into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.

[0178] In certain embodiments, for example, plural nodes hosting the distributed ledger may reach a consensus regarding the validity of information maintained with a block of the blockchain, e.g., a transaction contained on a transaction ledger, financial information or the like. Additionally, when multiple versions of information exist on the ledger, multiple nodes can converge on the most up-to-date version of the transaction. For example, in the case of a virtual currency transaction, any node within the distributed ledger that creates a transaction can determine within a level of certainty whether the transaction can take place and become final by confirming that no conflicting transactions (i.e., the same currency unit has not already been spent) confirmed by the distributed ledger elsewhere.

[0179] In certain embodiments, for example, a distributed ledger may comprise two types of records. The first type of record is the information type, which consists of the actual data stored in the distributed ledger. The second type of record is the block type, which confirms when and in what sequence certain information became recorded as part of the distributed ledger. In certain embodiments, for example, information may be created by participants using the distributed ledger in the normal course of business, for example, when someone sends a resource to another person. In certain embodiments, for example, blocks are created by users known as “miners” who use specialized software/equipment to create blocks. In certain embodiments, for example, nodes in possession of a block of the distributed ledger may communicate with other nodes to validate added information based on a set of rules that are defined by the particular system implementing the distributed ledger. For example, in the case of financial information, such as cryptocurrencies or the like, valid information may be digitally signed, conducted from a valid digital wallet and, in some cases, meet other criteria.

[0180] In certain embodiments, for example, a distributed ledger may be decentralized—meaning that a distributed ledger is maintained on multiple nodes of the distributed ledger. One node in the distributed ledger may have a complete or partial copy of the entire ledger or set of information and/or blocks on the distributed ledger. Transactions may be initiated at a node of a distributed ledger and communicated to the various other nodes of the distributed ledger. Any of the nodes can validate information, add the information to its copy of the distributed ledger, and/or broadcast the information, its validation (in the form of a block) and/or other data to other nodes. This other data may include time-stamping, such as is used in financial resource distributed ledgers. Various other specific-purpose implementations of distributed ledgers have been developed. These include distributed domain name management, decentralized crowd-funding, synchronous/asynchronous communication, decentralized real-time ride sharing and even a general purpose deployment of decentralized applications.

[0181] In certain embodiments, for example, the distributed ledger may be public (for example a distributed ledger like Bitcoin, Litecoin, Ethereum, Zcash, Monero, Dash, Litecoin, Dodgecoin, or Hyperledger). In certain embodiments, for example, the distributed ledger may be private (for example a distributed ledger like Bankchain, MONAX, or Multichain). In certain embodiments, for example, the ledger may be permissionless (for example a ledger like blockchain). In certain embodiments, for example, the ledger may be permissioned (for example like Hyperledger, Kaleido, or PBFT). In certain embodiments, for example, the distributed ledger may be a consortium distributed ledger (for example a ledger like R3, EWF, B3i, or Corda).

[0182] In certain embodiments, for example, the distributed ledger may be an open-source distributed computing platform. In certain embodiments, for example, the distributed ledger may be a blockchain-based distributed computing platform and operating system. In certain embodiments, for example, the distributed ledger may utilize scripting functionality. In certain embodiments, for example, the distributed ledger may utilize smart contract functionality. In certain embodiments, for example, the distributed ledger may support a modified version of Nakamoto consensus via transaction-based state. In certain embodiments, for example, the distributed ledger may be an open-source, public, blockchain-based distributed computing platform and operating system utilizing smart contract functionality, and support a modified version of Nakamoto consensus via transaction-based state transitions (for example Ethereum).

[0183] Certain embodiments (for example the embodiment disclosed in FIG. 1) may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a database. In certain embodiments, for example, the database may be a relational database. In certain embodiments, for example, the database may be an Oracle database. In certain embodiments, for example, the database may be a MySQL database. In certain embodiments, for example, the database may be a Microsoft SQLServer database. In certain embodiments, for example, the database may be a PostgreSQL database. In certain embodiments, for example, the database may be a DB2 database. In certain embodiments, for example, the database may be a non-relational database. In certain embodiments, for example, the database may be a key-value store (for example Redis or Amazon DynamoDB). In certain embodiments, for example, the database may be a wide column store (for example Cassandra, Scylla, or HBase). In certain embodiments, for example, the database may be a document store (for example MongoDB or Couchbase). In certain embodiments, for example, the database may be a graph database (for example Neo4J or Datastax Enterprise Graph). In certain embodiments, for example, the database may comprise a search engine (for example Elasticsearch, Splunk, or Solr). In certain embodiments, for example, the data source (for example a mobile medical device) may comprise one of the foregoing types of databases in the memory to store the generated data.

[0184] Certain embodiments (for example the embodiment disclosed in FIG. 1) may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a network connection. In certain embodiments, for example, the network connection may be configured according to X10, Ethernet, RS-485, 6LoWPAN, Bluetooth LE (BLE), ZigBee, Z-Wave, or two or more of the foregoing protocol. In certain embodiments, for example, the network connection may utilize a cellular protocol, for example 3G, 4G, 4GLTE, 5G, or 6G.

[0185] Certain embodiments may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a data protocol used in transmission of data. In certain embodiments, for example, the data protocol may be used in transmission of data (for example device data, hash data, or messages configured for delivery to a distributed ledger network) from a data source (for example a mobile medical device) to a server. In certain embodiments, for example, the data protocol may be used in transmission of data (for example device data) from the server to a database. In certain embodiments, for example, the data protocol may be used in transmission of data (for messages configured for delivery to a distributed ledger network) from a server to a peer in a distributed ledger network. In certain embodiments, for example, the data protocol may be a machine-to-machine protocol. In certain embodiments, for example, the data protocol may be an Internet of Things (IoT) protocol. In certain embodiments, for example, the data protocol may comprise an MQ Telemetry Transport (MQTT) protocol. In certain embodiments, for example, the data protocol may comprise an Advanced Message Queuing Protocol (AMQP). In certain embodiments, for example, the data protocol may comprise a Simple/Streaming Text Oriented Messaging Protocol (STOMP). In certain embodiments, for example, the data protocol may comprise a Data Distribution Service DDS. In certain embodiments, for example, the data protocol may comprise a Constrained Application Protocol (CoAP). In certain embodiments, for example, the data protocol may comprise an Open Platform Communications Unified Architecture (OPC UA) protocol. In certain embodiments, for example, the data protocol may comprise a Java Message Service (JMS) protocol. In certain embodiments, for example, the data protocol may comprise an eXtensible Messaging and Presence Protocol (XMPP). In certain embodiments, for example, the data protocol may comprise a Representational State Transfer (REST) protocol. In certain embodiments, for example, the data protocol may comprise an Open Mobile Alliance Light Weight Machine-to-Machine (OMA LWM2M) protocol. In certain embodiments, for example, the data protocol may comprise a JavaScript Object Notation (JSON) protocol. In certain embodiments, for example, the data protocol may comprise a Simple Network Management Protocol (SNMP). In certain embodiments, for example, the data protocol may comprise a protocol conforming to Technical Report 069: CPE WAN Management Protocol (TR-069-CWMP). In certain embodiments, for example, the data protocol may conform to a Health Level 7 (HL7) specification. In certain embodiments, for example, the data protocol may conform to a Fast Healthcare Interoperability Resources (FHIR) specification. In certain embodiments, for example, the data protocol may conform to Continua Design Guidelines (CDG). In certain embodiments, for example, the data protocol may comprise Hypertext Transfer Protocol (HTTP). In certain embodiments, for example, the data protocol may conform to the Alljoyn framework. In certain embodiments, for example, the data protocol may comprise Modbus protocol (for example Modbus over TCP and UDP). In certain embodiments, for example, the data protocol may conform to VITA 49 radio transport packet specification. In certain embodiments, for example, the data protocol may conform to Edgent protocol. In certain embodiments, for example, the data protocol may comprise a file transfer protocol. In certain embodiments, for example, the data protocol may comprise a domain name server protocol. In certain embodiments, for example, the data protocol may comprise an Internet Control Message Protocol (ICMP). In certain embodiments, for example, the data protocol may comprise a structured query language protocol. In certain embodiments, for example, the data protocol may comprise a publish-subscribe messaging pattern protocol. In certain embodiments, for example, the data protocol may comprise a data distribution service protocol. In certain embodiments, for example, the data protocol may comprise a data structure identifier. In certain embodiments, for example, the data protocol may comprise a data topic. In certain embodiments, for example, the data protocol may comprise a data type (for example “string”, “integer”, “unsigned integer”, “Boolean”, “floating point”, “double precision”, etc.). In certain embodiments, for example, the data protocol may indicate an allowed range (for example a continuous range or a list of allowed values) of values for a data payload. In certain embodiments, for example, the data protocol may comprise a data definition identifier.

[0186] Certain embodiments may provide, for example, a method, a system, a product (for example a computer program product), a distributed system (for example a distributed computer program), software, middleware, computing infrastructure and/or apparatus (or a combination of two or more of the foregoing) comprising a command syntax, command type, and/or command type identifier accompanying transmitted data (for example a packet of data sent to a database may be accompanied by a command instructing the database how to format or operate on the data). In certain embodiments, for example, the command type may comprise a SQL command and/or statement, for example the command type may comprise SQLread, SQLwrite, AND/OR, ALTER TABLE, AS (alias), BETWEEN, CREATE DATABASE, CREATE TABLE, CREATE INDEX, CREATE VIEW, DELETE, DROP DATABASE, DROP INDEX, DROP TABLE, EXISTS, GROUP BY, HAVING, IN, INSERT INTO, INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN, LIKE, ORDER BY, SELECT, SELECT *, SELECT DISTINCT, SELECT INTO, SELECT TOP, TRUNCATE TABLE, UNION, UNION ALL, UPDATE, WHERE, or a combination of two or more of the foregoing commands. In certain embodiments, for example, the command type may comprise a DNS command, for example the command type may comprise ipconfig, trace route, netstat, arp, route, hostname, control netconnections, or a combination of two or more of the foregoing commands. In certain embodiments, for example, the command type may comprise an FTP command, for example the command type may comprise !, $, ?, account, append, ascii, beep, binary, bye, case, cd, cdup, chmod, close, cr, debug, delete, dir, disconnect, exit, form, get, glob, hash, help, idle, image, ipany, ipv4, ipv6, lcd, ls, macdef, mdelete, mdir, mget, mkdir, mls, mode, modtime, mput, newer, nlist, nmap, ntrans, open, passive, prompt, proxy, put, pwd, qc, quit, quote, recv, reget, rename, reset, restart, rhelp, rmdir, rstatus, runique, send, sendport, site, size, status, struct, sunique, system, tenex, tick, trace, type, umask, user, verbose, or a combination of two or more of the foregoing commands. In certain embodiments, for example, the command type may comprise a Telnet, an Rlogin, an Rsh, or a Secure Shell command. In certain embodiments, for example, the command type may comprise an ICMP command, for example the command type may comprise PING, TRACEROUTE, ICMP PERMIT, ICMP DENY, or a combination of two or more of the foregoing commands. In certain embodiments, for example, the command type may comprise an MQTT command. In certain embodiments, for example, the command type may be a function call. In certain embodiments, for example, the function call may be a call to or from a smart contract. In certain embodiments, for example, the function call may be signed.

[0187] A schematic illustration of an approach to device registration to support subsequent data collection for use compliance monitoring is shown in FIG. 2. A mobile device manufacturer 200 manufactures a mobile device 202 and pre-populates an identification code for the device 202 in a device database 204, and ships the device 202 which ends up in inventory (shown by dashed lines) at a healthcare facility 206. At a future point in time, the device 202 is assigned to a patient 208, and the healthcare facility 206 assists the patient 208 to register the device 202 with the manufacturer by a computer 210 accessing a first Internet portal 212. Registration includes providing patient identification and contact information, a device registration code which references the device identification code, and a HIPAA release form executed by the patient 208. The device registration code may be located on the device 202, for example on a sticker affixed to the outside of the device 202. The registration code may be scannable by a digital scanner connected (not shown) to the computer 210. In a further action, the healthcare facility 206 may submit a request via the computer 210 (or another computer) to a second Internet portal 214 for access to data generated by the device 202, and the request will be submitted to the patient 208 for approval. The communication to the patient 208 and the approval by the patient 208 to grant access (or refusal to grant access) may be electronic (for example a text message or an email) If the request is approved, access credentials are sent from the second Internet portal 214 to the computer 210 and the second Internet portal 214 updates the device database 204 with the credentials. A record may be written to the smart contract indicating grant, refusal, or revocation of the access. The computer 210 sends instructions to append the identification code for the device 202, identification information for the patient, and patient-specific operating instructions for the device 202 to a HIPPA-compliant electronic health record database 216. The patient leaves the healthcare facility 206 with the mobile device 202.

[0188] A schematic illustration of an approach to remote patient compliance monitoring incorporating a distributed ledger is depicted in FIG. 3. An operator (for example an intended patient who has been assigned a mobile device) activates a mobile device 300 for a period of time on each of 3 separate occasions (the number of occasions is dictated by operating instructions provided to an intended patient and the number “3” is selected for illustration purposes only—any number of occasions, including one occasion or more than three occasions, is contemplated herein) by engaging an activation component 302 (for example a button) on the device 300. In response, on each of the 3 occasions an operating component 304 of the device 300 generates operating data and a processor 306 of the device 300 executes instructions to cause the operating data to be stored in a memory 308 of the device 300. Next, a cellular radio 310 of the device 300 detects a cellular network 312 and, following detection of the cellular network 312, the processor 306 executes instructions to form and transmit a network packet. The formed network packet comprises a header with destination coordinates for a first server 314 and a dual payload. The dual payload includes: a first payload comprising at least a portion of the stored operating data and a device identification code, and a second payload comprising a message containing a hash of the at least a portion of the stored operating data, and a digital signature of the device 300 applied to the hash, wherein the message is a set of instructions recognizable by a distributed ledger network 316 to encode the hash in a distributed ledger. The network packet is transferred via the cellular radio 310 to the cellular network 312. After traversing a portion of the cellular network the network packet is passed to a packet-switched network 318 (for example the public Internet) and routed to the first server 314. Following receipt of the network packet by the first server 314, first server 314 verifies the digital signature by passing a public key associated with the device identification code (for example the public key may be the device identification code), the digital signature, and the hash through one or more signature verifying functions, verifying that the public key is present in a proprietary list 320 of public keys assigned to authorized devices, extracts the operating data and the message from the dual payload, inserts the operating data into a HIPAA-compliant database 322, and pushes the message (without any patient identification information) to a peer 324 of the distributed ledger network 316. The processor 306 may execute instructions to encrypt the operating data before the operating data is stored in the memory 308, or the processor 306 may execute instructions to encrypt the operating data before it is transmitted to the cellular network 312. Communications via the cellular network and the packet-switched network may be encrypted or otherwise secured (for example by transport layer security between the device 300 and the first server 314.

[0189] The distributed ledger 316 may be a private ledger or a public ledger such as Ethereum configured to provide an immutable record of the time series data by storing a reference to the addition of the hash to an immutability construct such as a block in a blockchain The first server 314 may be a secure server that is purpose-configured to receive data exclusively from predetermined devices based on a pre-populated list of device identification codes and/or proprietary list 320 of public keys, with write access to the device database 322 otherwise strictly limited to predetermined administrative functions (for example, pre-populating device identification codes), and data export from the device database 322 may be limited to predefined internal report generation and requests from authorized third parties via a second server 326.

[0190] Remote compliance monitoring of an intended patient's use of the mobile device 300 comprises (a) using a compliance device 328 (for example a computer at a healthcare facility 330) to obtain the device identification code and access credentials for a patient from a HIPPA-compliant EHR database 332, (b) supplying a data request with access credentials to the second server 326 to obtain time series of operating data, (c) verifying access (for example by a smart contract) by confirming the access credentials are present on a list of valid access credentials, and (d) obtaining one or more hashes of the time series of operating data from a peer 334 (for example a peer assigned to the healthcare facility 330) in the distributed ledger network 316. The time series of operating data are run through a hash function on the compliance device 328 and the results are confirmed to match the one or more hashes obtained from the distributed ledger network 316. Upon confirmation, the compliance device 328 compares the time series of operating data with the operating instructions for the intended user and determines whether the course of use of the mobile device 300 complies with the instructions. If the use is non-compliant and a risk is detected that exceeds a predetermined threshold, remote compliance monitoring may trigger communication with the intended patient, for example to provide updated instructions for operating the device 300.

[0191] FIG. 3 describes certain exemplary embodiments, but other variations fall within scope of the disclosure. In certain embodiments, for example, the remote compliance monitoring may be performed at a different location from the healthcare facility 330. Certain embodiments, for example, may combine portions or all of FIG. 1, FIG. 2, and/or FIG. 3.

[0192] A schematic illustration of an approach to remote patient compliance monitoring incorporating a distributed ledger and a compliance reporting service is depicted in FIG. 4. An operator (for example an intended patient who has been assigned a mobile device) activates a mobile device 300 for a period of time on each of 3 separate occasions (the number of occasions is dictated by operating instructions provided to an intended patient and the number “3” is selected for illustration purposes only—any number of occasions, including one occasion or more than three occasions, is contemplated herein) by engaging an activation component 302 (for example a button) on the device 300. In response, on each of the 3 occasions an operating component 304 of the device 300 generates operating data and a processor 306 of the device 300 executes instructions to cause the operating data to be stored in a memory 308 of the device 300. Next, a cellular radio 310 of the device 300 detects a cellular network 312 and, following detection of the cellular network 312, the processor 306 executes instructions to form and transmit a network packet. The formed network packet comprises a header with destination coordinates for a first server 314 and a dual payload. The dual payload includes: a first payload comprising at least a portion of the stored operating data and a device identification code, and a second payload comprising a message containing a hash of the at least a portion of the stored operating data, and a digital signature of the device 300 applied to the hash, wherein the message is a set of instructions recognizable by a distributed ledger network 316 to encode the hash in a distributed ledger. The network packet is transferred via the cellular radio 310 to the cellular network 312. After traversing a portion of the cellular network the network packet is passed to a packet-switched network 318 (for example the public Internet) and routed to the first server 314. Following receipt of the network packet by the first server 314, first server 314 verifies the digital signature by passing a public key associated with the device identification code (for example the public key may be the device identification code), the digital signature, and the hash through one or more signature verifying functions, verifying that the public key is present in a proprietary list 320 of public keys assigned to authorized devices, extracts the operating data and the message from the dual payload, inserts the operating data into a HIPAA-compliant database 322, and pushes the message (without any patient identification information) to a peer 324 of the distributed ledger network 316. The processor 306 may execute instructions to encrypt the operating data before the operating data is stored in the memory 308, or the processor 306 may execute instructions to encrypt the operating data before it is transmitted to the cellular network 312.

[0193] Remote compliance monitoring of an intended patient's use of the mobile device 300 comprises a compliance service 400 (a) using a compliance device 328 (for example a computer at a healthcare facility 330) to obtain the device identification code and access credentials for a patient from a HIPPA-compliant EHR database 332, (b) supplying a data request with access credentials to the second server 326 to obtain the time series of operating data, (c) verifying access (for example by a smart contract) by confirming the access credentials are present on a list of valid access credentials, and (d) obtaining the recorded hash of the operating data from a peer 334 (for example a peer assigned to the healthcare facility 330) in the distributed ledger network 316. The time series is run through a hash function on the compliance device 328 and the result is confirmed to match the hash obtained from the distributed ledger network 316. Upon confirmation, the compliance service 400 compares the time series of operating data with the operating instructions for the intended user and generates a report which is transmitted to the compliance device 328 where it is utilized to perform the remote compliance monitoring to determine whether the course of use of the mobile device 300 complies with the instructions. If the use is non-compliant (for example the use comprises over-use or underuse) and a risk is detected that exceeds a predetermined threshold (for example over-use indicates a risk of disease deterioration), remote compliance monitoring may trigger communication with the intended patient, for example to provide updated instructions for operating the device 300.

[0194] A schematic illustration of an approach to remote patient compliance monitoring is depicted in FIG. 5. An operator (for example an intended patient who has been assigned a mobile device) activates a mobile device 500 for a period of time on each of 3 separate occasions (the number of occasions is dictated by operating instructions provided to an intended patient and the number “3” is selected for illustration purposes only—any number of occasions, including one occasion or more than three occasions, is contemplated herein) by engaging an activation component 502 (for example a button) on the device 500. In response, on each of the 3 occasions an operating component 504 of the device 500 generates operating data and a processor 506 of the device 500 executes instructions to cause the operating data to be stored in a memory 508 of the device 500. Next, a cellular radio 510 of the device 500 detects a cellular network 512 and, following detection of the cellular network 512, the processor 506 executes instructions to cause the operating data to be copied from the memory 508, placed—along with a preconfigured identification code for the device and a preconfigured destination address associated with a server hardware 514—into a network packet, and transferred via the cellular radio to the cellular network 512. After traversing a portion of the cellular network the network packet is passed to a packet-switched network 516 (for example the public Internet) and routed to the server hardware. The operating data and identification code for the mobile device 500 are extracted from the packet and the operating data is encoded as time series of operating data (indexed at least in part by the identification code for the mobile device 500) in a device database 518 resident on the server hardware 514. The device database 518 does not contain any personal identification information for an intended user of the device 500. The server hardware 514 may be a secure server hardware that is purpose-configured to receive data exclusively from predetermined devices based on a pre-populated list of device identification codes, and write access to the device database 518 may otherwise be strictly limited to predetermined administrative functions (for example, pre-populating device identification codes). Optionally, the processor 506 may execute instructions to encrypt the operating data before the operating data is stored in the memory 508, or the processor 506 may execute instructions to encrypt the operating data before it is transmitted to the cellular network 512.

[0195] Subsequently, remote compliance monitoring of an intended patient's use of the mobile device 500 comprises a compliance device 520 obtaining the identification code for the device 500 and operating instructions for the device 500 (for example a doctor's prescription) from a HIPPA-compliant EHR database 522 via a network 524, and uses the identification code for the device 500 as an index to retrieve the time series of operating data from the device database 518 via the network 524. The remote compliance monitoring compares the time series of operating data with the operating instructions for the intended user and determines whether the course of use of the mobile device 500 complies with the instructions. If the use is non-compliant and a risk is detected that exceeds a predetermined threshold, remote compliance monitoring may trigger communication with the intended patient, for example to provide updated instructions for operating the device 500.

[0196] FIG. 5 describes certain exemplary embodiments, but other variations fall within scope of the disclosure. In certain embodiments, for example, the remote compliance monitoring may be performed at a healthcare facility 526 or at a location different location from the healthcare facility 526. In certain embodiments, for example, the network 524 may overlap the network 516, and/or the data from the EHR database 522 may be received by a different network than the time series of operating data. Certain embodiments, for example, may combine portions or all of FIGS. 1-5.

[0197] A schematic illustration of an approach to remote patient compliance monitoring incorporating a distributed ledger is depicted in FIG. 6. An operator (for example an intended patient who has been assigned a mobile device) activates a mobile device 500 for a period of time on each of 3 separate occasions (the number of occasions is dictated by operating instructions provided to an intended patient and the number “3” is selected for illustration purposes only—any number of occasions, including one occasion or more than three occasions, is contemplated herein) by engaging an activation component 502 (for example a button) on the device 500. In response, on each of the 3 occasions an operating component 504 of the device 500 generates operating data and a processor 506 of the device 500 executes instructions to cause the operating data to be stored in a memory 508 of the device 500. Next, a cellular radio 510 of the device 500 detects a cellular network 210 and, following detection of the cellular network 512, the processor 506 executes instructions to cause the operating data to be copied from the memory 508, placed—along with a preconfigured identification code for the device and a preconfigured destination address associated with a server 514—into a network packet, and transferred via the cellular radio to the cellular network 512. After traversing a portion of the cellular network the network packet is passed to a packet-switched network 516 (for example the public Internet) and routed to the server. The operating data and identification code for the mobile device 500 are extracted from the packet and the operating data is encoded as time series of operating data (indexed at least in part by the identification code for the mobile device 500) in a device database 518 resident on the server 514. The device database 500 does not contain any personal identification information for an intended user of the device 500. Optionally, the processor 506 may execute instructions to encrypt the operating data before the operating data is stored in the memory 508, or the processor 506 may execute instructions to encrypt the operating data before it is transmitted to the cellular network 512.

[0198] Subsequently, the time series of operating data (or one or more hashes derived from the time series of operating data) is published to a distributed ledger 600 via a network 524. The distributed ledger 600 may be a private ledger or a public ledger such as Ethereum configured to provide an immutable and optionally encrypted) record of the time series data. The server 514 may be a secure server that is purpose-configured to receive data exclusively from predetermined devices based on a pre-populated list of device identification codes, with write access to the device database 518 otherwise be strictly limited to predetermined administrative functions (for example, pre-populating device identification codes), and data export from the device database 518 may be limited to the publication to the distributed ledger 600 (e.g., according to a predefined protocol such as pre-approved JSON messages) and to predefined internal report generation.

[0199] Remote compliance monitoring of an intended patient's use of the mobile device 500 comprises a compliance device 520 obtaining the identification code for the device 500 and operating instructions for the device 500 (for example a doctor's prescription) from a HIPPA-compliant EHR database 522 via the network 524, and uses the identification code for the device 500 as an index to retrieve the time series of operating data (and/or one or more hashes (for example one hash for each data transmission from the mobile device) derived from the time series of operating data) from the distributed ledger 600 via the network 524. The one or more hashes may be used to generate a request for one or more dates associated with the time series. The remote compliance monitoring compares the time series of operating data with the operating instructions for the intended user and determines whether the course of use of the mobile device 500 complies with the instructions. If the use is non-compliant and a risk is detected that exceeds a predetermined threshold, remote compliance monitoring may trigger communication with the intended patient, for example to provide updated instructions for operating the device 500.

[0200] FIG. 6 describes certain exemplary embodiments, but other variations fall within scope of the disclosure. In certain embodiments, for example, the remote compliance monitoring may be performed at a different location from the healthcare facility 526. In certain embodiments, for example, the network 524 may overlap the network 516, and/or the data from the EHR database 522 may be received by a different network than the time series of operating data. Certain embodiments, for example, may combine portions or all of FIGS. 1-6.

[0201] A schematic illustration of an approach to remote patient compliance monitoring incorporating a distributed ledger and a compliance reporting service is depicted in FIG. 7. An operator (for example an intended patient who has been assigned a mobile device) activates a mobile device 500 for a period of time on each of 3 separate occasions (the number of occasions is dictated by operating instructions provided to an intended patient and the number “3” is selected for illustration purposes only—any number of occasions, including one occasion or more than three occasions, is contemplated herein) by engaging an activation component 502 (for example a button) on the device 500. In response, on each of the 3 occasions an operating component 504 of the device 500 generates operating data and a processor 506 of the device 500 executes instructions to cause the operating data to be stored in a memory 508 of the device 500. Next, a cellular radio 510 of the device 500 detects a cellular network 512 and, following detection of the cellular network 512, the processor 506 executes instructions to cause the operating data to be copied from the memory 508, placed—along with a preconfigured identification code for the device and a preconfigured destination address associated with a server 514—into a network packet, and transferred via the cellular radio to the cellular network 512. After traversing a portion of the cellular network the network packet is passed to a packet-switched network 516 (for example the public Internet) and routed to the server. The operating data and identification code for the mobile device 500 are extracted from the packet and the operating data is encoded as time series of operating data (indexed at least in part by the identification code for the mobile device 500) in a device database 518 resident on the server 514. The device database 518 does not contain any personal identification information for an intended user of the device 500. Optionally, the processor 506 may execute instructions to encrypt the operating data before the operating data is stored in the memory 508, or the processor 506 may execute instructions to encrypt the operating data before it is transmitted to the cellular network 520.

[0202] Subsequently, the time series of operating data is published to a distributed ledger 600 via the network 524. The distributed ledger 600 may be a private ledger or a public ledger such as Ethereum configured to provide an immutable and optionally encrypted) record of the time series data. The server 514 may be a secure server that is purpose-configured to receive data exclusively from predetermined devices based on a pre-populated list of device identification codes, with write access to the device database 518 otherwise be strictly limited to predetermined administrative functions (for example, pre-populating device identification codes), and data export from the device database 518 may be limited to the publication to the distributed ledger 600 (e.g., according to a predefined protocol such as pre-approved JSON messages) and to predefined internal report generation.

[0203] Remote compliance monitoring of an intended patient's use of the mobile device 500 comprises a compliance service 700 obtaining the identification code for the device 500 and operating instructions for the device 500 (for example a doctor's prescription) from a HIPPA-compliant EHR database 522 via a network 524, and uses the identification code for the device 500 as an index to retrieve the time series of operating data from the distributed ledger 600 via the network 524. The compliance service 700 compares the time series of operating data with the operating instructions for the intended user and generates a report which is transmitted to a compliance device 520 utilized to perform the remote compliance monitoring to determine whether the course of use of the mobile device 500 complies with the instructions. If the use is non-compliant and a risk is detected that exceeds a predetermined threshold, remote compliance monitoring may trigger communication with the intended patient, for example to provide updated instructions for operating the device 500.

[0204] FIG. 7 describes certain exemplary embodiments, but other variations fall within scope of the disclosure. In certain embodiments, for example, the remote compliance monitoring may be performed at a different location from the healthcare facility 526. In certain embodiments, for example, the network 524 may overlap the network 516, and/or the data from the EHR database 522 may be received by a different network than the time series of operating data. Certain embodiments, for example, may combine portions or all of FIGS. 1-7.

[0205] FIG. 8 schematically depicts a blockchain 800 having a starting block 802 (the so-called “genesis block”) and a subsequent series of transactional blocks (804, 806, and 808). Each transactional block (804, 806, or 808) comprises a transaction (810, 812, or 814, respectively) (for example the transfer of property from one party to another) and a hash value (816, 818, or 820, respectively), the hash value referencing the previous block. The hash value is a piece of ciphertext generated by passing (822, 824, or 826) at least a portion of the text of the previous block through at least one mathematical hash function. The hash values (816, 818, and 820) ensure that a block cannot be altered without causing a mismatch between the contents of the block and the hash values in all subsequent blocks. Moreover, any mismatch should be easy to detect because the at least one mathematical hash function is selected to ensure that even a small change to the content of a block produces a large change in the hash value generated from it. Of note, the hash values make it simple to track and audit the validity of the data, making blockchains much more difficult to hack or falsify.

[0206] FIG. 9 is a schematic depiction of exemplary steps required to add transactions to a blockchain A wallet 904 transmits packet data containing a new transaction to one or more network participants 906 in a blockchain network, each of whom maintains their own copy of a list of new transactions 908A (so-called “unconfirmed transactions”). Each participant 906 may verify the veracity of the new transactions 908A (including verification of digital signatures associated with the new transactions) according to a pre-determined set of rules, either in partnership or in competition with other participants, and place the verified new transactions in a new block 910. The new block 910 may be appended to a prior instance of the blockchain 912 containing previously added blocks 914A-E as shown, and the provenance and immutability of the resulting blockchain 916 may be established by including a ciphertext signature 918 in the new block 910, wherein the ciphertext signature 918 is obtained by applying a cipher function (for example a hash or trap door function) constructively to all of the prior instance of the blockchain 912. The participant distributes the resulting blockchain 916 to the other network participants, and the participants apply consensus rules to either accept or reject the blockchain 916. If the blockchain 916 is accepted, it replaces the prior instance of the blockchain 912 and becomes the starting point for appending future blocks.

[0207] FIG. 10 is a schematic depiction of a distributed ledger ecosystem configured to process user-originated transactions and smart contracts. Consensus nodes 1000A-D communicate among one another to verify transactions, authorize messages that trigger execution of smart contract functions (according to consensus rules), update the distributed ledger with new transactions (according to the consensus rules), and manage copies of a distributed ledger 1002A-D. The distributed ledger 1002A-D contains transactions, uploaded data, and smart contracts grouped in sequences of blocks. Placement of smart contracts on the consensus nodes 1000A-D in the distributed ledger 1002A-D enables the smart contracts and their data to be maintained in a persistent state based on the state of the distributed ledger 1002A-D, and for transactions initiated by the smart contracts to be authorized based on consensus rules followed by the consensus nodes 1000A-D. In an exemplary configuration, the distributed ledger contains copies 1004A-D of a first smart contract for distributing trust assets (the trust assets and their ownership recorded in the distributed ledger 1002A-D) to beneficiaries and copies 1006A-D of a second smart contract for updating a car registry recorded in the distributed ledger 1002A-D.

[0208] In operation, a user node 1008 (for example a node at a law firm) deploys a copy of the first smart contract to a consensus node 1000A, which then shares the first smart contract with the other nodes. Once the first smart contract is added to the distributed ledger 1002A-D, a node at a bank 1010 may send a message to one of the consensus nodes 1000B to execute a function of the first smart contract to distribute a quantity of cryptocurrency (or other assets, as defined by the smart contract) to user accounts named in the first smart contract. To trigger the distribution, the consensus nodes 1000A-D will independently execute said function and communicate with one another to reach consensus about the correct result.

[0209] In another example of the ecosystem in operation, a node 1012 at a department of motor vehicles may transmit a message to a consensus node 1000A to execute a function of the second smart contract to upload updated car registry information to the distributed ledger 1002A-D. The distributed 1002A-D ledger is updated once the consensus nodes 1000A-D verify the message and reach consensus on the result of said function. A separate node 1014 (for example a node at a car dealership or a police department) may send a message with proper authenticating credentials to a consensus node 1000D to query and read a portion of the uploaded vehicle registry information from a copy 1002D of the distributed ledger.

[0210] In addition to the foregoing transactions related to smart contracts, a client wallet 1016 (for example a wallet present on a smart phone) may submit a transaction to a consensus node 1000C to transfer a quantity of cryptocurrency from one address to another address. The cryptocurrency transaction may be embedded into a smart contract function call whereby specified transactions may only occur if valid amounts of cryptocurrency are included in said transactions. Similarly to the previous transactions, prior to executing the transaction and updating the distributed ledger 1002A-D, the consensus nodes 1000A-D will receive and verify the transaction, followed by reaching consensus on the correct state of the distributed ledger 1002A-D.

[0211] All publications and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

[0212] While preferred embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. It is intended that the following claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby.