System and method for conducting transactions over a network

Transaction agents in SSI systems address transaction tracking and monetization challenges, ensuring secure and private transaction processing within the SSI framework.

JP7761809B2Active Publication Date: 2025-10-28AVAST SOFTWARE +3
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2025504595
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2022-07-25
Filing Date
2023-07-17
Publication Date
2025-10-28
Estimated Expiration
2043-07-17

AI Technical Summary

Technical Problem

Current Self-Sovereign Identity (SSI) infrastructure models face limitations in securely processing transactions, particularly in tracking, recording, and monetizing usage for enhanced security and usability while preserving holder privacy.

Method used

Introduce mechanisms for tracking and monetizing SSI infrastructure and services through transaction agents that maintain separate lines of communication and tracking, enabling secure and private transaction processing without altering the core requirements of SSI infrastructure.

Benefits of technology

Facilitates secure, auditable, and monetizable transactions while protecting holder privacy by implementing transaction agents that track and bill transactions independently, enhancing system security and usability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007761809000003
    Figure 0007761809000003
  • Figure 0007761809000004
    Figure 0007761809000004
  • Figure 0007761809000005
    Figure 0007761809000005
Patent Text Reader

Abstract

A system and method for conducting transactions over a network. A first agent and a second agent are provided. The second agent is capable of transacting with a third agent for the use of a service, and the third agent is capable of communicating with a fourth agent. The first agent is operable to communicate with the second agent to facilitate a transaction for the use of the service by the second agent with the third agent. The first agent is further operable to communicate with the fourth agent to facilitate a transaction for the use of the service by the second agent with the third agent.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates generally to digital communications, and more particularly to conducting transactions over a network.

[0002] Self-sovereign identity ("SSI") is a concept or model that allows individuals to control their digital identities. SSI systems are generally decentralized, allowing holders (e.g., individuals or organizations) to generate and maintain unique identifiers known as decentralized identifiers ("DIDs"). Credentials issued by an entity, usually an organization, acting as an issuer are provided by a specific party ("holder") to another party ("verifier") to verify the identity information contained within the specific party's credential. The SSI infrastructure used by issuers, verifiers, and holders is typically open source, but leverages many proprietary standards for elements of the technology stack. SSI infrastructure providers provide proprietary software, such as applications that process transactions. Summary of the Invention

[0003] This Summary is intended to introduce simplified concepts that are described below in the Detailed Description of Exemplary Embodiments. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] A method for conducting transactions on a network is provided. The method includes receiving a digitally signed transaction by a first agent from a second agent, the digitally signed transaction being received by the second agent from a third agent and including a digital signature. A first verifiable proof is received by the first agent from a fourth agent. The first verifiable proof is transmitted by the first agent to a fifth agent. The first agent receives an unlocking signature from the fifth agent for a locked credential provided by a sixth agent to the second agent. The first agent transmits the unlocking signature to the fourth agent.

[0005] A further method for conducting transactions on a network is provided. The further method includes receiving a first transaction by a first agent from a second agent, the first transaction being initiated by a third agent. The first agent transmits a first verifiable proof to a fourth agent. The first agent receives a credential signature for a verifiable credential including one or more data points from the fourth agent, the verifiable credential including one or more data points provided by a fifth agent to the second agent for the first transaction. The credential signature is transmitted by the first agent to the second agent.

[0006] Another method for conducting transactions on a network is provided in which a first agent sends a request to a second agent to initiate use of a service. The first agent receives a request for one or more data points to initiate use of the service from the second agent. The first agent sends one or more requirements to satisfy the one or more data points to the second agent. The first agent receives a digitally signed transaction from the second agent, the digital signature included therein. The first agent sends the digitally signed transaction to a third agent. The first agent receives an indication from the third agent that a first verifiable proof for the digitally signed transaction has been received, and the first agent sends a second verifiable proof to the second agent. The second verifiable proof is based on a verifiable credential including the one or more data points.

[0007] A system for conducting transactions over a network is provided. The system includes a first agent and a second agent. The second agent is operable to transact with a third agent to utilize a service. The third agent is capable of communicating with a fourth agent. The first agent is operable to communicate with the second agent to facilitate the transaction with the third agent to utilize the service by the second agent. The first agent is further operable to communicate with the fourth agent to facilitate the transaction with the third agent to utilize the service by the second agent.

[0008] A further system for conducting transactions on a network is provided. The further system includes a first agent and a second agent. The first agent is operable to receive a digitally signed transaction from the second agent, the digitally signed transaction being received by the second agent from a third agent and including a digital signature. The first agent is also operable to receive a first verifiable proof from the fourth agent and transmit the first verifiable proof to a fifth agent. The first agent is further operable to receive an unlock signature from the fifth agent for a locked credential provided to the second agent by a sixth agent and transmit the unlock signature to the fourth agent. The second agent is operable to transmit a request to initiate use of a service to the third agent and to receive from the third agent a request for one or more data points for initiating use of the service. The second agent is also operable to transmit to the third agent one or more requirements for satisfying the one or more data points and to receive the digitally signed transaction from the third agent. The second agent is further operable to send a second verifiable proof to the third agent, the second verifiable proof being based on the locked credential and including the one or more data points.

[0009] Another system for conducting transactions over a network is provided, the system including a first agent and a second agent. The first agent is operable to receive a first transaction and a second transaction from the second agent, where the first transaction is initiated by a third agent and the second transaction includes identification data of a fifth agent. The first agent is also operable to receive an indication from the second agent that a verifiable credential has been received by the second agent, the verifiable credential including one or more data points provided by the fifth agent to the second agent for the first transaction. The first agent is further operable to transmit a first verifiable proof based on the second transaction to a fourth agent in response to the first agent receiving the indication from the second agent that the verifiable credential has been received by the second agent. The first agent is further operable to receive a credential signature for the verifiable credential from the fourth agent and transmit the credential signature to the second agent. The second agent is operable to send a request for a verifiable credential to the fifth agent, the request for the verifiable credential including the second transaction. The second agent is further operable to provide the entity identification information to the fifth agent and to receive the verifiable credential from the fifth agent.

[0010] Yet another system is provided for conducting transactions over a network, the system including a first agent and a third agent. The first agent is operable to send a request to initiate use of a service to a second agent, receive a request for one or more data points for initiating use of the service from the second agent, and send one or more requirements for satisfying the one or more data points to the second agent. The first agent is further operable to receive a digitally signed transaction from the second agent, the digital signature included, and send the digitally signed transaction to the third agent. The first agent is further operable to receive from the third agent an indication that a first verifiable proof of the digitally signed transaction has been received and send a second verifiable proof to the second agent, the second verifiable proof being based on a verifiable credential including the one or more data points. The third agent is operable to receive the first verifiable proof from a fourth agent and send an indication that the first verifiable proof of the digitally signed transaction has been received to the first agent.

[0011] Yet another method for conducting a transaction on a network is provided. The method includes sending a request to initiate a service by a second agent to a third agent. The second agent receives a request for one or more data points for initiating the service from the third agent and sends a request for a locked credential to a sixth agent in response to the request for the one or more data points from the third agent. The second agent receives the locked credential from the sixth agent and sends one or more requirements for satisfying the one or more data points to the third agent. The second agent receives a digitally signed transaction from the third agent, the transaction including a digital signature. The first agent receives the digitally signed transaction from the second agent. The second agent sends a second verifiable proof to the third agent, the second verifiable proof being based on the locked credential and including the one or more data points. The fourth agent receives the digitally signed transaction and the second verifiable proof from the third agent. The first agent receives a first verifiable proof from the fourth agent and transmits the first verifiable proof to a fifth agent. The first agent receives an unlock signature for the locked credential from the fifth agent and transmits the unlock signature to the fourth agent. The fourth agent transmits the unlock signature to the third agent.

[0012] Yet another method for conducting a transaction over a network is provided, the method including: sending a request to initiate use of a service by a second agent to a third agent; the second agent receiving a request for one or more data points to initiate use of the service from the third agent; the second agent sending a request for a verifiable credential including the one or more data points to a fifth agent, the request for the verifiable credential including a second transaction; the fourth agent receiving the second transaction from the fifth agent; the first agent receiving a first transaction from the second agent, the first transaction initiated by the third agent; the first agent receiving a second transaction from the second agent, the second transaction including identification data of the fifth agent; the second agent providing entity identification information to the fifth agent; and the second agent receiving the verifiable credential including the one or more data points from the fifth agent. The first agent receives an indication from the second agent that the verifiable credential has been received by the second agent. In response to the first agent receiving the indication from the second agent that the verifiable credential has been received by the second agent, the first agent transmits a first verifiable proof based on the second transaction to the fourth agent. A credential signature for the verifiable credential is transmitted by the fourth agent to the first agent based on the second transaction and the first verifiable proof. The first agent transmits the credential signature to the second agent. The second agent transmits a second verifiable proof including one or more data points based on the credential signature and the verifiable credential to the third agent. The sixth agent receives an indication from the third agent that the second verifiable proof has been received by the third agent.The first agent receives an indication from the sixth agent that the second verifiable proof has been received by the third agent, and the first agent sends an indication to the second agent that the second verifiable proof has been received by the third agent. [Brief explanation of the drawings]

[0013] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: Figures of the drawing and detailed description are exemplary; they are not to be considered limiting, as other embodiments are possible; Like reference numerals in the figures indicate like elements.

[0014] [Figure 1] FIG. 1 illustrates the process flow and system in which a data artifact is provided by an issuer to a holder agent and verified by a verifier agent. [Figure 2] FIG. 2 illustrates a Self-Sovereign Identity (“SSI”) system and the corresponding infrastructure layer, transaction agent layer, and base layer. [Figure 3] FIG. 3 shows that a data artifact is provided by an issuer to a holder agent and verified by a verifier agent, with the transaction facilitated by a transaction agent. [Figure 4] FIG. 4 illustrates a transaction scheme system that includes multiple systems enabling issuer, holder, and verifier agents, respectively, and enabling issuer, holder, and verifier transaction agents, respectively. [Figure 5A] FIG. 5A illustrates the process flow and system that enables trading on the network via transaction agents. [Figure 5B] FIG. 5B illustrates the process flow and system that enables trading on the network via transaction agents. [Figure 6A]FIG. 6A illustrates the process flow and system that enables trading on the network via transaction agents. [Figure 6B] FIG. 6B illustrates the process flow and system that enables trading on the network via transaction agents. [Figure 7] FIG. 7 illustrates the process flow and system that enables trading on the network via transaction agents. [Figure 8] FIG. 8 illustrates a computer system for performing the described methods, according to an exemplary embodiment.

[0015] Current Self-Sovereign Identity ("SSI") infrastructure models have limitations with regard to securely processing transactions. For security and monetization purposes, it is desirable to track, record, and audit SSI transactions. This specification describes systems and methods that introduce mechanisms for tracking and monetizing usage of SSI infrastructure and services built on the SSI infrastructure. The systems and methods described herein do not require changes to the core requirements of SSI infrastructure, including verifiable credentials and the structure and use of verifiable credentials within SSI exchanges.

[0016] The terms used herein are as follows:

[0017] An "issuer" is an entity that issues a verifiable credential or data artifact.

[0018] A "holder" is an entity that possesses a verifiable credential or data artifact provided by an issuer entity.

[0019] A "verifier" is an entity that verifies a data artifact provided by an owner as part of a transaction, and is a provider of a service with which the owner wishes to engage.

[0020] A "contract" defines what data artifacts are required from an entity requesting a service before the provider will provide the service to that entity.

[0021] A "transaction agent" is an application component that provides the functionality to track, communicate, aggregate, and interface with credential-based transactions.

[0022] A "transaction agent service provider system" is a system (e.g., a software or hardware system) that hosts one or more transaction agents and one or more transaction ledgers on behalf of holders, issuers, or validators that choose to implement the system. A transaction agent service provider system can play different roles for issuers, holders, and validators. A transaction agent service provider system is also referred to as a "transaction agent provider," "payment infrastructure," or "platform provider."

