Accenture Global Solutions Limited

Other

Hugo Borne-Pons

Giuseppe Giordano

Luca Schiatti

Naima Hamouma

David Baurle Treat

Abdoulaye Faye

Antoine Rabenandrasana

Emmanuel Viale

Haris Pasic

Hugo Tardiou

Embodiments provide systems, method, and computer-readable storage media for performing robotic tasks in a distributed and coordinated manner. A fleet of robots may use a sequence of messages to appoint supervisors for a set of tasks, where the supervisor robots are responsible for ensuring that their supervised tasks are completed by other robots of the fleet. The supervisors may solicit requests from other robots to perform available tasks and select a robot to perform an available task. Once a robot is appointed, the supervisor and the worker may use messaging sequences to monitor the status of the task and participating robots (e.g., the supervisor and the worker). The monitoring may enable the supervisor to detect a failed worker and enable other robots to detect a failed supervisor. When failed robots are detected, the robot(s) detecting the failure may initiate operations to take over the role(s) of the failed robots to ensure operation of the fleet of robots continues in a smooth manner and the tasks are completed efficiently.

Fault tolerant systems for distributed supervision of robots

Systems and methods of the present disclosure leverage distributed ledger technology (DLT) to provide decentralized control of cooperative tasks performed by a plurality of robots. Characteristics of the plurality of robots may be stored in a distribute ledger, which may be provided by a blockchain or a distributed database system. When a service request is received, a set of tasks may be identified for providing the requested service and the robot characteristics recorded to the distributed ledger may be used to identify a list of candidate robots possessing characteristics corresponding to the set of tasks may be identified. A smart contract may be utilized to select one or more candidate robots for performing the task and to verify the selected robot(s) successfully completed the task. State information associated with operation of the selected robot(s) may be monitored to verify task completion.

Decentralized robot cooperation platform

A device may receive entity data identifying parameters needed by entities to generate a quotation, and entity encryption data identifying homomorphic encryption schemes supported by the entities. The device may receive, from a client device, a smart contract that includes a request for a quotation, client encryption data identifying homomorphic encryption schemes supported by the client device, and identification data identifying the entities. The device may encrypt the data included in the smart contract, based on the entity encryption data and the client encryption data, to generate encrypted data. The device may generate a modified smart contact by replacing the data included in the smart contract with references to the encrypted data. The device may provide the modified smart contract to server devices associated with the entities. The device may receive, from the server devices associated with the entities, the modified smart contract with quotations.

Systems and methods for secure requests for quotations

Systems and methods for active state synchronization between distributed ledger technology (DLT) platforms are provided. A system may store an origin blockchain compliant with an origin DLT. The system may further store a target blockchain compliant with a target DLT. The target DLT may be different from the origin DLT. The system may include a DLT object synchronizer with access to the origin blockchain and the target blockchain. The DLT object synchronizer may receive, from an exchange node, a request to synchronize an origin instance of a DLT object between the origin blockchain and the target blockchain. The DLT object synchronizer may select a target instance of the DLT object on the target blockchain. The DLT object synchronizer may format origin data from the origin instance for compliance with the target DLT. The DLT object synchronizer may synchronize the origin instance and the target instance.

Active state blockchain synchronization

Systems and methods for membership-based cryptologic blockchain interoperability are provided. A receiver distributed ledger technology (DLT) network may include a data receiver node and a receiver validator node. The receiver validator node may receive a certification of token data stored on a furnisher blockchain. The certification may be signed by a plurality of furnisher validator nodes of a furnisher DLT network. To validate the certification, the receiver validator may obtain a furnisher credentials stored on a membership blockchain. The receiver validator node may perform the validation based on the furnisher credentials. The receiver validator node may digitally sign a validation of the certification. The receiver node of the receiver DLT network may commit the token data to a receiver blockchain in response to validation of the certification.

Cryptologic blockchain interoperability membership system

A system may provide a smart contract interface for blockchain interoperability. The system receive selection parameters indicative of a furnisher blockchain and a receiver blockchain. The system may obtain, based on the selection parameters, furnisher synchronization logic and receiver synchronization logic. The furnisher synchronization logic may include instructions to lock token data on the furnisher blockchain. The receiver synchronization logic may include instructions to commit token data to the receiver blockchain. The system may generate an interoperability smart contract comprising the furnisher synchronization logic and the receiver synchronization logic. The system may deploy the interoperability smart contract to a furnisher blockchain and the receiver blockchain.

