Abstract: In an embodiment, systems and methods storing claims on a DSP and a cryptographic ledger are provided. When a provider generates a claim for a medical service, the claim is encrypted using key exchanged between the provider and the payor. The encrypted claim is stored at the DSP at a DSP provided address. The encrypted claim and DSP provided address are stored on a cryptographic ledger as an NFT or other data structure. The payor may retrieve the DSP provided address from the ledger and may retrieve the encrypted claim from the DSP. The payor may decrypt the claim and may facilitate payment for the claim via a smart contract or may otherwise dispute the claim. At a later time, the provider (or payor) can use a zero-knowledge proof to prove that the claim was provided (or paid).

Abstract: Disclosed are various embodiments for a service for decentralized browser based wallets. Various embodiments of the present disclosure can receive a first passcode and a second passcode from a security provider device. Various embodiments can use a cryptowallet to decrypt a first encrypted private key using the first passcode to generate a decrypted private key. Various embodiments can use a cryptowallet to sign a transaction request with the decrypted private key. Various embodiments can use a cryptowallet to generate a second encrypted private key by encrypting the decrypted private key using the second passcode.

Abstract: A contract provider provides a distributed ledger that has a node for each payor, provider, and the contract provider. Each entity controls its own node and has access to private and public keys associated with their node. When a provider desires to create a contract with a provider, the provider uses an application provided by the contract provider. The application has access to various contract related templates, forms and workflows associated with the contracts. The application includes an iframe that connects to the node of the provider. The provider may create a draft contract using the application that is stored on the distributed ledger by the nodes of the provider via the iframe. The payor may then similarly use the application to access the contract via the iframe by contacting to their node. The provider and payor may continue to edit the contract via the application until it is complete.

Abstract: Systems and methods for transaction authorizations using a distributed database are disclosed. The system may allow registered transaction account holders and merchants to interact and complete transactions according to workflows enforced by smart contracts. The system may include an issuer system that receives a transaction authorization request comprising a merchant ID, a transaction account number, a transaction amount, and a transaction ID. The issuer system may retrieve a merchant public key and a smart contract based on the merchant ID, and a user public key based on the transaction account number. The issuer system may invoke the smart contract by passing the user public key and the transaction ID to the smart contract. The system may propagate transaction data (e.g., the merchant ID, the transaction account number, the payment amount, a transaction status, etc.) to a blockchain network for writing to a blockchain according to the invoked smart contract.

Abstract: Disclosed are various embodiments for using a distributed ledger to track the evolution or deployment of feature sets for machine-learning. A registration request is received from a first node of a distributed ledger, the registration request comprising a code hash representing a feature set generator and a data hash representing a data set. The registration request is then relayed to a second node of the distributed ledger for approval by the second node. Next, an approval for the registration request is received from the second node. Subsequently, an entry in the distributed ledger comprising the code hash and the data hash is created.

Abstract: A hybrid identity service system is disclosed. The system may receive a transaction request. The system may generate a first passcode and a second passcode. The system may decrypt a first encrypted private key with the first passcode to recover a private key. The system may sign the transaction request with the private key and may encrypt the private key with the second passcode to generate a second encrypted private key.

Abstract: Disclosed are various embodiments for decentralizing the authentication or verification of data. An identity key can be generated for a data item. A request can then be sent to an authentication service for authentication of the data item, the request comprising the identity key and the data item. A verified claim for the data item can then be received in response. Subsequently, an identity document is generated, the identity document comprising the identity key for the data item and the verified claim. Finally, the identity document can be stored in a distributed ledger.

Abstract: Disclosed are various approaches for managing the status of machine-learning models using distributed ledgers. A registration request for a machine-learning model can be received. The registration request can include a model name for the machine-learning model, a version identifier for the machine-learning model, a network address from which the machine-learning model can be retrieved, a source code hash for a source code version of the machine learning model, and a runtime hash for a binary executable version of the machine-learning model. A registration identifier can then be created based at least in part on the source code hash and the runtime hash. Subsequently, an entry in the distributed ledger can be created for the machine-learning model. The entry can include the registration identifier, the model name, the model version, the network address, the source code hash, and the runtime hash.

Abstract: A transaction account based micro-payment system using blockchain is disclosed. The system may receive a micro-payment request including a payment address from a merchant system. The system may invoke an account holder account smart contract and a directory smart contract. The system may write a plurality of micro-payment transaction debits to a transaction account based micro-payment blockchain via a blockchain node. The system may generate a transaction clearance event based on the account holder account smart contract. The system may write a micro-payment transaction clearance credit to the transaction account based micro-payment blockchain.

Abstract: A single sign-on system using blockchain is disclosed. The single sign-on system may interconnect various organization systems over a peer-to-peer network, with each organization system having a blockchain node and an application programming interface (API). The blockchain node invokes and uses a smart contract to write registration credentials to the blockchain during a registration process. During a login process, the blockchain node invokes the smart contract to determine whether login credentials match stored login credentials in the blockchain. In response to matching login credentials, the API may generate a single sign-on token that can be used by a user device to access one or more organization systems connected over the network.

