Abstract: A Blockchain Rules Engine is provided as a pluggable service that depicts a real-world implementation of a Rules Engine that stores rules, transactions, and results on a blockchain for use by blockchain and non-blockchain applications. The Blockchain Rules Engine manages rules implemented by a client application that interacts with a blockchain platform that manages the blockchain. The Blockchain Rules Engine includes a language specific software developer's kit (SDK) that provides an interface to the client application and that exposes rule execution functionality to the client application, a rules engine application programming interface (API) layer that provides a rules engine API to the language specific SDK and that receives and processes commands from the language specific SDK, and a blockchain platform specific service layer that interacts with the blockchain platform and accepts input from the rules engine API layer to execute business logic implemented in the rules.

Abstract: An Application Specific Integrated Kernel (ASIK) is a modular interface that provides generic solutions to major business needs without the developer having to understand the Blockchain. The ASIK is a collection of APIs for essential use cases that are frequently performed on the Blockchain. The APIs are synchronized with business logic on a Chaincode. A web service layer of the ASIK identifies the business requirements and exposes representational state transfer (REST) APIs from a bundle that may be needed to fulfill a task or operation. A certain transaction request made by the end user is carried out by a generic collection of preconceived scenarios that is configured by the input data collected from the request and converted to Blockchain transactions by the Chaincode. Once the transaction is successfully performed on the Blockchain, the response travels back to the user in the form of a viable output.

Abstract: A Blockchain Rules Engine is provided as a pluggable service that depicts a real-world implementation of a Rules Engine that stores rules, transactions, and results on a blockchain for use by blockchain and non-blockchain applications. The Blockchain Rules Engine manages rules implemented by a client application that interacts with a blockchain platform that manages the blockchain. The Blockchain Rules Engine includes a language specific software developer's kit (SDK) that provides an interface to the client application and that exposes rule execution functionality to the client application, a rules engine application programming interface (API) layer that provides a rules engine API to the language specific SDK and that receives and processes commands from the language specific SDK, and a blockchain platform specific service layer that interacts with the blockchain platform and accepts input from the rules engine API layer to execute business logic implemented in the rules.

Abstract: A set of both smart contract and off-chain tools is described that enable the management and organization of data so as to enable storage of that data in a distributed ledger according to relational database principles. A cross-distributed-ledger-platform specification plus reusable core components together create a system that may be implemented on distributed ledger platforms to enable storage and retrieval of data to/from the distributed ledger governed by relational principles. A realization of this system enables addition of system chaincode to Hyperledger® Fabric and uses schemas and data represented as JSON. In use, the user may create, update, and query data from code, a console, or a smart contract where every update is a distributed ledger transaction.

Abstract: A blockchain transaction manager implements a method of managing submission of blockchain transactions to a node in a blockchain network by validating a received blockchain transaction and enqueuing the validated received blockchain transaction in a transaction queue, preparing at least one transaction attribute of the received blockchain transaction and placing the received blockchain transaction in a persistence queue, digitally signing or certifying the received blockchain transaction, attempting to submit the digitally signed or certified blockchain transaction to the node, and polling a blockchain status of the submitted blockchain transaction. Processes are provided for automatically recalculating blockchain transaction processing fees in the blockchain transaction attributes. Processes are also provided for repairing transaction attributes when the blockchain transaction has been rejected and submitting the repaired blockchain transaction to the node.

Abstract: A parent/child model for smart contracts enables the smart contracts to be updateable without compromising the immutability of the underlying data. As a first step, a parent smart contract (Client Contract) is deployed that stores any other contract that may be called using the contract address. Then, whenever a new child smart contract (Service Contract) is deployed, the parent smart contract is updated with the address of the new child smart contract so that the parent smart contract will be able to call the child smart contract. The structure of the child smart contract is known to the parent smart contract. For example, the number of inputs going into the child smart contract and the number of outputs coming out of the child smart contract are known to the parent smart contract before deployment of the parent smart contract, and the transaction data remains accessible without affecting the parent contract.