[0023] "Payment agent" means a transaction agent that provides payment functionality.

[0024] A "sponsor" is an entity that sponsors (e.g., pays for) the issuance of a verifiable credential, thereby granting credit to the user. The sponsor may be entitled to a portion of the verifier's payment for verifying the credential. The sponsor may be a separate entity, or may play the role of issuer, the role of the holder's transaction agent service provider system, or the role of verifier.

[0025] A "locked credential" is a verifiable credential (VC) that can be shared by a holder but cannot be verified by a verifier without unlocking. Unlocking can be cryptographic (e.g., the verifier must receive a cryptographic key to unlock the credential's contents or portions of the contents) or policy-based (e.g., the verifier's agent adheres to a policy and unlocks the credential for verification only after procedural conditions are met, such as payment being verified).

[0026] An "unlocked credential" is a verifiable credential that was previously obtained from an issuer and can be shared by a holder, and can be used multiple times by the holder for use in a transaction requiring the credential, without paying a fee to the issuer or notifying the issuer of such use.

[0027] A "co-protocol" is an interaction between two entities (e.g., a holder, a verifier, or an issuer) in a payment scheme for an action requiring a payment.

[0028] A "use case" is a real-world example of how users, consumers, and computers interact with a service and a service provider.

[0029] A "transaction scheme" or "payment scheme" is a set of interactions between entities in a transactional agent system to accomplish a use case.

[0030] "Transaction" or "txn" refers to an exchange between two parties, whether for a fee or for free, involving, for example, a service provided by one party to another requester, such as a purchase order.

[0031] A "cryptographic system flow" is a system flow that describes a transaction data exchange in which the protections provided by the system are cryptographically enforced, i.e., a verifiable credential cannot be used in a transaction without the cryptographic proof necessary to verify a signature on the credential.

[0032] "Policy system flow" means a system flow that describes transaction data exchange, and the protections provided by the system are enforced by policies that are defined and deployed throughout the system, i.e., a verifiable credential cannot be used in a transaction without verification that the credential complies with policies agreed upon among entities in the system.

[0033] As described herein, references to a "first," "second," or "third" component (e.g., a "first agent," a "second agent"), or a "particular" or "certain" component or implementation (e.g., a "particular user," a "certain user," a "particular computing device," a "particular implementation") are not used to imply a sequential or numerical limitation or limitation of quality, but rather are used to distinguish or identify various components and implementations.

[0034] 1, a process flow and system 200 effective in a network environment is shown. A third-party data artifact issuer 24, e.g., a community of data artifact issuers 24, provides a data artifact (e.g., a verifiable credential) to a holder agent 42. The holder agent 42 may be provided in the form of a software agent that includes software encompassing a digital wallet that holds the issued data artifact belonging to a user (i.e., a "holder") of the holder agent 42, as well as software applications and a network stack necessary to support use of the digital wallet.

[0035] The primary issuer 32 may also provide data artifacts to the holder agent 42. The composite issuer 34 works with other issuers, including third-party data artifact issuers 24 and ID&V entities 26 within the ID&V (Identification and Authentication) community, to create data artifacts for the holder agent 42. The gateway issuer 36 issues data artifacts to the holder agent 42 on behalf of the ID&V entities 26. The primary issuer 32, composite issuer 34, and gateway issuer 36 may be enabled, for example, by the same entity that enables the software agents that form the holder agent 42. The verifier agent 52 interfaces with the holder agent 42 to verify the data artifacts.

[0036] Referring to FIG. 2 , a self-sovereign identity (“SSI”) system 300 is provided. For privacy reasons, when implementing a verifiable credential, it is undesirable for the holder and issuer (e.g., via holder agent 42 and issuer agent 22) to communicate directly. For illustrative purposes, if a driver's license issued by one state's Department of Motor Vehicles (“DMV”) is the verifiable credential and is used by the holder to gain access to various nightclubs, the holder may not want the DMV to know that they went to the nightclub in order to verify their driver's license. The SSI system 300 supports holder privacy via the transaction layer 304 by allowing the holder via the holder agent 42 to use the verifiable credential (even a locked credential) without the issuer of the credential knowing where the credential was used. The SSI system 300 further supports cryptographically tracking proof of transaction via the transaction layer 304, e.g., for purposes of auditing and tracking payments associated with the transaction.

[0037] Base layer 302 defines the base components of SSI system 300. Transaction layer 304 defines the components that handle payment processing related to a transaction and includes issuer transaction agent 62, holder transaction agent 72, and verifier transaction agent 82. Infrastructure layer 306 defines the services needed to support base layer 302 and transaction layer 304. The infrastructure layer includes issuer transaction infrastructure 90, holder transaction infrastructure 92, and verifier transaction infrastructure 94.

[0038] The base layer includes an issuer agent 22, which may include one or more of a third-party data artifact issuer 24, an ID&V entity 26, a primary issuer 32, a composite issuer 34, or a gateway issuer 36. The initiation of a transaction occurs when a holder, corresponding to a holder agent 42, with an existing issued verifiable credential desires and attempts to use a verified service. Data flow between the holder agent 42, the verifier agent 52, and one or more transaction agents 62, 72, 82 occurs on a pay-per-transaction basis.

[0039] A challenge for SSI system 300 arises when a provider of software and services enabling transactions or services through SSI system 300 wants to track, audit, and monetize the transactions or services, for example, to enhance the security and usability of the system and protect the privacy of credential holder usage. Referring to Figures 2 and 3, as a solution to the challenge, the transaction agent architecture introduces three functional roles into the process flow and system 200 defined in SSI system 300 and enabling process flow and system 400. The three functional roles include transaction agent roles realized by issuer transaction agent 62, holder transaction agent 72, and verifier transaction agent 82.

[0040] The issuer transaction agent 62 provides the issuer agent 22 with tracking of transactions in which it is involved, including monetization, by returning transactions to the issuer agent 22 based on holder and verifier transactions (via the holder agent 42 and the verifier agent 52, respectively) without the issuer's involvement in the transaction (via the issuer agent 22). The issuer agent 22 may include one or more of a third-party data artifact issuer 24, an ID&V entity 26, a primary issuer 32, a composite issuer 34, or a gateway issuer. The holder transaction agent 72 provides tracking of transactions in which it is involved, including monetization by the holder agent 42 (e.g., a software agent) back to providers of services that enable the holder agent 42 (e.g., software agent services), such as security service providers. The verifier transaction agent 82 provides transaction monetization to the verifier agent 52, including transaction billing and tracking services for transactions in which it is involved. The issuer transaction agent 62, holder transaction agent 72, and verifier transaction agent 82 maintain separate lines of communication and tracking to enable security and usability of the system and to protect the privacy of holder credential usage.

[0041] The process flow and system 400 includes a transaction-by-transaction flow represented by steps 402 through 414. In step 402, a holder agent 42 sends a transaction, including, for example, a verifiable credential of the holder of the holder agent 42, to a verifier agent 52. The verifier agent 52 signs the transaction and verifies the transaction with the holder agent 42. 42(step 404). The holder agent 42 sends the signed transaction to the holder transaction agent 72 (step 406). The holder transaction agent 72 then sends the signed transaction to, for example, the verifier agent 52 The holder transaction agent 72 then applies the public key of the verifier agent 52 to verify the signature (step 408). The holder transaction agent 72 creates a transaction ledger entry (step 410). The holder transaction agent 72 sends proof of the transaction (the "transaction proof") back to the holder agent 42 (step 412). The holder agent 42 then sends the transaction proof to the verifier agent 52 (step 414).

[0042] The process flow and system 400 further includes an asynchronous batch process flow and system, represented by steps 450 through 454. In step 450, the holder transaction agent 72 sends an invoice to the verifier transaction agent 82. The verifier transaction agent 82 sends payment to the holder transaction agent 72 (step 452), which pays the issuer transaction agent 62 (step 454).

[0043] 4, an exemplary transaction scheme system 500 (e.g., a payment scheme system) in accordance with SSI system 300 is provided. Transaction scheme system 500 enables cryptographic tracking of transaction proofs, for example, for purposes of auditing and tracking payments associated with the transaction. Transaction scheme system 500 enables a continuous flow of data between issuer agent 22, holder agent 42, verifier agent 52, issuer transaction agent 62, holder transaction agent 72, and verifier transaction agent 82. Transaction scheme system 500 can be implemented over a network of, for example, a local area network (LAN), a wide area network (WAN), the Internet, a cellular network, Wi-Fi, TM The present invention is capable of operating in a computer network that may include one or more wired or wireless networks, or a combination thereof, including over wireless data networks such as cellular networks and 3G / 4G / 5G cellular networks.

[0044] The issuer transaction agent service provider system 60 includes an issuer transaction agent 62 and an issuance ledger 66 for recording record-keeping communications from the issuer transaction agent 62 and making the record-keeping communications accessible to the issuer transaction agent 62. The issuer transaction agent service provider system 60 further includes an issuer agency transaction agent 64 for sending and receiving agency-related communications.

[0045] The holder transaction agent service provider system 70 includes a holder transaction agent 72 and a transaction ledger 76 for recording record-keeping communications from the holder transaction agent 72 and making the record-keeping communications accessible to the holder transaction agent 72. The holder transaction agent service provider system 70 further includes a holder agency transaction agent 74 for sending and receiving agency-related communications to and from the issuer agency transaction agent 64 and the verifier agency transaction agent 84.

[0046] The verifier transaction agent service provider system 80 includes a verifier transaction agent 82 and a verified ledger 86 for recording record-keeping communications from the verifier transaction agent 82 and making the record-keeping communications accessible to the verifier transaction agent 82. The verifier transaction agent service provider system 80 further includes a verifier agency transaction agent 84 for sending and receiving agency-related communications to and from the holder agency transaction agent 74.

[0047] A networkable processor-enabled issuer system 20 enables an issuer agent 22. A networkable processor-enabled holder device 40 enables a holder agent 42. The holder agent 42 may be provided to the holder device 40, for example, as a standalone application or as a plug-in, add-on, or extension to an existing application, for example, a web browser. A networkable processor-enabled verifier system 50 enables a verifier agent 52. The verifier agent 52 may be provided to the verifier system 50, for example, as a standalone application or as a plug-in, add-on, or extension to an existing application, for example, a web browser plug-in.

[0048] The data flows enabled by the transaction scheme system 500 include those shown in Table 1 below.

[0049] [Table 1]

[0050] A set of co-protocols are defined herein for use as part of a payment scheme within a transaction agent system, including SSI system 300. The described co-protocols track and monetize the use of verifiable credentials during use of SSI system 300 in multiple scenarios. The described co-protocols support real-time tracking of transactions in which verifiable credentials are used, regardless of the costs or payments required to support those transactions. Co-protocols can be categorized into either a credential payment category or a service payment category.

[0051] The credential payment category is where payment occurs during or after the use of a transaction credential. The service payment category is where payment occurs during or after the use of a service engaged by the holder from the service provider. Except for specific service provision use cases described below, it is assumed that verifiers do not receive payment for participating in the use of the SSI infrastructure. For use cases in the credential payment category, benefits to verifiers include higher quality data, reduced data acquisition costs, and reduced transaction friction.

[0052] In an exemplary first co-protocol corresponding to the credential payment category, a holder agent 42 requests a verifiable credential from an issuer agent 22, which requests payment before issuance. In the first co-protocol, the holder of the holder agent 42 is the payer, and the issuer agent 22 is the payee. For example, a holder (e.g., a consumer) implementing the holder agent 42 wishes to use a service on the Internet that requires a particular verifiable credential from an issuer implementing the issuer agent 22, the holder must pay to obtain the verifiable credential before initiating a transaction with the service, and the service implements the verifier agent 52.

