Microsoft Technology Licensing, LLC

Prescryptive Health, Inc.

John Marley Gray

Nayana Singh Patel

Supriya Madhuram

Gregory Philip Cignavitch

David Allen Smith

Brenda Yachu Lee

Kevin C Young

Christopher Scott Blackley

Rhetick Sengupta

The disclosed technology is generally directed to secure transactions. In one example of the technology, an enclave is used for executing a cryptlet binary of a first cryptlet. The enclave is a secure execution environment for which results of a secure execution are capable of being attested to have run unaltered and in private, the enclave stores an enclave private key, and the first cryptlet is associated with at least a first counterparty. A cryptlet binding that is associated with the first cryptlet is generated. The cryptlet binding includes counterparty information that is associated with at least the first counterparty. Cryptlet binding information is provided to a cryptlet binding key graph. A location of a hardware security module (HSM) that stores a key that is associated with the first counterparty is received from the cryptlet binding key graph.

Cryptlet binding key graph

The disclosed technology is generally directed to secure transactions. In one example of the technology, a smart contract is generated based at least in part on a schema and provided information. The smart contract may be caused to be deployed on a ledger as a smart contract ledger instance. A unique address associated with the deployed smart contract ledger instance may be received. A cryptlet binding for a first contract cryptlet that is associated with the smart contract ledger instance may be generated. The cryptlet binding may be sent to the first contract cryptlet. Responsive to a state change associated with the first contract cryptlet, an update may be communicated to the smart contract ledger instance.

Cryptlet smart contract

A computer system comprises a logic system, and, operatively coupled to the logic system, a computer-memory system holding instructions that, when executed by the logic system, cause the computer system to: receive a token-behavior selection corresponding to a real-world asset to be tracked on a virtual ledger; receive a virtual-ledger architecture selection identifying a provider-defined architecture of the virtual ledger; construct a template for registration of a token class on the virtual ledger according to the provider-defined architecture of the virtual ledger, wherein each new token instantiated from the token class exhibits a set of behaviors determined by the token-behavior selection; and provide access to the template to a client computer device.

Reusable template for asset token

A system for managing prescriptions via a blockchain is provided. The system records in the blockchain a prescription transaction that identifies a prescription that has been written for a patient. The system then records in the blockchain a submission selection transaction with code for controlling selection of a pharmacy to dispense the prescription. For pharmacies that provide a submission for dispensing the prescription, the system records in the blockchain a submission transaction with submission information relating to dispensing of the prescription by the pharmacy. When a pharmacy is selected to dispense the prescription, the system records in the blockchain a selected submission transaction indicating the pharmacy selected to dispense the prescription. When the prescription is dispensed, the system records in the blockchain a dispense transaction indicating that the selected pharmacy has dispensed the prescription.

Blockchain prescription management system

The disclosed technology is generally directed to secure transactions. In one example of the technology, a first enclave to be used for executing a cryptlet binary of a first cryptlet is identified. The first enclave may be a secure execution environment that stores an enclave private key, and the first cryptlet may be associated with at least a first counterparty. A cryptlet binding that is associated with the first cryptlet may be generated, and may include counterparty information that is associated with at least the first counterparty. Cryptlet binding information may be provided to a cryptlet binding key graph, and a location of a first hardware security module (HSM) that stores a key that is associated with the first counterparty may be received from the cryptlet binding key graph.

Cryplet binding key graph

In one example, an enclave pool is formed. The enclave pool may include a plurality of enclaves. Each enclave may have a private enclave key and a public enclave key. A shared enclave pool key may be generated from or otherwise based on the public enclave key of each enclave of the enclave pool. A first enclave may be allocated from the enclave pool to a first cryptlet. A payload of the first enclave is received. The payload of the first enclave may be signed with a first digital signature by the private enclave key of the first enclave. A payload of the second enclave may be received. The payload of the second enclave may be signed with a second digital signature by the private enclave key of the second enclave. The first digital signature and the second signature may be validated via the shared enclave pool key.

Enclave pool shared key

Techniques for implementing a ledger-independent token service are provided. According to one set of embodiments, a computer system executing the service can receive, from a user, a request to create a token on a distributed ledger network. The computer system can further provide to the user one or more token templates, where each token template corresponds to a type of physical or digital asset and defines a set of one or more attributes and one or more control functions associated with the type. The computer system can then receive, from the user, a selection of a token template in the one or more token templates and create the token on the distributed ledger network, where the created token includes the set of one or more attributes and one or more control functions defined in the selected token template.

Ledger-independent token service