Abstract: A blockchain transaction manager implements a method of managing submission of blockchain transactions to a node in a blockchain network by validating a received blockchain transaction and enqueuing the validated received blockchain transaction in a transaction queue, preparing at least one transaction attribute of the received blockchain transaction and placing the received blockchain transaction in a persistence queue, digitally signing or certifying the received blockchain transaction, attempting to submit the digitally signed or certified blockchain transaction to the node, and polling a blockchain status of the submitted blockchain transaction. Processes are provided for automatically recalculating blockchain transaction processing fees in the blockchain transaction attributes. Processes are also provided for repairing transaction attributes when the blockchain transaction has been rejected and submitting the repaired blockchain transaction to the node.

Abstract: A blockchain transaction manager implements a method of managing submission of blockchain transactions to a node in a blockchain network by validating a received blockchain transaction and enqueuing the validated received blockchain transaction in a transaction queue, preparing at least one transaction attribute of the received blockchain transaction and placing the received blockchain transaction in a persistence queue, digitally signing or certifying the received blockchain transaction, attempting to submit the digitally signed or certified blockchain transaction to the node, and polling a blockchain status of the submitted blockchain transaction. Processes are provided for automatically recalculating blockchain transaction processing fees in the blockchain transaction attributes. Processes are also provided for repairing transaction attributes when the blockchain transaction has been rejected and submitting the repaired blockchain transaction to the node.

Abstract: A blockchain transaction manager implements a method of managing submission of blockchain transactions to a node in a blockchain network by validating a received blockchain transaction and enqueuing the validated received blockchain transaction in a transaction queue, preparing at least one transaction attribute of the received blockchain transaction and placing the received blockchain transaction in a persistence queue, digitally signing or certifying the received blockchain transaction, attempting to submit the digitally signed or certified blockchain transaction to the node, and polling a blockchain status of the submitted blockchain transaction. Processes are provided for automatically recalculating blockchain transaction processing fees in the blockchain transaction attributes. Processes are also provided for repairing transaction attributes when the blockchain transaction has been rejected and submitting the repaired blockchain transaction to the node.

Abstract: A parent/child model for smart contracts enables the smart contracts to be updateable without compromising the immutability of the underlying data. As a first step, a parent smart contract (Client Contract) is deployed that stores any other contract that may be called using the contract address. Then, whenever a new child smart contract (Service Contract) is deployed, the parent smart contract is updated with the address of the new child smart contract so that the parent smart contract will be able to call the child smart contract. The structure of the child smart contract is known to the parent smart contract. For example, the number of inputs going into the child smart contract and the number of outputs coming out of the child smart contract are known to the parent smart contract before deployment of the parent smart contract, and the transaction data remains accessible without affecting the parent contract.

Abstract: A set of both smart contract and off-chain tools is described that enable the management and organization of data so as to enable storage of that data in a distributed ledger according to relational database principles. A cross-distributed-ledger-platform specification plus reusable core components together create a system that may be implemented on distributed ledger platforms to enable storage and retrieval of data to/from the distributed ledger governed by relational principles. A realization of this system enables addition of system chaincode to Hyperledger® Fabric and uses schemas and data represented as JSON. In use, the user may create, update, and query data from code, a console, or a smart contract where every update is a distributed ledger transaction.

Abstract: A blockchain-based consent management system includes a webserver subsystem configured to receive and handle authorized web user requests for access to and/or transactions corresponding to consent data for a blockchain, the webserver subsystem comprising a blockchain subsystem interface; and a blockchain subsystem defining a channel having at least two organizations, corresponding chaincode and an endorsement policy, each of the at least two organizations having at least one peer, each of the at least one peer maintaining a blockchain copy, the blockchain subsystem comprising an orderer in communication with the blockchain subsystem interface.

Abstract: A set of both smart contract and off-chain tools is described that enable the management and organization of data so as to enable storage of that data in a distributed ledger according to relational database principles. A cross-distributed-ledger-platform specification plus reusable core components together create a system that may be implemented on distributed ledger platforms to enable storage and retrieval of data to/from the distributed ledger governed by relational principles. A realization of this system enables addition of system chaincode to Hyperledger® Fabric and uses schemas and data represented as JSON. In use, the user may create, update, and query data from code, a console, or a smart contract where every update is a distributed ledger transaction.