[0053] In an exemplary second co-protocol corresponding to the credential payment category, a holder agent 42 requests a service as part of a transaction requiring a verifiable credential, and an issuer agent 22 requires payment before the issuer agent 22 provides an unlocking signature that enables a verifier agent 52 implemented by the service to use the verifiable credential. In the second co-protocol, the verifier of the verifier agent 52 is the payer, and the issuer agent 22 is the payee. For example, a subscription media streaming service (Netflix) implementing a verifier agent 52 may TM ) pays the publisher agent 22, which provides the consumer's (holder of the holder agent 42) credential information to be used as part of the subscription sign-up process.

[0054] In an exemplary third co-protocol corresponding to the credential payment category, a service is used by a holder of a holder agent 42 in a transaction with a verifier of a verifier agent 52 requiring a verifiable credential, and a system provider of the holder agent 42 requests payment for use of the SSI system 300 as part of the transaction. In the third co-protocol, the verifier of the verifier agent 52 is the payer, and the system provider of the holder agent 42 is the payee. For example, a credit card company system provides a service to a holder of the holder agent 42 (e.g., a consumer), and the credit card company system receives payment from a verifier of the verifier agent 52 (e.g., a product or service vendor).

[0055] In an exemplary fourth co-protocol corresponding to the credential payment category, the service is used by a holder of a holder agent 42 in a transaction with a verifier of a verifier agent 52 that requires a verifiable credential already in the holder agent's 42's possession, and the holder receives payment from the verifier for providing the verifiable credential. In the fourth co-protocol, the verifier of a verifier agent 52 is the payer and the holder of a holder agent 42 is the payee. For example, the holder is a loyalty program purchaser, and the verifier (e.g., a loyalty program administrator) pays the holder to provide the verifiable credential as part of a verified purchase transaction under the loyalty program.

[0056] In an exemplary fifth co-protocol corresponding to the service payment category, a service provided by a verifier of verifier agent 52 is used by a holder of holder agent 42, who wishes to pay for the service using the same transaction tracking mechanism used for credential tracking, in exchange for using that mechanism for service tracking. In the fifth co-protocol, the holder of holder agent 42 (e.g., a buyer) is the payer, and the verifier of verifier agent 52 (e.g., a seller) is the payer. For example, a holder of holder agent 42 (e.g., a consumer) may pay for a subscription media streaming service (e.g., Netflix) through a payment mechanism. TM ) and wishes to pay for their subscription media streaming services using a transaction agent system that includes SSI system 300.

[0057] In an exemplary sixth co-protocol corresponding to the service payment category, a service provided by a verifier at verifier agent 52 is used by a holder at holder agent 42. This service allows for a variety of payment mechanisms supported by the verifier, but the holder would like to be able to choose which payment method is preferred during a particular transaction between the holder and the verifier. 6 In the co-protocol, the holder (e.g., buyer) of the holder agent 42 is the payer, and the verifier (e.g., seller) of the verifier agent 52 is the payer. For example, if a holder (e.g., consumer) of the holder agent 42 pays for a subscription media streaming service (e.g., Netflix), TM ), and use a third-party payment service (e.g., PayPal) instead of a credit card while using the same transaction agent system (e.g., SSI system 300) that was used to establish the subscription. TM ) to pay for subscription media streaming services.

[0058] In an exemplary seventh co-protocol corresponding to the credential payment category, the holder agent 42 requests a verifiable credential from the issuer agent 22, which requires payment before issuance. 7 In the co-protocol, the holder sponsor of the holder agent 42 is the payer and the issuer agent 22 is the payee.

[0059] A variety of payment schemes are supported by transaction agent systems including SSI system 300. The payment schemes described rely on the same architectural components included in SSI system 300 and highlight how the architectural components interact with each other as part of a transaction to support various co-protocols that can be combined to support a payment scheme.

[0060] Three exemplary payment schemes are summarized in Table 2. [Table 2]

[0061] The example payment scheme in Table 2 describes two scenarios. The first scenario describes how the payment scheme supports the establishment of a new verifiable credential, and the second scenario describes how a subsequent transaction leverages an existing verifiable credential (locked or unlocked). In the third payment scheme, the second payment scheme is used to make a payment for the new verifiable credential before proceeding to the third payment scheme. Beneficial prerequisites for the first, second, and third payment schemes include the existence of issuer agent 22, holder agent 42, and verifier agent 52 to support the SSI infrastructure of SSI system 300, and the existence of a transaction infrastructure including transaction agents 62, 72, and 82.

[0062] Below are four example use cases defined to highlight the relative advantages and disadvantages of each payment scheme in Table 2. The first use case involves providing identity proof to sign up for an online service. The second use case involves providing education proof for an employment application. The third use case involves providing age proof to access a social club. The fourth use case involves providing proof of authorized purchase of a particular product when the user (i.e., the purchaser) writes a product / service review.

[0063] In the first payment scheme of Table 2, the verifier pays the issuer for each validation of a locked credential. The first payment scheme implements a transaction agent in the credential validation process. The payment terms of the first payment scheme include a requirement to pay for each validation of a transaction. With reference to FIGS. 5A and 5B, two exemplary scenarios in which the first payment scheme is applied are represented by process flow and system 600 and process flow and system 700, respectively. In process flow and system 600 of FIG. 5A, a new verifiable credential is requested from issuer agent 22. Prerequisites for process flow and system 600 include a requirement that holder agent 42 not possess a previous verifiable credential. In process flow and system 700 of FIG. 5B, holder agent 42 already possesses a verifiable credential previously received from issuer agent 22.

[0064] The process flows and systems 600, 700 enable a method for conducting transactions over a network via multiple agents, including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. As described with respect to the process flows and systems 600 and 700, the first agent is depicted as a holder transaction agent 72, the second agent is depicted as a holder agent 42, the third agent is depicted as a verifier agent 52, the fourth agent is depicted as a verifier transaction agent 82, the fifth agent is depicted as an issuer transaction agent 62, and the sixth agent is depicted as an issuer agent 22. The depiction of multiple agents with respect to the process flows and systems 600, 700 is exemplary in nature, and the process flows and systems 600, 700 are not limited by the specific naming of each agent.

[0065] Referring to FIG. 5A, a process flow and system 600 useful in a network environment is shown. A holder, via a holder agent 42 (i.e., a second agent), wishes to initiate a transaction to utilize a service from a provider, and a provider, acting as a verifier, via a verifier agent 52 (i.e., a third agent), wishes to verify the holder. The holder agent 42 requests a service from the verifier agent 52 (step 602). The verifier agent 52 specifies to the holder agent 42 in a request for data related to the transaction (e.g., a presentation request) which of one or more data points, such as attributes related to the transaction (e.g., attributes of a verifiable credential), are required (step 604), where the one or more data points define the terms of the transaction (e.g., a contract), similar to, for example, contract terms. The data points may include, for example, one or more of the holder's first name, last name, date of birth, credit card number, social security number, or passport number. Holder agent 42 requests a verifiable credential from issuer agent 22 (i.e., the sixth agent) in response to the data request from verifier agent 52 (step 606). Holder agent 42 does not need to disclose the identity of verifier agent 52 to issuer agent 22 in its request, but holder agent 42 may provide the data points requested by verifier agent 52.

[0066] The holder agent 42 and issuer agent 22 interact to satisfy the conditions that must be met for the issuer agent 22 to issue the requested verifiable credential based on the use case, credential type, and assurance level (step 608). For example, ( "KYC" )For a (know-your-client) type verifiable credential, the holder of the holder agent 42 may be required to present a driver's license or other ID along with their face on camera. The issuer agent 22 sends the holder's locked credential (i.e., the locked verifiable credential) and a cryptographic commitment, which is information that allows the transaction agent to pay a fee for verification, to the holder agent 42 (step 610). The cryptographic commitment is related to the locked credential and contains information that the verifier agent 52 uses to contact the issuer agent 22. The cryptographic commitment can be provided as a partial signature of the locked credential, ensuring that the locked credential is usable by the holder agent 42 and allowing the verifier agent 52 to verify the locked credential after payment or other requirements via the verifier transaction agent 82 are completed. The cryptographic commitment can include cost information and payment information regarding the cost of the locked credential.

[0067] The holder agent 42 sends a response (e.g., a response to the presentation request) to the verifier agent 52 (step 612) that includes one or more requirements for the data requested by the holder agent 42 to satisfy one or more data points for the initiated transaction (e.g., a contract). The one or more requirements provided by the holder agent 42 may include, for example, one or more of a price, a service level agreement ("SLA"), or a policy for the requested data. If the one or more requirements are acceptable to the verifier agent 52, the verifier agent 52 responds by updating the transaction to generate a signed transaction confirming that the one or more requirements are accepted, and the verifier agent 52sends a response including the signed transaction to holder agent 42 (step 614). The signed transaction includes data of issuer agent 22 (e.g., the digital identity of issuer agent 22).

[0068] The signed (i.e., “updated”) transaction, including data about issuer agent 22 (e.g., the digital identity of issuer agent 22), obtained by holder agent 42 from verifier agent 52 in step 614, and the cryptographic commitment obtained by holder agent 42 from issuer agent 22 in step 610, are sent by holder agent 42 to holder transaction agent 72 (i.e., the first agent) (step 616). The holder transaction agent 72 beneficially verifies the signature of the signed transaction, for example, by applying a public key associated with verifier agent 52 (step 617). The signed (i.e., “updated”) transaction received by holder transaction agent 72 from holder agent 42 in step 616 is written by holder transaction agent 72 to transaction ledger 76 (step 618). A confirmation of the storage of the signed transaction in the transaction ledger 76 is sent by holder transaction agent 72 to holder agent 42 (step 620). Holder agent 42 sends to verifier agent 52 a locked verifiable proof based on (e.g., including) the locked credential, including one or more data points (a "data point proof") requested by verifier agent 52 (step 622). The data point proof includes a presentation of the requested one or more data points and one or more locked proofs associated with the requested one or more data points.

[0069] Holder agent 42 confirms to holder transaction agent 72 (step 624) that verifier agent 52 has been sent the datapoint proof, thereby making the payment portion of the transaction available through action by holder transaction agent 72. Verifier agent 52 sends the signed transaction and the datapoint proof received from holder agent 42 to verifier transaction agent 82 (i.e., the fourth agent) (step 626).

[0070] The verifier transaction agent 82 stores the signed transaction and data point proof in the verified ledger 86 (step 628), triggering payment initiation. The verifier transaction agent 82 sends the payment to the issuer agent 22 and a payment certificate to the holder transaction agent 72 (step 630). Holder Transaction Agent 72 The issuer agent 22's payment and payment certificate ("payment certificate"), which de-identifies the payment and payment certificate and does not disclose the identity of the payer, is relayed by the holder transaction agent 72 to the issuer transaction agent 62 (i.e., the fifth agent) (step 632). The issuer transaction agent 62 stores the payment certificate in the issuance ledger 66 (step 634) so ​​that it can send an unlock signature for the locked credential associated with the data point certificate back to the verifier agent 52 via the holder transaction agent 72 and the verifier transaction agent 82.

[0071] The issuer transaction agent 62 sends the unlock signature for the locked credential associated with the data point proof associated with the signed transaction to the holder transaction agent 72 for relay to the verifier agent 52 (step 636). transaction agent 6 2 to the verifier transaction agent 82 (step 638). The verifier transaction agent 82 then Holdings person transaction agent 7 2 to the verifier agent 52 to unlock the data point proof associated with the signed transaction (step 640). The verifier agent 52 then uses the unlock signature of the locked credential to unlock the data point proof received from the holder agent 42 for the signed transaction (step 642). 。

[0072] The verifier agent 52 sends a notification to the verifier transaction agent 82 that the transaction has been successfully completed (step 644), allowing the verifier transaction agent 82 to relay the completion status and update the verified ledger 86 with the completion status. The verifier transaction agent 82 updates the verified ledger 86 with the completion status (step 646). The verifier transaction agent 82 notifies the holder transaction agent 72 that the transaction has been completed (step 648). The holder transaction agent 72 then updates the transaction ledger 76 with the completion status (step 650).

