Abstract: Disclosed are various embodiments for verifying the presentation of media represented by non-fungible tokens (NFTs). A presentation device can receive a smart contract address and a non-fungible token (NFT) identifier from a client device. The presentation device can then execute a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, wherein the NFT identifier is provided as an argument to the function of the smart contract. Subsequently, the presentation device can validate the owner address for the NFT. Then, in response to validation of the owner address for the NFT, the presentation device can present the media file represented by the NFT.

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 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: 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. An approval request to approve creation of a feature set record in a distributed ledger can be received. The approval request can include a feature set hash representing a feature set, a code hash representing a feature set generator, and a data hash representing a data set. An approval decision can be generated for the feature set record based at least in part on the approval request and at least one approval rule stored in an approval data store. The approval decision can be transmitted to a distributed agent. The approval decision can approve or reject creation of the feature set record in the distributed ledger.

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: Systems and methods for performing cross-entity load balancing operations using a distributed ledger are provided herein. An example method may include, in response to receiving a valid invocation from a first entity, and based at least in part on data associated with the valid invocation, identifying a target entity from a plurality of candidate entities.

Abstract: Systems and methods for using a virtual health wallet are provided. The wallet is created for a patient by an SSI service and is associated with a DID that is associated to the patient along with a public and private key pair. The DID of the patient is stored on a distributed ledger. The wallet is stored on a cloud-based endpoint. When a record is created for a patient by a provider, the record is stored in the wallet at the endpoint, and a DID of the record is stored in the ledger along with an address of the endpoint. Later the user may share the DID of the record with a requestor. The requestor retrieves the address of the endpoint from the ledger using the DID and requests access to the record from the wallet. The wallet verifies that the requestor has permission and provides access to the record.

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: 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: 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: 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: 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: 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 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.