Abstract: Embodiments may include, at a vendor's materials handling facility that includes a first process management component controlled by the vendor for preparing shipments and a second process management component controlled by a merchant that receives inventory items from the vendor at the vendor's materials handling facility, utilizing the second process management component to receive order information specifying one or more items that a customer ordered from the merchant. The reserved portion of the vendor's materials handling facility may be reserved for shipment preparation operations controlled by the merchant. Embodiments may include, subsequent to the merchant receiving the item(s) from the vendor into a reserved portion of the facility reserved for merchant operations, utilizing the second process management component to control the preparation of a shipment including the one or more items specified by the order information.

Abstract: A client hosted virtualization system (CHVS) includes a processor and non-volatile memory with BIOS code and virtualization manager code. The virtualization manager initializes the CHVS, authenticates a virtual machine image and launches the virtual machine based on the image. The CHVS is configurable to execute the BIOS or the virtualization manager. A client system update network includes a client update system and a CHVS with a processor, a security processor, and non-volatile memory with BIOS code and virtualization manager code that initializes the CHVS, authenticates a virtual machine image and launches a virtual machine based on the image. The CHVS is configurable to execute the BIOS or the virtualization manager. The client update system receives updates and sends them to the CHVS. The CHVS authenticates the updates with the security processor, and overwrites the non-volatile memory with the updates.

Abstract: A system, method, and computer-readable medium are disclosed for automatically provisioning a virtual image on a target system. A service operating system comprising a virtual machine monitor and a personalization agent is installed on a target system. A set of digital assets entitlement data is provided along with an associated set of digital assets data contained in a virtual software image, which is then installed on the target system by the personalization agent.

Abstract: A client hosted virtualization system (CHVS) includes a processor and non-volatile memory with BIOS code and virtualization manager code. The virtualization manager initializes the CHVS, authenticates a virtual machine image and launches the virtual machine based on the image. The CHVS is configurable to execute the BIOS or the virtualization manager. A client system update network includes a client update system and a CHVS with a processor, a security processor, and non-volatile memory with BIOS code and virtualization manager code that initializes the CHVS, authenticates a virtual machine image and launches a virtual machine based on the image. The CHVS is configurable to execute the BIOS or the virtualization manager. The client update system receives updates and sends them to the CHVS. The CHVS authenticates the updates with the security processor, and overwrites the non-volatile memory with the updates.

Abstract: A system, method, and computer-readable medium are disclosed for automatically provisioning a virtual image on a target system. A service operating system comprising a virtual machine monitor and a personalization agent is installed on a target system. A set of digital assets entitlement data is provided along with an associated set of digital assets data contained in a virtual software image, which is then installed on the target system by the personalization agent.

Abstract: A system and method is disclosed for the automatic enforcement of wireless-enabled device usage policies within a predetermined environment. A wireless usage policy manager enforces predetermined usage policies by automatically disabling or limiting the operation of wireless-enabled devices as they enter the predetermined boundaries of the wireless policy management environment. Information elements of existing wireless communications protocols are appended or extended and then communicated to subject wireless devices, and then implemented at the time of handover to limit their behavior. Similar information elements are communicated and implemented when the wireless-enabled devices exit the predetermined boundaries of the wireless policy management environment to automatically restore their prior operational state without user actions.

Abstract: A system and method is disclosed for decoupling and simulcasting metadata from digitized audio and/or video content to facilitate an on-line purchase of a copy of the content. One or more digitized audio/video content streams containing metadata are intercepted prior to being played. Metadata associated with the audio/video content within the intercepted stream is identified, decoupled, and wirelessly simulcasted by a metadata simulcaster such that it can be automatically received, stored and enacted upon by similarly enabled wireless devices to facilitate on-line purchases of the associated content, in electronic or physical form, at the present or a later time. Audio content metadata received via satellite radio is similarly intercepted by a mobile metadata simulcaster and locally simulcast via a wireless protocol such as, but not limited to, Bluetooth to similarly enabled wireless devices to facilitate on-line purchases of audio content through a wireless wide area network connection to the Internet.