[0073] The holder transaction agent 72 notifies the holder agent 42 that the transaction is complete (step 652), and the holder agent 42 may choose to display an update to the user or system. The holder transaction agent 72 notifies the issuer transaction agent 62 that the transaction is complete (step 654), and the issuer transaction agent 62 updates the issuance ledger 66 with the completion status (step 656).

[0074] Steps 618, 620, 624, and 628 provide an additional level of completeness that ensures that SSI system 300 can detect problems and / or indicate progress throughout the process flow and flow sequence of system 600. A system implementation may choose to skip one or more of steps 618, 620, 624, and 628 for optimization purposes without losing the overall outcome of the transaction.

[0075] Referring to FIG. 5B, a process flow and system 700 useful in a network environment is shown. A holder, via a holder agent 42 (i.e., a second agent), wishes to initiate a transaction to utilize a service from a provider, and a provider, acting as a verifier, via a verifier agent 52 (i.e., a third agent), wishes to verify the holder. The holder agent 42 requests the service from the verifier agent 52 (step 702). In a request for transaction data (e.g., a presentation request), the verifier agent 52 specifies to the holder agent 42 which of one or more data points, such as attributes related to the transaction (e.g., attributes of a verifiable credential), are required (step 704), where the one or more data points define the terms of the transaction (e.g., a contract), similar to, for example, contract terms. The data points may include, for example, one or more of the holder's first name, last name, date of birth, credit card number, social security number, or passport number.

[0076] The holder agent 42 sends a response (e.g., a response to the presentation request) to the verifier agent 52 including one or more requirements regarding the data requested by the holder agent 42 to satisfy one or more data points of the initiated transaction (e.g., a contract) (step 706). The one or more requirements provided by the holder agent 42 may include, for example, one or more of a price, a service level agreement ("SLA"), or a policy for the requested data. If the one or more requirements are acceptable to the verifier agent 52, the verifier agent 52 responds by updating the transaction to generate a signed transaction confirming that the one or more requirements are accepted, and the verifier agent 52 sends a response including the signed transaction to the holder agent 42 (step 708). The signed transaction includes data of the issuer agent 22 (e.g., the digital identity of the issuer agent 22).

[0077] The signed (i.e., “updated”) transaction obtained by the holder agent 42 from the verifier agent 52 in step 708, which includes data about the issuer agent 22 (e.g., the digital identity of the issuer agent 22) and a cryptographic commitment previously obtained from the issuer agent 22, is sent by the holder agent 42 to the holder transaction agent 72 (step 710). The holder transaction agent 72 beneficially verifies the signature of the signed transaction, e.g., by applying a public key associated with the verifier agent 52 (step 711). The signed (i.e., “updated”) transaction received by the holder transaction agent 72 from the holder agent 42 in step 710 is written by the holder transaction agent 72 to the transaction ledger 76 (step 712). A confirmation of the storage of the signed transaction in the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 714). Holder agent 42 sends to verifier agent 52 (step 716) a locked verifiable proof based on (e.g., including) the locked credential, including one or more data points requested by verifier agent 52 (the "data point proof"). The data point proof includes a presentation of the one or more requested data points and a locked proof associated with the requested data points.

[0078] Holder agent 42 confirms to holder transaction agent 72 (step 718) that verifier agent 52 has been sent the datapoint proof, and the payment portion of the transaction is then made available by action of holder transaction agent 72. Verifier agent 52 sends the signed transaction and the datapoint proof received from holder agent 42 to verifier transaction agent 82 (i.e., the fourth agent) (step 720).

[0079] The verifier transaction agent 82 stores the signed transaction and data point proof in the verified ledger 86 (step 722), triggering payment initiation. The verifier transaction agent 82 sends the payment to the issuer agent 22 and a payment certificate to the holder transaction agent 72 (step 724). Holder Transaction Agent 72 The payment and payment certificate to the issuer agent 22 ("payment certificate"), which de-identifies the payment and payment certificate and does not disclose the identity of the payer, is relayed by the holder transaction agent 72 to the issuer transaction agent 62 (step 726). The issuer transaction agent 62 stores the payment certificate in the issuance ledger 66 (step 728) and can send an unlock signature for the locked credential associated with the data point certificate back to the verifier agent 52 via the holder transaction agent 72 and the verifier transaction agent 82.

[0080] The issuer transaction agent 62 sends the unlock signature for the locked credential associated with the data point proof associated with the signed transaction to the holder transaction agent 72 for relay to the verifier agent 52 (step 730). transaction agent 6 2 to the verifier transaction agent 82 (step 732). The verifier transaction agent 82 Holdings person transaction agent 7 2 to verifier agent 52 to unlock the data point proof associated with the signed transaction (step 734). Verifier agent 52 then uses the unlock signature for the locked credential to unlock the data point proof received from holder agent 42 for the signed transaction (step 736).

[0081] The verifier agent 52 sends a notification to the verifier transaction agent 82 that the transaction has been successfully completed (step 738), allowing the verifier transaction agent 82 to relay the completion status and to update the verified ledger 86 with the completion status. The verifier transaction agent 82 updates the verified ledger 86 with the completion status (step 740). The verifier transaction agent 82 notifies the holder transaction agent 72 that the transaction has been completed (step 742). The holder transaction agent 72 then updates the transaction ledger 76 with the completion status (step 744).

[0082] The holder transaction agent 72 notifies the holder agent 42 that the transaction is complete (step 746), and the holder agent 42 may choose to display an update to the user or system. The holder transaction agent 72 notifies the issuer transaction agent 62 that the transaction is complete (step 748), and the issuer transaction agent 62 updates the issuance ledger 66 with the completion status (step 750).

[0083] Steps 712, 714, 718, and 722 provide an additional level of completeness that ensures that SSI system 300 can detect problems and / or indicate progress throughout the process flow and flow sequence of system 700. A system implementation may choose to skip one or more of steps 712, 714, 718, and 722 for optimization purposes without losing the overall outcome of the transaction.

[0084] The scenarios represented by the process flows and systems 600 and 700 enable the second and third co-protocols described above. In the second co-protocol, the holder agent 42 requests a service as part of a transaction requiring a verifiable credential, and the issuer agent 22 requests payment before the issuer agent 22 provides an unlock signature that enables the verifier agent 52 to use the verifiable credential. In the second co-protocol, the verifier of the verifier agent 52 is the payer, and the issuer agent 22 is the payee. In the third co-protocol, a service is used by the holder of the holder agent 42 in a transaction with the verifier of the verifier agent 52 requiring a verifiable credential, and the system provider of the holder agent 42 requests payment for use of the SSI system 300 as part of the transaction. In the third co-protocol, the verifier of the verifier agent 52 is the payer, and the system provider of the holder agent 42 is the payee.

[0085] The scenario represented by the process flows and systems 600 and 700 is particularly suited to applications supporting the first use case described herein, which involves providing identity proof for online service sign-up. The scenario represented by the process flows and systems 600 and 700 is even more suited to applications supporting the fourth use case described herein, which involves providing proof of authorized purchase of a particular product when a user (i.e., a purchaser) writes a product / service review. With respect to the fourth use case, the issuer agent 22 can motivate certain incident response platforms (“IRPs”) to not verify the verifiable credentials (e.g., if the IRPs publish bad reviews). Alternatively, other use cases can be supported by the scenario represented by the process flows and systems 600 and 700.

[0086] In the second payment scheme of Table 2, the holder pays the issuer for each issuance of a verifiable credential. The second payment scheme implements a transaction agent to perform the credential processing. The payment terms of the second payment scheme include a requirement to pay for each issuance of a verifiable credential used in a transaction. With reference to FIGS. 6A and 6B, two exemplary scenarios in which the second payment scheme applies are represented by process flow and system 800 and process flow and system 900, respectively. In the process flow and system 800 of FIG. 6A, a new verifiable credential is requested from the issuer agent 22. The prerequisites of the first process flow and system 800 include a requirement that the holder does not have a previous verifiable credential. In the process flow and system 900 of FIG. 6B, the holder agent 42 already has a verifiable credential that was previously received from the issuer agent 22.

[0087] The process flows and systems 800, 900 enable a method for conducting transactions over a network via a plurality of agents, including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. As described with respect to the process flows and systems 800 and 900, the first agent is depicted as a holder transaction agent 72, the second agent is depicted as a holder agent 42, the third agent is depicted as a verifier agent 52, the fourth agent is depicted as an issuer transaction agent 62, the fifth agent is depicted as an issuer agent 22, and the sixth agent is depicted as a verifier transaction agent 82. The depiction of multiple agents with respect to the process flows and systems 800, 900 is exemplary in nature, and the process flows and systems 800, 900 are not limited by the specific naming of each agent.

[0088] Referring to FIG. 6A, a process flow and system 800 useful in a network environment is shown. A holder, via a holder agent 42 (i.e., a second agent), wishes to initiate a transaction to utilize a service from a provider, and a provider, acting as a verifier, via a verifier agent 52 (i.e., a third agent), wishes to verify the holder. The holder agent 42 requests service from the verifier agent 52 (step 802). The verifier agent 52 initiates a new transaction (hereinafter, a “free transaction”) that is not subject to issuer-imposed or holder-imposed costs by sending an initiation notice to a verifier transaction agent 82 (i.e., a sixth agent) (step 804). The verifier transaction agent 82 stores the free transaction notice in the form of a transaction update in the verified ledger 86 (step 806).

[0089] The verifier transaction agent 82 notifies the verifier agent 52 that the free transaction has been successfully saved to the verified ledger 86 so that the verifier agent 52 can begin processing the presentation request (step 808). The verifier agent 52 specifies one or more required data points (e.g., attributes of the verifiable credential) in a presentation request for the free transaction to the holder agent 42 (step 810). The presentation request defines the terms of the free transaction, which may be similar to a contract. The holder agent 42 requests a verifiable credential from the issuer agent 22 (i.e., the fifth agent), and the holder agent 42 initiates a signed credential request transaction including payment for the issuance of the verifiable credential (step 812). The issuer agent 22 sends the signed credential request transaction from the holder agent 42 to the issuer transaction agent 62 (i.e., the fourth agent) (step 814). The issuer transaction agent 62 verifies the digital signature of the digitally signed transaction, for example by applying the public key of the holder agent 42 (step 815).

[0090] The issuer transaction agent 62 stores the signed credential request transaction in the issuance ledger 66 (step 816). The issuer transaction agent 62 sends a confirmation of the storage of the signed credential request transaction (step 818), allowing the issuer agent 22 to continue the exchange with the holder agent 42 and issue a verifiable credential to the holder agent 42.

[0091] The free transaction obtained by the holder agent 42 from the verifier agent 52 in step 810 and the signed credential request transaction between the holder agent 42 and the issuer agent 22, including data about the issuer agent 22 (e.g., the digital identity of the issuer agent 22), are sent by the holder agent 42 to the holder transaction agent 72 (i.e., the first agent) in the form of a transaction update (step 820). The free transaction and the credential request transaction received by the holder transaction agent 72 in step 820 are written by the holder transaction agent 72 to the transaction ledger 76 in the form of a transaction update (step 822). A confirmation of the storage of the free transaction and the credential request transaction in the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 824).

[0092] The holder agent 42 and issuer agent 22 interact to meet any conditions that must be met before the issuer agent 22 can issue the requested verifiable credential based on the use case, credential type, and assurance level (step 826). For example, for a know-your-customer ("KYC") type verifiable credential, the holder of the holder agent 42 may be required to present a driver's license or other ID, along with their face, on camera. The issuer agent 22 sends the holder's verifiable credential and a cryptographic commitment, information that allows the transaction agent to pay a fee for verification, to the holder agent 42 (step 828). The cryptographic commitment is associated with the verifiable credential and includes information that the verifier agent 52 uses to contact the issuer agent 22. The cryptographic commitment may be provided as a partial signature of the verifiable credential that ensures that the verifiable credential can be used by the holder agent 42 and allows the verifier agent 52 to verify the verifiable credential after payment or other requirements have been completed by the holder via the holder transaction agent 72. The cryptographic commitment may include cost and payment information regarding the cost of the verifiable credential.