Cryptologic self-executing blockchain export commitment

A system may receive a request to perform a token exchange between a first account and a second account. A selected token for the token exchange may be associated with the first account. A hash of the selected token may be stored on a furnisher blockchain of a first distributed ledger. The system may generate a new token and a hash of the new token. The system may generate a shielded exchange instruction, the shielded exchange instruction comprising the hash of the new token and a zero-knowledge proof, wherein the zero-knowledge proof is indicative of the selected token being associated with the first account. The system may submit the shielded exchange instruction to a distributed ledger technology platform to cause execution of a furnisher smart contract and a receiver smart contract. Each of the smart contracts are configured to separately verify the zero-knowledge proof and update corresponding blockchains to consummate and record the token exchange.

Shielded interoperability of distributed ledgers

A distributed ledger technology (DLT) network may include a plurality of participant nodes. The participant nodes may respectively validate a distributed ledger based on a consensus protocol. A blockchain export system may send, to a data receiver not included in the DLT network, a participant public key for a participant node of the DLT network. The blockchain export system may receive, from the data receiver, a request to share token data stored in a blockchain of the distributed ledger. The blockchain export system may generate a certification that the token data is stored on the blockchain. The certification may include a digital signature based on a participant private key paired to the participant public key. The blockchain system may transmit the certification to the data receiver. The data receiver may verify the certification based on the participant public key.

Cryptologic blockchain interoperation

This document describes systems, methods, devices, and other techniques for managing healthcare records. In some implementations, a computing system is provided that includes an electronic ledger, a first program module, and a second program module. The electronic ledger can store entries of medical record management events invoked by participants in a distributed computing network. The first program module can be assigned to an account of a first user on the distributed computing network and can identify (i) medical records of the first user and (ii) accounts of users other than the first user that are authorized to access the medical records of the first user. The second program module can be assigned to an account of a second user on the distributed computing network and can call the first program module to request access to a set of one or more of the medical records of the first user.

Distributed healthcare records management

For shielded cryptographic data exchange interoperation, an interoperability node is in communication with a furnisher participant node of a furnisher distributed ledger technology (DLT) network and a receiver participant node of a receiver DLT network. The interoperability node may obtain a shielded exchange instruction. The shielded exchange instruction may include a zero-knowledge proof, a selected token nullifier, a new token nullifier, and a new token digest. The zero-knowledge proof may be indicative of the furnisher participant having access to the selected token identifier. When the interoperability node determines that the new token nullifier is not present on a receiver blockchain, the interoperability node may submit the shielded exchange instruction to a furnisher smart contract and a receiver smart contract. The furnisher smart contract may retire the selected token nullifier on the furnisher blockchain. The receiver smart contract may insert the new token nullifier and the new token digest to the receiver blockchain.

Interoperability of zero-knowledge proof enabled blockchains

Systems and methods for cryptologic blockchain interoperability are provided. A furnisher participant of a furnisher DLT network may receive a request to export or share token data stored on a furnisher blockchain that stores the token data based on a furnisher DLT. The furnisher participant may transmit, to a plurality of validator participants of the furnisher DLT network, a consensus request to certify the token data is stored on a furnisher blockchain. The furnisher participant may receive certifications that the token data is stored on the furnisher blockchain. The certifications may include digital signatures respectively signed by the validator participants. The furnisher participant may generate a multi-signature certification message. The furnisher participant may communicate the multi-signature certification message to the data receiver. The data receiver may verify the digital signatures based on public keys of the validator participants of the furnisher DLT network.

A data furnisher may append, to a furnisher blockchain, an interoperability smart contract comprising a cryptologic committal. The cryptologic committal may include logic configured to cause a data receiver to commit token data to the receiver blockchain based on a pre-commit authorization. The data furnisher may encrypt, based on a committal key, a pre-commit authorization to transfer token data stored on the furnisher blockchain to the receiver blockchain. The data furnisher may transmit the pre-commit authorization to the data receiver. After transmission of the pre-commit authorization, the data furnisher may receive a pre-commit acknowledgement of the pre-commit authorization. The data furnisher may lock the token data on the furnisher blockchain in response to verification that the token data is appended to the data receiver blockchain. The data furnisher may send the predetermined committal key to the data receiver to commit the token data to the data receiver blockchain.

Growing community of inventors

Juan les Pins, France

Hugo Borne-Pons