Accenture Global Solutions Limited

Other

Stevens Institute of Technology

Luca Schiatti

Kuntal Dey

Vikrant Shyamkant Kaulgud

Giuseppe Giordano

Hugo Borne-Pons

David Baurle Treat

Emmanuel Viale

Andrea Maria Milazzo

Naima Hamouma

Anh-Dung Le

Abdoulaye Faye

Aspyn Cole Palatnick

Zixuan Zhang

Antoine Rabenandrasana

Giuseppe Ateniese

Daniel Bachenheimer

Haris Pasic

Tracy Ann Kuhrt

Sankar Narayan Das

Thomas Jean Georges M Moretti

Alexis Antoine Hoss

Angelo Massimo Perillo

Danilo Francati

Dominic Paolino

Anne Alice Germaine Groeppelin

Guiseppe Giordano

Emmanuel Jean Viale

Andrea Milazzo

A system may provide blockchain-based storage node control for unified proof-of-storage interaction for off-chain data chunk storage. The system may include verification circuitry that may provide a challenge to a storage node to audit the storage status of a data chunk. The verification circuitry may obtain identities for the storage node and data chunk based on blockchain records. The verification circuitry may obtain a challenge answer from the storage node in response. The verification circuitry may analyze the challenge answer in view of a challenge key to confirm whether the storage node has possession of the data chunk. When the storage node has possession of the data chunk chain circuitry may add a verification record to the blockchain.

Cryptologic blockchain-based off-chain storage verification

A system supports asset transfers among blockchains of differing distributed ledger technologies using interop circuitry. The interop circuitry may receive asset permissions from origin and target participant circuitry. The asset permissions may support transfer of an asset from an origin blockchain to a target blockchain. The interop circuitry, acting on behalf of the origin and target participant circuitry, locks an asset on the origin blockchain. Then the interop circuitry creates the asset on the target blockchain. The locking of the asset on the origin blockchain may prevent a double-expend opportunity, where the asset can be redeemed on the origin blockchain and on the target blockchain.

Blockchain interoperability

A system includes a display control prime located within a central-zone in communication with a provisioned agent operating on an edge-zone device. The display control prime may implement prime-blind open-loop pixel-state control on the edge-zone device by executing pixel-state commands via the provisioned agent. The provisioned agent, operating within the edge-zone, may have access to un-sanitized data, which may be unavailable to the display control prime in the central-zone. The display control prime may provide conditional pixel-state commands via a pixel-state control parameter matrix. The provisioned agent may identify an operative pixel-state command from among the conditional pixel-state commands based on the un-sanitized data to which the display control prime is blind.

Privacy-secure edge-zone digital identity computing for open-loop pixel-state control

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

A participant node of a distributed ledger network may identify a distributed federated learning (DFL) smart contract stored on a blockchain. The DFL smart contract may include an aggregation sequence. The aggregation sequence may include an ordered sequence of participant node identifiers. The participant node may generate a trained model by training a global model with training data. The participant node may detect, on the blockchain, a first transition token indicative of a first model previously aggregated by another participant node. The participant node may receive the first model. The participant node may aggregate the first model with the trained model to generate a second model. The participant node may store, on the blockchain, a second transition token indicative of the second model. A successor node identified in the aggregation sequence may further aggregate the second model with an additional model in response to detection of the second transition token.

Decentralized federated learning 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

In some implementations, a system may generate information that identifies a passphrase to be used as a biometric input. The system may receive a voice input of a user speaking the passphrase. The system may generate one or more cryptographic keys based on the voice input. The system may generate a digital identifier based on the one or more cryptographic keys. The system may generate one or more biometric templates for the user. The system may encrypt the one or more biometric templates using the one or more cryptographic keys and to generate one or more encrypted biometric templates. The system may store in a secure storage associated with the user, at least one of the digital identifier, a public key of the one or more cryptographic keys, a phone number associated with the user, or the one or more encrypted biometric templates. Numerous other aspects are provided.

Utilizing voice biometrics to generate a secure digital identity for a user without access to technology

A commodity-measuring device for autonomously selecting a commodity supplier among a plurality of commodity suppliers being specified within a blockchain distributed database is provided. A microcontroller unit is configured to provide commodity consumption data to the transaction manager. A storage is configured to store a private key, and a communication module is configured to retrieve a commodity supplier file stored in the blockchain distributed database, and the commodity supplier file includes parameters of a commodity supplier and a program. A transaction manager is configured to determine autonomously, based on the commodity consumption data and parameters in the commodity supplier file, whether to select the commodity supplier; and if the determination is positive, the transaction manager is configured to, using the private key, send a transaction to the blockchain distributed database calling a function in the program to associate the commodity supplier file with the identifier.

Device, method and system for autonomous selection of a commodity supplier through a blockchain distributed database

A master oracle may receive an oracle network identifier for an oracle network. The master oracle may receive a plurality of data messages respectively generated by the oracles. The master oracle may verify, based on respective public keys for the oracles, that each of the data messages are digitally signed by a different corresponding one of the oracles. The master oracle may aggregate the data messages into an aggregated data message. The master oracle may digitally sign the aggregated data message with a private key and public key pair. The master oracle may transmit the aggregated data message to a participant node of a distributed ledger network. A smart contract stored on a blockchain may verify the aggregated data. After receiving and verifying the aggregated data message the smart contract may execute to perform operations based on the aggregated data message.

Multi-source deterministic oracle management

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

A method for anonymously communicating data that defines a token from a source system to a destination system via a block-chain distributed database includes receiving, at a token distribution system, request information from a source system. The request information specifies source identifying information and an address for receiving one or more tokens. The token distribution system determines one or more tokens for allocation to the source system and communicates the allocated tokens to the address defined in the request information via a zero-knowledge transaction. The source system moves the tokens to a different address for communicating a block-chain transaction and communicates the tokens at the different address to a destination address associated with the destination system via a block-chain transaction.

Growing community of inventors

Juan les Pins, France

Luca Schiatti