Abstract: Disclosed are various embodiments for authenticating users of applications using decentralized data models for storing a user's identity. A fingerprint for a computing device is received from an application executing on the computing device. An identity key associated with the fingerprint for the computing device is then obtained, the identity key being linked to a signed claim. The signed claim is retrieved and evaluated. The application executing on the computing device access is then granted access to the computing resource in response to evaluating the signed claim.

Abstract: Disclosed are various embodiments for authenticating a user using non-fungible tokens (NFTs). A trusted token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider. For example, when a client device associated with the user requests access from an access provider to an access-restricted website or other type of access-restricted area (e.g., building, concert venue, network, etc.), the access provider (e.g., website server, building computing device, venue system, etc.) uses the properties of the non-fungible token to verify one's identity and permit access upon verification.

Abstract: Systems and methods for peer-to-peer secure document exchange are disclosed. The system may allow a document provider to securely transmit a certified document to a document verifier using decentralized storage. The verifier system may generate a session key pair and transmit the session public key to a trusted API provider. The trusted API provider may generate a session nonce. The verifier system may transmit the session nonce to the provider system. The provider system may use the session nonce to retrieve the session public key. The provider system may encrypt a certified document using the session public key and store the encrypted certified document in the decentralized storage. The verifier system may retrieve the encrypted certified document by polling the trusted API provider based on the session nonce. The verifier system may decrypt the encrypted certified document using the session private key.

Abstract: Disclosed are various approaches for managing the status of machine-learning models using distributed ledgers. A registration request for a machine-learning model can be received. The registration request can include a model name for the machine-learning model, a version identifier for the machine-learning model, a network address from which the machine-learning model can be retrieved, a source code hash for a source code version of the machine learning model, and a runtime hash for a binary executable version of the machine-learning model. A registration identifier can then be created based at least in part on the source code hash and the runtime hash. Subsequently, an entry in the distributed ledger can be created for the machine-learning model. The entry can include the registration identifier, the model name, the model version, the network address, the source code hash, and the runtime hash.

Abstract: Disclosed are various embodiments for implementing a decentralized messaging system that allows users to exchange messages via an inbox maintained through a distributed ledger. A messaging inbox can be created for a user in a distributed ledger using an inbox address that includes a string of alphanumeric numbers without an identifying domain name or identifying information about the user. Furthermore, a user may define content preferences associated with the inbox that can be used by the distributed ledger to filter content received in the inbox to minimize unwanted or undesired content provided to the user.

Abstract: Disclosed are various embodiments for metaverse authentication using NFTs. An authentication setup request for an NFT can be received from an owner of the NFT. Then, a unique authentication credential for the NFT can be requested from an NFT smart contract. In response, URL of an edge wallet associated with an owner of the unique authentication credential is received. Then, a request can be sent to the URI of the edge wallet for the unique authentication credential. In response, a signed challenge is received from the edge wallet and a public key is retrieved from the NFT. A signature of the signed challenge is determined to be valid based at least in part on the public key, and access to an asset or resource is configured based at least in part on the signature of the signed challenge being valid.

Abstract: Disclosed are various embodiments for generating payment accessibility notifications for individuals with impairments. In one non-limiting example, a system includes a first computing device configured to identify a second computing device using a wireless communication protocol in a store location. A first notification for the first computing device is activated based at least in part on an accessibility type. A user interface is displayed for receiving client data, and the client data includes a product entered by a user. An expected amount is determined for the product based at least in part on the client data and transmitted to the second computing device. A pending amount for the product is received from the second computing device. A second notification is activated for the first computing device prior to a completion of the purchase based at least in part on the pending amount and the expected amount.

Abstract: A single sign-on system using blockchain is disclosed. The single sign-on system may interconnect various organization systems over a peer-to-peer network, with each organization system having a blockchain node and an application programming interface (API). The blockchain node invokes and uses a smart contract to write registration credentials to the blockchain during a registration process. During a login process, the blockchain node invokes the smart contract to determine whether login credentials match stored login credentials in the blockchain. In response to matching login credentials, the API may generate a single sign-on token that can be used by a user device to access one or more organization systems connected over the network.

Abstract: Disclosed are various embodiments for decentralizing the authentication or verification of data. An identity key can be generated for a data item. A request can then be sent to an authentication provider for authentication of the data item, the request comprising the identity key and the data item. A verified claim for the data item can then be received in response. Subsequently, an identity document is generated, the identity document comprising the identity key for the data item and the verified claim. Finally, the identity document can be stored in a distributed ledger.

Abstract: Disclosed are various embodiments for authenticating a user using non-fungible tokens (NFTs). A trusted token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider. For example, when a client device associated with the user requests access from an access provider to an access-restricted website or other type of access-restricted area (e.g., building, concert venue, network, etc.), the access provider (e.g., website server, building computing device, venue system, etc.) uses the properties of the non-fungible token to verify one's identity and permit access upon verification.