[0093] The holder agent 42 confirms to the holder transaction agent 72 that the issuer agent 22 has sent the verifiable credential to the holder agent 42 and that the holder agent 42 has received the verifiable credential (step 830), thereby making the payment portion of the credential request transaction available through operation of the holder transaction agent 72. The holder transaction agent 72 then sends the payment to the issuer transaction agent 62 and a payment certificate for the issuer agent 22 (step 832). The issuer transaction agent 62 then sends the credential signature (originating from the issuer agent 22) for the verifiable credential associated with the credential request transaction to the holder transaction agent 72 for relay to the holder agent 42 (step 834). The holder transaction agent 72 then sends the credential signature from the issuer transaction agent 62 to the holder agent 42 to enable use of the verifiable credential associated with the credential request transaction (step 836).

[0094] The holder agent 42 sends a verifiable presentation of the free transaction to the verifier agent 52 (step 838), where the verifiable presentation includes a verifiable credential that includes one or more data points requested by the verifier agent 52 and one or more proofs corresponding to the requested one or more data points. In response to receiving the verifiable presentation including the verifiable credential, the verifier agent 52 sends a verifiable presentation completion status to the verifier transaction agent 82, notifying the verifier transaction agent 82 that the verifiable presentation was received from the holder agent 42 and that the free transaction with the holder agent 42 has been completed (step 840). The verifier transaction agent 82 saves the verifiable presentation completion status, including the free transaction completion information, in the verified ledger 86 in the form of a transaction update (step 842). The verifier transaction agent 82 sends a notification to the holder transaction agent 72 that the verifiable presentation has been delivered to the verifier agent 52 and that the free transaction has been completed (step 844).

[0095] The holder transaction agent 72 notifies the holder agent 42 that the verifiable presentation has been delivered and the free transaction is complete (step 846). The holder transaction agent 72 updates the transaction ledger 76 with a completion status of the free transaction indicating that the free transaction is complete (step 848).

[0096] The scenario represented by process flow and system 800 enables the first and fourth co-protocols, as described above. In the first co-protocol, the holder agent 42 requests a verifiable credential from the issuer agent 22, which requires payment before issuance. The process flow and system 800 enables the holder to pay the issuer. A further step can be configured for the verifier to advance or refund to the holder money paid or to be paid by the holder to the issuer. In the fourth co-protocol, a service is used by the holder of the holder agent 42 in a transaction with a verifier of the verifier agent 52 that requires a verifiable credential already in the holder agent's 42's possession, and the holder receives payment from the verifier by providing the verifiable credential as part of the transaction.

[0097] Referring to FIG. 6B, a process flow and system 900 useful in a network environment is shown. A holder, via a holder agent 42 (i.e., a second agent), wishes to initiate a transaction to use a service from a provider, and a provider, acting as a verifier, via a verifier agent 52 (i.e., a third agent), wishes to verify the holder. The holder agent 42 requests service from the verifier agent 52 (step 902). The verifier agent 52 initiates a new transaction (hereinafter, a “free transaction”) that is not subject to issuer-imposed or holder-imposed costs by sending an initiation notice to the verifier transaction agent 82 (i.e., a sixth agent) (step 904). The verifier transaction agent 82 stores the free transaction notice in the form of a transaction update in the verified ledger 86 (step 906).

[0098] The verifier transaction agent 82 notifies the verifier agent 52 that the free transaction has been successfully saved to the verified ledger 86 so that the verifier agent 52 can begin processing the presentation request (step 908). The verifier agent 52 specifies one or more required data points (e.g., attributes of the verifiable credential) in a presentation request for the free transaction to the holder agent 42 (step 910). The presentation request defines the terms of the free transaction, which may be similar to a contract, for example.

[0099] The free transaction obtained by the holder agent 42 from the verifier agent 52 in step 910 is sent by the holder agent 42 to the holder transaction agent 72 (i.e., the first agent) in the form of a transaction update (step 912). The free transaction received by the holder transaction agent 72 in step 912 is written by the holder transaction agent 72 to the transaction ledger 76 in the form of a transaction update (step 914). A confirmation of the saving of the free transaction in the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 916).

[0100] The holder agent 42 sends a verifiable presentation of the free transaction to the verifier agent 52 (step 918), where the verifiable presentation includes a verifiable credential that includes one or more data points requested by the verifier agent 52 and one or more proofs corresponding to the requested one or more data points. In response to receiving the verifiable presentation including the verifiable credential, the verifier agent 52 sends a completion status of the verifiable presentation to the verifier transaction agent 82, notifying the verifier transaction agent 82 that the verifiable presentation was received from the holder agent 42 and that the free transaction with the holder agent 42 has been completed (step 920). The verifier transaction agent 82 saves the verifiable presentation completion status, including the free transaction completion information, in the verified ledger 86 in the form of a transaction update (step 922). The verifier transaction agent 82 sends a notification to the holder transaction agent 72 that the verifiable presentation has been delivered to the verifier agent 52 and that the free transaction has been completed (step 924).

[0101] The holder transaction agent 72 notifies the holder agent 42 that the verifiable presentation has been delivered and the free transaction is complete (step 926). The holder transaction agent 72 updates the transaction ledger 76 with the completion status of the free transaction indicating that the free transaction is complete (step 928).

[0102] The scenario represented by the process flow and system 900 is particularly suited to application to the first use case described herein, which involves providing identity proof for sign-up for an online service. A new credential holder may find it unusual and unacceptable to have to pay for an identity credential (if they do not already have one) during service sign-up under the process flow and system 800. However, a holder of an existing verifiable credential that meets the verifier's requirements can provide an unlocked credential under the process flow and system 900 to enable sign-up for an online service. Furthermore, the scenario represented by the process flow and system 800, 900 is particularly suited to applications supporting the exemplary second use case (i.e., providing educational credentials), third use case (i.e., providing proof of age to access a social club), and fourth use case (i.e., providing proof of authorized purchase of a particular product when a user writes a product / service review) described herein. Alternatively, other use cases can be supported by the scenario represented by the process flow and system 800, 900.

[0103] In the third payment scheme of Table 2, a transaction agent is involved in transactions in which the verifier pays the holder. The payment terms of the third payment scheme include a requirement to pay the holder per transaction for the verifiable credential used in the transaction. Referring to Figure 7, an exemplary scenario in which the third payment scheme is applied is represented by process flow and system 1000 effective in a network environment. When the third payment scheme is applied and the holder does not already have the required verifiable credential, the process steps applied to obtain the verifiable credential as specified in process flow and system 800 are performed, followed by the process steps of process flow and system 1000.

[0104] The process flow and system 1000 enables a method of conducting transactions on a network with multiple agents, including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. As described with respect to the process flow and system 1000, the first agent is depicted as a holder agent 42, the second agent is depicted as a verifier agent 52, the third agent is depicted as a holder transaction agent 72, the fourth agent is depicted as a verifier transaction agent 82, the fifth agent is depicted as an issuer agent 22, and the sixth agent is depicted as an issuer transaction agent 62. The depiction of multiple agents with respect to the process flow and system 1000 is exemplary in nature, and the process flow and system 1000 is not limited by the specific naming of each agent.

[0105] In the process flow and system 1000, a holder via a holder agent 42 (i.e., a first agent) wishes to initiate a transaction to avail a service from a provider, and a provider acting as a verifier via a verifier agent 52 (i.e., a second agent) wishes to verify the holder. The holder agent 42 requests the service from the verifier agent 52 (step 1002). The verifier agent 52 initiates a new transaction (hereinafter, a "payment transaction") that enables the verifier to make a payment to the holder by sending an initiation notice to the verifier transaction agent 82 (i.e., a fourth agent) (step 1004). The verifier transaction agent 82 stores the notification of the payment transaction in the form of a transaction update in the verified ledger 86 (step 1006).

[0106] The verifier transaction agent 82 notifies the verifier agent 52 that the payment transaction has been successfully saved to the verified ledger 86, allowing the verifier agent 52 to begin processing the presentation request (step 1008). The verifier agent 52 specifies to the holder agent 42 one or more data points (e.g., attributes of the verifiable credential) required in the payment transaction presentation request, which defines the terms of the payment transaction, which may resemble a contract, for example (step 1010). The holder agent 42 sends a response to the verifier agent 52's payment transaction presentation request (step 1012) that includes one or more requirements regarding the data requested by the verifier agent 52 to satisfy the one or more data points for the payment transaction (e.g., the contract) to be initiated. The one or more requirements provided by the holder agent 42 may include, for example, one or more of a price, a service level agreement ("SLA"), or a policy for the requested data. If one or more requirements are acceptable to the verifier agent 52, the verifier agent 52 responds by updating the payment transaction to generate a signed payment transaction that confirms that the one or more requirements are accepted, and the verifier agent 52 sends a response including the signed payment transaction to the holder agent 42 (step 1014).

[0107] The signed (i.e., updated) payment transaction obtained by the holder agent 42 from the verifier agent 52 in step 1014 is sent by the holder agent 42 to the holder transaction agent 72 (i.e., a third agent) (step 1016). The holder transaction agent 72 beneficially verifies the signature of the signed payment transaction by, for example, applying a public key associated with the verifier agent 52 (step 1017). The signed (i.e., updated) payment transaction received by the holder transaction agent 72 from the holder agent 42 in step 1016 is written by the holder transaction agent 72 to the transaction ledger 76 (step 1018). A confirmation of the saving of the signed payment transaction in the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 1020).

[0108] The verifier transaction agent 82 sends a payment confirmation to the holder transaction agent 72 for the signed payment transaction (step 1022). The holder transaction agent 72 sends a confirmation of receipt of payment from the verifier via the verifier transaction agent 82 to the holder agent 42 for the payment transaction (step 1024).

[0109] The holder agent 42 sends a verifiable presentation of the payment transaction to the verifier agent 52 (step 1026), the verifiable presentation including a verifiable credential containing one or more data points requested by the verifier agent 52 and one or more proofs corresponding to the requested one or more data points. In response to receiving the verifiable presentation including the verifiable credential, the verifier agent 52 sends a completion status of the verifiable presentation to the verifier transaction agent 82, notifying the verifier transaction agent 82 that the verifiable presentation was received from the holder agent 42 and that the payment transaction with the holder agent 42 is completed (step 1028). The verifier transaction agent 82 saves the verifiable presentation completion status, including the payment transaction completion information, in the form of a transaction update in the verified ledger 86 (step 1030). The verifier transaction agent 82 sends a notification to the holder transaction agent 72 that the verifiable presentation (“VP”) has been delivered to the verifier agent 52 and that the payment transaction has been completed (step 1032).

[0110] The holder transaction agent 72 notifies the holder agent 42 that the verifiable presentation has been delivered and the payment transaction is complete (step 1034). The holder transaction agent 72 updates the transaction ledger 76 with a payment transaction completion status indicating that the payment transaction is complete (step 1036).

[0111] The scenario represented by process flow and system 1000 enables the fourth co-protocol described above, in which a service is used by a holder of holder agent 42 in a transaction with a verifier at verifier agent 52 that requires a verifiable credential already in the holder agent's possession, and the holder receives payment from the verifier by providing the verifiable credential as part of the transaction. The scenario represented by process flow and system 1000 is particularly suited for applications supporting the fourth use case described herein (i.e., providing proof of authorized purchase of a particular product when a user writes a product / service review). Alternatively, other use cases may be supported by the scenario represented by process flow and system 1000.