Data structures stored on a distributed ledger are accessed. The data structures identify registered smart contract components that include counterparties, schemas, and contract cryptlet. A first template smart contract data structure for a first smart contract is composed on the distributed ledger such that the first template smart contract data structure is a relational data structure that includes an identifier for the first smart contract, an identifier for at least two counterparties, an identifier for at least one schema, and an identifier for at least one contract cryptlet. A first smart contract ledger instance associated with the first ledger instance is caused to be deployed, such that the first smart contract ledger instance is based on the first template smart contract data structure. The first smart contract is caused to begin execution, such that the first smart contract is based on the first template smart contract data structure.

Relational distributed ledger for smart contracts

Proof onions for transactions for smart contracts are stored. Details of the transactions are stored on blockchains separate from the proof onions. The proof onions are evidence structures for the steps taken to create any transaction for the smart contract. The proof onions include a plurality of signatures or other cryptographic proofs. A proof request that is associated with at least a first transaction of the transactions is received. A first proof onion of the proof onions that corresponds to the first transaction is retrieved. A plurality of public keys associated with the first proof onion is obtained. The plurality of public keys is used to validate the first proof onion. In response to the validation of the first proof onion, the proof request is responded to with at least an indication of the validity of the first transaction.

Cryptlet proofing services

The disclosed technology is generally directed to secure transactions. In one example of the technology, a secure encrypted communication tunnel between the enclave and a hardware security module (HSM) may be established and used. Establishing the tunnel includes the following steps. A session public/private enclave key pair, including a session enclave private key and a session enclave public key, may be derived from the public/private key pair of the enclave. The session enclave public key may be sent to the HSM. A session HSM public key may be received from the HSM. Additional information may be encrypted with the session HSM public key. The encrypted additional information may be sent to the HSM. Further encrypted information may be received from the HSM. The further encrypted information may be decrypted with the session enclave private key.

Secure cryptlet tunnel

In one example, a smart contract is generated such that the smart contract includes a schema and at least two counterparties. An updated version of the smart contract is generated. The updated version of the smart contract is stamped with a version stamp. The version stamp is used to prove the validity of the updated version of the smart contract.

Binding version stamp for smart contracts

In one example, a first enclave for use by a first counterparty to a smart contract is identified. A second enclave for use by a second counterparty to the smart contract may be identified. Secrets associated with the first counterparty to the first enclave may be caused to be securely provided. Secrets associated with the second counterparty to the second enclave may be caused to be securely provided. A cryptlet is caused to be provided to the first enclave. The cryptlet may be caused to be provided to the second enclave. A payload is received from the first enclave. A payload may be received from the second enclave. Validation may be caused to be performed for a plurality of payloads. The plurality of payloads may include the payload from the first enclave and the payload from the second enclave.

Enclave ring and pair topologies

The disclosed technology is generally directed to smart contracts. In one example of the technology, a first sub-contract is initialized based on communications from a first beacon node and a second beacon node. Initializing the first sub-contract includes seeding an asset on a ledger based on the first sub-contract. One or more additional sub-contracts are initialized based on communications from the beacon nodes such that the first sub-contract and the one or more additional sub-contracts together form an enterprise smart contract, and such that each sub-contract of the enterprise smart contract interrelates to at least one other sub-contract of the enterprise smart contract. Execution of logic for the enterprise smart contract is controlled. Information associated with the execution of the logic for the enterprise contract is stored on the ledger.

Beacon network with enterprise smart contracts having a centralized ledger

The public enclave key of each enclave in an enclave pool may be registered in an enclave pool registry, and the registry updated each time there is an enclave pool membership change. A shared enclave pool key may be derived from the public enclave key of each enclave of the enclave pool. The shared enclave pool key may be stored, in a shared key ledger, as a first version of the shared enclave key, and an updated version of the shared key may be generated and stored as another version each time there is an enclave pool membership change. The output of a cryptlet that executed in multiple enclaves may be signed with the enclave private key of each enclave in which the cryptlet executed. Each enclave signature may be compared against each version of the of the shared enclave pool key in the shared key ledger.

Encave pool management

The disclosed technology is generally directed to cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. The request for cryptographic resources includes a binding identity (ID). Cryptographic resources are fetched from at least one cryptographic resource pool of a plurality of cryptographic resource pools responsive to the request for cryptographic resources. Separate cryptographic resource pools of the plurality of cryptographic resource pools are pools of separate types of cryptographic resources. Which type of proof delegate code is suitable for each fetched cryptographic resource is determined. For each fetched cryptographic resource, the determined type of proof delegate code is injected into the fetched cryptographic resource.

Growing community of inventors

Snoqualmie, WA, United States of America

John Marley Gray