[0112] 5A , a process flow and system 600 enables a first method for conducting transactions on a network with multiple agents, including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. The first method is described with reference to steps and elements of the process flow and system 600, in which the first agent is depicted as holder transaction agent 72, the second agent is depicted as holder agent 42, the third agent is depicted as verifier agent 52, the fourth agent is depicted as verifier transaction agent 82, the fifth agent is depicted as issuer transaction agent 62, and the sixth agent is depicted as issuer agent 22. The depiction of multiple agents with respect to the process flow and system 600 is exemplary in nature, and the process flow and system 600 is not limited by the specific naming of each agent.

[0113] A first method for conducting a transaction on a network includes receiving a digitally signed transaction by a holder transaction agent 72 (i.e., a first agent) from a holder agent 42 (i.e., a second agent), where the digitally signed transaction is received by the holder agent 42 from a verifier agent 52 (i.e., a third agent) and includes a digital signature (step 616). The holder transaction agent 72 beneficially verifies the digital signature (step 617). A first verifiable proof (e.g., payment proof, payment certificate) from a verifier transaction agent 82 (i.e., a fourth agent) is received by the holder transaction agent 72 (step 630). The first verifiable proof is sent by the holder transaction agent 72 to an issuer transaction agent (i.e., a fifth agent) (step 632). An unlocking signature for the locked credential, provided to the holder agent 42 by the issuer agent 22 (i.e., a sixth agent), is sent by the holder transaction agent 72 to the issuer transaction agent 52. 62 (step 636), and the unlocking signature is sent by the holder transaction agent 72 to the verifier transaction agent 82 (step 638).

[0114] The first method further includes sending, by the holder agent 42, a request to initiate use of the service to the verifier agent 52 (step 602); receiving, by the holder agent 42, a request for one or more data points from the verifier agent 52 supporting verification of the entity initiating use of the service (step 604); and sending, by the holder agent 42, to the verifier agent 52, one or more requirements for satisfying the one or more data points (step 612). For example, the entity may include one or both of a user of the holder agent 42 or an organization associated with the user of the holder agent 42. The one or more requirements may include, for example, one or more of a price, a service level agreement (“SLA”), or a policy. The data points may include, for example, one or more of a last name, a first name, a date of birth, a credit card number, a social security number, or a passport number. The digitally signed transaction is received by the holder agent 42 from the verifier agent 52 (step 614), and a second verifiable proof (e.g., a data point proof) is sent by the holder agent 42 to the verifier agent 52, the second verifiable proof being based on the locked credential and including the one or more data points (step 622). For example, the second verifiable proof may include a locked credential including the one or more data points. The first method may further include updating the ledger by the holder transaction agent 72 based on the digitally signed transaction received from the holder agent 42 (step 618).

[0115] The first method further includes sending a request for a locked credential by the holder agent 42 to the issuer agent 22 in response to a request for one or more data points from the verifier agent 52 (step 606), receiving the locked credential by the holder agent 42 from the issuer agent 22 (step 610), and generating a second verifiable proof by the holder agent 42 based on the locked credential (step 622). The request for entity identification information from the issuer agent 22 is received by the holder agent 42, the holder agent 42 obtains the entity identification information from the user, and the entity identification information can be sent by the holder agent 42 to the issuer agent 22 (step 608). The entity identification information may include, for example, a driver's license, a business license, a passport, a social security card, etc.

[0116] The first method further includes receiving the digitally signed transaction and the second verifiable proof by the verifier transaction agent 82 from the verifier agent 52 (step 626), and sending an unlocking signature by the verifier transaction agent 82 to the verifier agent 52 (step 640). The ledger can be updated by the verifier transaction agent 82 based on the digitally signed transaction and the second verifiable proof (step 628). The unlocking signature is received by the verifier agent 52 from the verifier transaction agent 82 (step 640), the second verifiable proof is unlocked by the verifier agent 52 using the unlocking signature (step 642), and the verifier agent 52 enables use of the service in response to the verifier agent 52 unlocking the second verifiable proof.

[0117] 6A , a process flow and system 800 enables a second method for conducting transactions on a network with multiple agents, including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. The second method is described with reference to steps and elements of the process flow and system 800, in which the first agent is depicted as holder transaction agent 72, the second agent is depicted as holder agent 42, the third agent is depicted as verifier agent 52, the fourth agent is depicted as issuer transaction agent 62, the fifth agent is depicted as issuer agent 22, and the sixth agent is depicted as verifier transaction agent 82. The depiction of multiple agents with respect to the process flow and system 800 is exemplary in nature, and the process flow and system 800 is not limited by the specific naming of each agent.

[0118] A second method of conducting a transaction on a network includes receiving a first transaction (e.g., a free transaction) by a holder transaction agent 72 (i.e., the first agent) from a holder agent 42 (i.e., the second agent) (step 820), where the first transaction is initiated by a verifier agent 52 (i.e., the third agent). A first verifiable proof (e.g., a payment certificate) is sent by the holder transaction agent 72 to an issuer transaction agent 62 (i.e., the fourth agent) (step 832). The second method further includes receiving a credential signature by the holder transaction agent 72 from the issuer transaction agent 62 for a verifiable credential that includes one or more data points provided to the holder agent 42 by the issuer agent 22 (i.e., the fifth agent) for the first transaction (step 834), and sending the credential signature by the holder transaction agent 72 to the holder agent 42 (step 836).

[0119] The second method further includes receiving a second transaction (e.g., a credential request transaction) from the holder agent 42 by the holder transaction agent 72 (step 820) that includes identification data of the issuer agent 22, and sending a first verifiable proof based on the second transaction by the holder transaction agent 72 to the issuer transaction agent 62 (step 832).

[0120] The second method further includes sending a request for a verifiable credential by the holder agent 42 to the issuer agent 22, the request for the verifiable credential including the second transaction (step 812), and providing entity identification information by the holder agent 42 to the issuer agent 22 (step 826). The verifiable credential is received by the holder agent 42 from the issuer agent 22 (step 828). An indication that the verifiable credential has been received by the holder agent 42 is received by the holder transaction agent 72 from the holder agent 42 (step 830). The transmission of a first verifiable proof (e.g., a payment certificate) by the holder transaction agent 72 to the issuer transaction agent 62 (step 832) is in response to the holder transaction agent 72 receiving an indication from the holder agent 42 that the verifiable credential has been received by the holder agent 42.

[0121] The second method further includes the holder agent 42 sending a request to initiate service usage to the verifier agent 52 (step 802) and the holder agent 42 receiving a request for one or more data points for initiating service usage from the verifier agent 52 (step 810). A credential signature is applied to the verifiable credential by the holder agent 42 to generate a signed credential including the one or more data points (step 837), and the signed credential including the one or more data points is sent by the holder agent 42 to the verifier agent 52 (step 838). A second verifiable proof including the one or more data points is generated by the holder agent 42 based on the signed credential (step 837). The second verifiable proof including the one or more data points may be sent by the holder agent 42 to the verifier agent 52 (step 838). A second verifiable proof is generated by holder agent 42 and sent to verifier agent 52, for example as a verifiable presentation (“VP”) that includes the signed credential.

[0122] The second method further includes receiving, by the verifier transaction agent 82, an indication from the verifier agent 52 that the second verifiable proof has been received by the verifier agent 52 (step 840). The indication that the second verifiable proof has been received by the verifier agent 52 is received by the holder transaction agent 72 from the verifier transaction agent 82 (step 844). The indication that the second verifiable proof has been received by the verifier agent 52 is sent by the holder transaction agent 72 to the holder agent 42 (step 846).

[0123] The second method further includes updating the ledger by the holder transaction agent 72 based on a second transaction (e.g., a credential request transaction) from the holder agent 42 (step 822), and updating the ledger by the holder transaction agent 72 based on an indication that a second verifiable proof has been received by the verifier agent 52 (step 848).

[0124] The second method further includes receiving a second transaction (e.g., a credential request transaction) by the issuer transaction agent 62 from the issuer agent 22 (step 814), and sending a credential signature by the issuer transaction agent 62 to the holder transaction agent 72 based on the second transaction and the first verifiable proof (e.g., a payment certificate) (step 834). The second transaction may include a digitally signed transaction, and the issuer transaction agent 62 may verify the digitally signed transaction (step 815).

[0125] In addition to the above description, and with reference to FIG. 7, the process flow and system 10 1000 enables a third method for conducting transactions on a network with multiple agents, including a first agent, a second agent, a third agent, and a fourth agent. The third method is described with reference to steps and elements of a process flow and system 1000, in which the first agent is depicted as a holder agent 42, the second agent is depicted as a verifier agent 52, the third agent is depicted as a holder transaction agent 72, and the fourth agent is depicted as a verifier transaction agent 82. The depiction of multiple agents with respect to the process flow and system 1000 is exemplary in nature, and the process flow and system 1000 is not limited by the particular naming of each agent.

[0126] A third method of conducting a transaction on the network includes sending a request to initiate use of a service by a holder agent 42 (i.e., a first agent) to a verifier agent 52 (i.e., a second agent) (step 1002), receiving a request for one or more data points for initiating use of the service by the holder agent 42 from the verifier agent 52 (step 1010), and sending one or more requirements for satisfying the one or more data points by the holder agent 42 to the verifier agent 52 (step 1012). A digitally signed transaction (e.g., a payment transaction) including a digital signature is received by the holder agent 42 from the verifier agent 52 (step 1014). The digitally signed transaction is sent by the holder agent 42 to a holder transaction agent 72 (i.e., a third agent) (step 1016). An indication that a first verifiable proof of the digitally signed transaction (e.g., payment proof, payment certificate) has been received is received by the holder agent 42 from the holder transaction agent 72 (step 1024), and the holder agent 42 sends a second verifiable proof to the verifier agent 52, where the second verifiable proof is based on a verifiable credential including one or more data points (step 1026).

[0127] A third method of conducting a transaction on the network further includes receiving a first verifiable proof (e.g., proof of payment, payment certificate) by the holder transaction agent 72 from the verifier transaction agent 82 (i.e., the fourth agent) (step 1022), and sending an indication by the holder transaction agent 72 to the holder agent 42 that the first verifiable proof of the digitally signed transaction has been received (step 1024).

[0128] The second verifiable proof beneficially includes the verifiable credential. The second verifiable proof can be transmitted as a verifiable presentation (“VP”) that includes the verifiable credential (step 1026). A third method of conducting a transaction on a network further includes receiving, by the verifier transaction agent 82, from the verifier agent 52 an indication that the second verifiable proof has been received by the verifier agent 52 (step 1028); receiving, by the holder transaction agent 72, from the verifier transaction agent 82 an indication that the second verifiable proof has been received by the verifier agent 52 (step 1032); and transmitting, by the holder transaction agent 72, an indication that the second verifiable proof has been received by the verifier agent 52 to the holder agent 42 (step 1034), to complete the digitally signed transaction.

[0129] 4 in addition to the above description, process flows and systems 600, 700, 800, 900, 1000 are implemented by a transaction scheme system 500 for conducting transactions over a network with multiple agents, including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. With respect to transaction scheme system 500, the first agent is depicted as holder transaction agent 72, the second agent is depicted as holder agent 42, the third agent is depicted as verifier agent 52, the fourth agent is depicted as verifier transaction agent 82, the fifth agent is depicted as issuer transaction agent 62, and the sixth agent is depicted as issuer agent 22. The first computing device is depicted as holder transaction agent service provider system 70, and the second computing device is depicted as holder device 40. The depiction of multiple agents, devices, and ledgers for transaction scheme system 500 is exemplary in nature, and the transaction scheme system is not limited by the particular naming of each agent, device, or ledger.

[0130] The transaction scheme system 500 is configured for transacting over a network and includes a holder transaction agent 72 (i.e., a first agent) and a holder agent 42 (i.e., a second agent). The holder agent 42 is operable to transact with a verifier agent 52 (i.e., a third agent) to utilize a service. The verifier agent 52 is operable to communicate with a verifier transaction agent 82 (i.e., a fourth agent). The holder transaction agent 72 is operable to communicate with the holder agent 42 to facilitate transactions by the holder agent 42 with the verifier agent 52 for service utilization, and the holder transaction agent 72 is operable to communicate with the verifier transaction agent 82 to facilitate transactions by the holder agent 42 with the verifier agent 52 for service utilization.

[0131] The holder transaction agent 72 is further operable to transact the signature of the verifiable credential with the issuer transaction agent 62 (i.e., the fifth agent) to facilitate a transaction by the holder agent 42 with the verifier agent 52 for service use. The holder agent 42 is further operable to transact the verifiable credential with the issuer agent 22 (i.e., the sixth agent) to facilitate a transaction by the holder agent 42 with the verifier agent 52 for service use, and the issuer agent 22 is capable of communicating with the issuer transaction agent 62. The holder agent 42 is further operable to transmit the verifiable credential to the verifier agent 52.

[0132] The holder transaction agent 72 is further operable to transmit a signature of the verifiable credential to the verifier transaction agent 82. The verifier transaction agent 82 included in the transaction scheme system 500 is operable to transmit a signature of the verifiable credential to the verifier agent 52. The transaction scheme system 500 further includes a transaction ledger 76, and the holder transaction agent 72 is operable to update the transaction ledger 76 based on transactions by the holder agent 42 to avail of services. The transaction scheme system 500 further includes a verified ledger 86, and the verifier transaction agent 82 is operable to update the verified ledger 86 based on transactions by the holder agent 42 to avail of services.

[0133] The transaction scheme system 500 further includes a holder transaction agent service provider system 70 (i.e., a first computing device) in which a holder transaction agent 72 is enabled, and a holder device 40 (i.e., a second computing device) in which a holder agent 42 is enabled.

[0134] The transaction scheme system 500 further includes an issuer transaction agent 62 operable to provide a signature of the verifiable credential to the holder transaction agent 72 and transact with the holder transaction agent 72 to facilitate the holder agent 42 transacting with the verifier agent 52 for service utilization. The verifier transaction agent 82 is operable to receive the signature of the verifiable credential from the holder transaction agent 72 and transmit the signature of the verifiable credential to the verifier agent 52. The holder agent 42 is further operable to transact with the issuer agent 22 for the verifiable credential to facilitate the holder agent 42 transacting with the verifier agent 52 for service utilization. The holder agent 42 is further operable to transmit the verifiable credential to the verifier agent 52.

[0135] The holder agent 42 is further operable to send a request for a verifiable credential to the issuer agent 22. The issuer transaction agent 62 is further operable to receive the request for a verifiable credential from the issuer agent 22, receive a verifiable proof from the holder transaction agent 72, and send a signature for the verifiable credential to the holder transaction agent 72 based on the request for the verifiable credential and the verifiable proof.

[0136] 8 abstractly illustrates the functionality of an exemplary computer system 2000 in which the systems, methods, and processes described herein may be implemented. For example, issuer system 20, holder device 40, verifier system 50, issuer transaction agent service provider system 60, holder transaction agent service provider system 70, and verifier transaction agent service provider system 80 may each be embodied by a particular computer system 2000. The computer system 2000 may be provided in the form of a personal computer, laptop, handheld mobile communications device, mainframe, distributed computing system, or other suitable computer configuration. Exemplary subject matter may be described herein as computer-executable instructions, e.g., in the form of program modules, which may include programs, routines, objects, data structures, components, or architectures configured to perform particular tasks or implement particular abstract data types. Computer-executable instructions are represented, for example, by instructions 2024 executable by computer system 2000.

[0137] Computer system 2000 can operate as a stand-alone device or can be connected (e.g., networked) to other machines. In a networked deployment, computer system 2000 can operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Computer system 2000 can also be thought of as including a collection of machines that, individually or jointly, execute a set (or sets) of instructions to perform one or more of the methodologies described herein.

[0138] Those skilled in the art will appreciate that the systems, methods, and processes described herein can be implemented using other computer systems, including, but not limited to, network-connectable personal computers, minicomputers, mainframe computers, handheld mobile communication devices, multiprocessor systems, microprocessor-based or programmable electronic devices, and smart phones. Such computer systems can also be configured as distributed computing environments where program modules are enabled and tasks are performed by processing devices linked over a computer network, and where program modules can be located in both local and remote memory storage devices.

[0139] The exemplary computer system 2000 includes a processor 2002, such as a central processing unit (CPU) or a graphics processing unit (GPU), a main memory 2004, and a static memory 2006, communicating via a bus 2008. A display device 2010, such as a liquid crystal display (LCD), a light-emitting diode (LED) display, or a cathode ray tube (CRT), is provided for displaying data to a user of the computer system 2000. The display device 2010 may be capable of receiving data input from a user, for example, via a resistive or capacitive touchscreen. A character input device 2012 may be provided, for example, in the form of a physical keyboard, or may be provided as a program module that allows for a user-interactive simulated keyboard on the display device 2010, for example, using a resistive or capacitive touchscreen. An audio input device 2013, such as a microphone, allows for spoken language input that the processor 2002 can convert into text input via instructions 2024. A pointing / selecting device 2014 may be provided, for example in the form of a computer mouse, or may be enabled via a resistive or capacitive touch screen on the display device 2010. A data drive 2016, a signal generator 2018 such as an audio speaker, and a network interface 2020 may be provided. A positioning system 2017 may also be provided, including, for example, a GPS receiver and supporting hardware.

[0140] Instructions 2024 and data structures, e.g., software instructions, that embody or use the systems, methods, and processes described herein are stored on computer-readable medium 2022 and are accessible via data drive 2016. Furthermore, when the instructions 2024 are executed, the instructions 2024 may reside, completely or partially, for a particular period of time within main memory 2004 or within processor 2002. Main memory 2004 and processor 2002 are also considered computer-readable media in this manner.

[0141] While the computer-readable medium 2022 is shown as a single medium, the computer-readable medium 2022 may be considered to include one medium or multiple media, such as in a centralized or distributed database or associated caches and servers that store the instructions 2024. The computer-readable medium 2022 may be considered to include any tangible medium that can store, encode, or carry instructions for execution by a machine, cause a machine to perform any one or more of the methodologies described herein, or store, encode, or carry data structures used by or associated with such instructions. Furthermore, the term "computer-readable storage medium" may be considered to include, but is not limited to, solid-state memory, optical media, and magnetic media that can store information in a non-transitory manner. The computer-readable medium may include, for example, non-volatile memory such as semiconductor memory devices (e.g., magnetic disks such as internal hard disks and removable disks, magneto-optical disks, CD-ROM and DVD-ROM disks, EPROMs (Erasable Programmable Read-Only Memory), EEPROMs (Electrically Erasable Programmable Read-Only Memory), and flash memory devices).

[0142] The instructions 2024 may be transmitted or received over a computer network using a signal transmission medium via a network interface 2020 operating under one or more known transfer protocols, such as FTP, HTTP, or HTTPs. Examples of computer networks include local area networks (LANs), wide area networks (WANs), the Internet, cellular networks, POTS (Plain Old Telephone) networks, and networks such as Wi-Fi. TMand wireless data networks such as 3G / 4G / 5G cellular networks. The term "computer-readable signal medium" may be considered to include any transitory, intangible medium capable of storing, encoding, or carrying instructions for execution by a machine, including digital or analog communication signals or other intangible media for facilitating communication of such instructions.

[0143] Although the features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. The methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor.

[0144] Although embodiments have been described above in detail, these embodiments are to be considered non-limiting and merely exemplary. Modifications and extensions may be developed, and all such modifications are to be considered to be within the scope defined by the appended claims.

Claims

1. receiving a digitally signed transaction by a first agent from a second agent, the digitally signed transaction being received by the second agent from a third agent and including a digital signature; receiving a first verifiable proof by the first agent from a fourth agent; transmitting the first verifiable proof by the first agent to a fifth agent; receiving, by the first agent, an unlock signature from the fifth agent for a locked credential provided by a sixth agent to the second agent; sending an unlock signature by the first agent to the fourth agent; 1. A method of conducting a transaction on a network comprising:

2. sending a request by the second agent to the third agent to initiate use of a service; receiving, by the second agent, a request from the third agent for at least one data point supporting verification of an entity initiating the use of the service; transmitting, by the second agent to the third agent, at least one requirement to satisfy the at least one data point; receiving the digitally signed transaction by the second agent from the third agent; 10. The method of claim 1, further comprising transmitting a second verifiable proof by the second agent to the third agent, the second verifiable proof being based on the locked credential and including the at least one data point.

3. 3. The method of claim 2, further comprising updating a ledger by the first agent based on the digitally signed transaction received from the second agent.

4. sending, by the second agent to the sixth agent, a request for the locked credential in response to the request for the at least one data point from the third agent; receiving the locked credential by the second agent from the sixth agent; The method of claim 2 , further comprising generating, by the second agent, the second verifiable proof based on the locked credential.

5. receiving a request for entity identification information by the second agent from the sixth agent; obtaining said entity identification information from a user by said second agent; The method of claim 4 , further comprising: transmitting the entity identification information by the second agent to the sixth agent.

6. receiving the digitally signed transaction and the second verifiable proof by the fourth agent from the third agent; The method of claim 4 , further comprising: transmitting the unlock signature by the fourth agent to the third agent.

7. 7. The method of claim 6, further comprising updating a ledger by the fourth agent based on the digitally signed transaction and the second verifiable proof.

8. receiving the unlock signature by the third agent from the fourth agent; 7. The method of claim 6, further comprising: unlocking the second verifiable proof using the unlock signature.

9. 9. The method of claim 8, further comprising enabling the use of the service by the third agent in response to the unlocking of the second verifiable proof by the third agent.

10. The method of claim 5 , wherein the entity identification information includes at least one of a driver's license, a business license, a passport, or a social security card.

11. The method of claim 4 , wherein the second verifiable proof includes the locked credential.

12. The method of claim 2 , wherein the at least one data point includes at least one of a last name, a first name, a date of birth, a credit card number, a social security number, or a passport number.

13. The method of claim 2 , wherein the at least one requirement includes at least one of a price, a service level agreement (SLA), or a policy.

14. The method of claim 2 , wherein the entity includes at least one of a user of the second agent or an organization associated with the user of the second agent.

15. The method of claim 1 , wherein the first verifiable proof comprises proof of payment.

16. The method of claim 1 , further comprising verifying the digital signature by the first agent.

17. sending a request by the second agent to the third agent to initiate use of a service; receiving, by the second agent, from the third agent, a request for at least one data point for initiating the use of the service; transmitting, by the second agent to the third agent, at least one requirement to satisfy the at least one data point; receiving the digitally signed transaction by the second agent from the third agent; 10. The method of claim 1, further comprising: transmitting the locked credential including the at least one data point by the second agent to the third agent.

18. receiving a first transaction by a first agent from a second agent, the first transaction being initiated by a third agent; transmitting a first verifiable proof by the first agent to a fourth agent; receiving, by the first agent from the fourth agent, a credential signature for a verifiable credential including at least one data point, the verifiable credential including the at least one data point provided by a fifth agent to the second agent for the first transaction; transmitting the credential signature by the first agent to the second agent; 1. A method of conducting a transaction on a network comprising:

19. receiving, by the first agent, a second transaction from the second agent, the second transaction including identification data of the fifth agent; 20. The method of claim 18, further comprising transmitting the first verifiable proof based on the second transaction by the first agent to the fourth agent.

20. sending a request for the verifiable credential by the second agent to the fifth agent, the request for the verifiable credential including the second transaction; providing entity identification information by the second agent to the fifth agent; receiving the verifiable credential by the second agent from the fifth agent; receiving, by the first agent, an indication from the second agent that the verifiable credential has been received by the second agent; 20. The method of claim 19, wherein transmitting the first verifiable proof by the first agent to the fourth agent is in response to receiving the indication by the first agent from the second agent that the verifiable credential was received by the second agent.

21. sending a request by the second agent to the third agent to initiate use of a service; receiving, by the second agent from the third agent, a request for the at least one data point for initiating the use of the service; applying, by the second agent, the credential signature to the verifiable credential to generate a signed credential that includes the at least one data point; generating, by the second agent, a second verifiable proof based on the signed credential, the second verifiable proof including the at least one data point; 21. The method of claim 20, further comprising: transmitting, by the second agent, the second verifiable proof including the at least one data point to the third agent.

22. 22. The method of claim 21, further comprising transmitting the second verifiable proof by the second agent to the third agent as a verifiable presentation that includes the signed credential.

23. receiving, by a sixth agent, an indication from the third agent that the second verifiable proof was received by the third agent; receiving, by the first agent, the indication from the sixth agent that the second verifiable proof was received by the third agent; 23. The method of claim 22, further comprising: sending, by the first agent to the second agent, the indication that the second verifiable proof was received by the third agent.

24. updating a ledger by the first agent based on the second transaction from the second agent; 24. The method of claim 23, further comprising: updating the ledger by the first agent based on the indication that the second verifiable proof was received by the third agent.

25. sending a request by the second agent to the third agent to initiate use of a service; receiving, by the second agent from the third agent, a request for the at least one data point for initiating the use of the service; applying, by the second agent, the credential signature to the verifiable credential to generate a signed credential that includes the at least one data point; 21. The method of claim 20, further comprising transmitting the signed credential including the at least one data point by the second agent to the third agent.

26. receiving the second transaction by the fourth agent from the fifth agent; 21. The method of claim 20, further comprising transmitting the credential signature by the fourth agent to the first agent based on the second transaction and the first verifiable proof.

27. 27. The method of claim 26, wherein the second transaction comprises a digitally signed transaction, the method further comprising verifying the digitally signed transaction by the fourth agent.

28. 20. The method of claim 19, further comprising updating a ledger by the first agent based on the second transaction from the second agent.

29. sending a request by the first agent to a second agent to initiate use of the service; receiving, by the first agent from the second agent, a request for at least one data point for initiating the use of the service; transmitting, by the first agent to the second agent, at least one requirement to satisfy the at least one data point; receiving, by the first agent, a digitally signed transaction from the second agent, the digital signature including the transaction; transmitting the digitally signed transaction by the first agent to a third agent; receiving, by the first agent, an indication from the third agent that a first verifiable proof of the digitally signed transaction has been received; transmitting a second verifiable proof by the first agent to the second agent, the second verifiable proof being based on a verifiable credential that includes the at least one data point; 1. A method of conducting a transaction on a network comprising:

30. receiving the first verifiable proof by the third agent from a fourth agent; 30. The method of claim 29, further comprising sending, by the third agent, the indication that the first verifiable proof of the digitally signed transaction was received to the first agent.

31. 30. The method of claim 29, wherein the second verifiable proof includes the verifiable credential.

32. 30. The method of claim 29, further comprising transmitting the second verifiable proof as a verifiable presentation that includes the verifiable credential.

33. receiving, by a fourth agent, an indication from the second agent that the second verifiable proof was received by the second agent; receiving, by the third agent, the indication from the fourth agent that the second verifiable proof was received by the second agent; 30. The method of claim 29, further comprising: sending, by the third agent, the indication that the second verifiable proof was received by the second agent to the first agent.

34. A system for conducting transactions on a network, comprising a first agent, a second agent, a fourth agent, and a fifth agent, The second agent transacting with a third agent for use of the service, said third agent operable to communicate with said fourth agent; The first agent communicating with the second agent to facilitate a transaction by the second agent with the third agent for the use of the service; operative to communicate with a fourth agent to facilitate the transaction by the second agent with the third agent for the use of the service; the fifth agent is operable to transact with the first agent to provide a signature of a verifiable credential to the first agent to facilitate the transaction by the second agent with the third agent for the use of the service; the fourth agent is operable to receive the signature of the verifiable credential from the first agent and to transmit the signature of the verifiable credential to the third agent; the second agent is further operable to transact with a sixth agent for the verifiable credential to facilitate the transaction by the second agent with the third agent for the use of the service; the second agent is further operable to transmit the verifiable credential to the third agent; system.

35. 35. The system of claim 34, wherein the first agent is further operable to transact with the fifth agent for the signature of the verifiable credential to facilitate the transaction by the second agent with the third agent for the use of the service.

36. The system described in claim 35, wherein the sixth agent is capable of communicating with the fifth agent.

37. 36. The system of claim 35, wherein the first agent is further operable to transmit the signature for the verifiable credential to the fourth agent.

38. 35. The system of claim 34, further comprising a ledger, wherein the first agent is operable to update the ledger based on the transaction by the second agent for the use of the service.

39. The system of claim 34, further comprising a ledger, wherein the fourth agent is operable to update the ledger based on the transaction by the second agent for the use of the service.

40. a first computing device on which the first agent is enabled; 35. The system of claim 34, further comprising: a second computing device on which the second agent is enabled.

41. the second agent is further operable to send a request for the verifiable credential to the sixth agent; The fifth agent further comprises: receiving the request for the verifiable credential from the sixth agent; receiving a verifiable proof from the first agent; 35. The system of claim 34, operable to transmit the signature of the verifiable credential to the first agent based on the request for the verifiable credential and the verifiable proof.

42. A system for conducting transactions over a network, comprising a first agent and a second agent, wherein the first agent: receiving a digitally signed transaction from the second agent, the digitally signed transaction being received by the second agent from a third agent and including a digital signature; receiving a first verifiable proof from a fourth agent; sending the first verifiable proof to a fifth agent; receiving from the fifth agent an unlock signature for the locked credential provided by a sixth agent to the second agent; Operative to transmit the unlock signature to the fourth agent; The second agent Sending a request to initiate a service to the third agent; receiving a request from the third agent for at least one data point for initiating the use of the service; sending at least one requirement to satisfy said at least one data point to said third agent; receiving the digitally signed transaction from the third agent; a system operable to transmit a second verifiable proof to the third agent, the second verifiable proof being based on the locked credential and including the at least one data point;

43. The method further includes the fourth agent, wherein the second agent sending a request for the locked credential to the sixth agent in response to the request for the at least one data point from the third agent; receiving the locked credential from the sixth agent; further operable to generate the second verifiable proof based on the locked credential; The fourth agent: receiving the digitally signed transaction and the second verifiable proof from the third agent; 43. The system of claim 42, further operable to transmit the unlock signature to the third agent.

44. a first computing device on which the first agent is enabled; 43. The system of claim 42, further comprising: a second computing device on which the second agent is enabled.

45. A system for conducting transactions over a network, comprising a first agent and a second agent, wherein the first agent: receiving a first transaction and a second transaction from the second agent, the first transaction being initiated by a third agent and the second transaction including identification data of a fifth agent; receiving an indication from the second agent that a verifiable credential has been received by the second agent, the verifiable credential including at least one data point provided by the fifth agent to the second agent for the first transaction; sending a first verifiable proof based on the second transaction to a fourth agent in response to receiving, by the first agent, an indication from the second agent that the verifiable credential was received by the second agent; receiving a credential signature for the verifiable credential from the fourth agent; Operable to transmit the credential signature to the second agent; The second agent sending a request for the verifiable credential to the fifth agent, the request for the verifiable credential including the second transaction; providing entity identification information to said fifth agent; The system is operable to receive the verifiable credential from the fifth agent.

46. The second agent Sending a request to initiate a service to the third agent; receiving a request from the third agent for the at least one data point for initiating the use of the service; applying the credential signature to the verifiable credential to generate a signed credential that includes the at least one data point; generating a second verifiable proof based on the signed credential, the second verifiable proof including the at least one data point; 46. ​​The system of claim 45, further operable to transmit the second verifiable proof including the at least one data point to the third agent.

47. The sixth agent further comprises: operative to receive an indication from the third agent that the second verifiable proof has been received by the third agent; The first agent receiving the indication from the sixth agent that the second verifiable proof was received by the third agent; 47. The system of claim 46, further operable to send the indication that the second verifiable proof was received by the third agent to the second agent.

48. A system for conducting transactions on a network, comprising a first agent and a third agent, wherein the first agent: Sending a request to initiate use of the service to a second agent; receiving a request from the second agent for at least one data point for initiating the use of the service; sending at least one requirement to satisfy said at least one data point to said second agent; receiving a digitally signed transaction from the second agent, the transaction including a digital signature; Sending the digitally signed transaction to the third agent; receiving an indication from the third agent that the first verifiable proof of the digitally signed transaction has been received; and operable to transmit a second verifiable proof to the second agent, the second verifiable proof being based on a verifiable credential including at least one data point; The third agent: receiving the first verifiable proof from a fourth agent; The system is operable to send an indication to the first agent that the first verifiable proof of the digitally signed transaction has been received.

49. sending a request by the second agent to a third agent to initiate use of the service; receiving, by the second agent, from the third agent, a request for at least one data point for initiating the use of the service; sending, by the second agent to a sixth agent, a request for a locked credential in response to the request for the at least one data point from the third agent; receiving the locked credential by the second agent from the sixth agent; transmitting, by the second agent to the third agent, at least one requirement to satisfy the at least one data point; receiving, by the second agent, a digitally signed transaction from the third agent, the digital signature including the digital signature; receiving the digitally signed transaction by a first agent from the second agent; transmitting a second verifiable proof by the second agent to the third agent, the second verifiable proof being based on the locked credential and including the at least one data point; receiving, by a fourth agent, the digitally signed transaction and the second verifiable proof from the third agent; receiving a first verifiable proof by the first agent from the fourth agent; transmitting the first verifiable proof by the first agent to a fifth agent; receiving, by the first agent, an unlock signature for the locked credential from the fifth agent; transmitting the unlock signature by the first agent to the fourth agent; transmitting the unlocking signature by the fourth agent to the third agent.

50. sending a request by the second agent to a third agent to initiate use of the service; receiving, by the second agent, from the third agent, a request for at least one data point for initiating the use of the service; sending, by the second agent to a fifth agent, a request for a verifiable credential including the at least one data point, the request for the verifiable credential including a second transaction; receiving the second transaction by a fourth agent from the fifth agent; receiving a first transaction by a first agent from the second agent, the first transaction being initiated by the third agent; receiving the second transaction by the first agent from the second agent, the second transaction including identification data of the fifth agent; providing entity identification information by said second agent to said fifth agent; receiving, by the second agent, the verifiable credential including the at least one data point from the fifth agent; receiving, by the first agent, an indication from the second agent that the verifiable credential has been received by the second agent; transmitting, by the first agent to the fourth agent, a first verifiable proof based on the second transaction in response to receiving, by the first agent, the indication from the second agent that the verifiable credential was received by the second agent; sending, by the fourth agent to the first agent, a credential signature for the verifiable credential that is based on the second transaction and the first verifiable proof; transmitting the credential signature by the first agent to the second agent; transmitting, by the second agent to the third agent, a second verifiable proof based on the credential signature and the verifiable credential, the second verifiable proof including the at least one data point; receiving, by a sixth agent, an indication from the third agent that the second verifiable proof was received by the third agent; receiving, by the first agent, the indication from the sixth agent that the second verifiable proof was received by the third agent; sending, by the first agent to the second agent, the indication that the second verifiable proof was received by the third agent; 1. A method of conducting a transaction on a network comprising:

Citation Information

Patent Citations

  • Cryptographic authentication and tokenized transactions

    JP2019525645A

  • Method and apparatus for verifying digital identity, electronic device, non-transitory computer-readable storage medium, and program

    JP2021111412A

  • Identity escrow management for minimal disclosure credentials

    US20140281491A1

  • Electronic patient credentials

    US20210287770A1

  • Did system using browser-based security pin authentication and control method thereof

    WO2022102930A1