SYSTEMS AND METHODS FOR TRANSACTING OVER A NETWORK

§101 §103 §112

DETAILED ACTION Status of Claims The following is a non-final First Office Action on the Merits is in reply to the application filed on 01/06/2026. Claims 1-20 are pending and have been considered below. Priority The application claims priority to, and is a divisional application of, 18063284, filed on 12/08/2022. The priority is acknowledged. Information Disclosure Statement (IDS) The information disclosure statements (IDSs) submitted on 03/03/2026, 05/15/2026, 08/12/2026, 08/22/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, such IDSs is being considered by Examiner. Claim Rejections - 35 USC § 101 35 USC 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore, subject to the conditions and requirements of this title. Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims does/do not fall within at least one of the four categories of patent eligible subject matter because the claims recite software per se. Claim 1 is directed to a “system for transaction over a network” comprising a first agent and a second agent . Applicant’s specification defines an “agent” as “an application component, executed on a computing system, operating on behalf of an entity (e.g., a user or organization) to transact for the entity” (see [0031]). Thus, under braodest reasonable interpretation, the recited first and second agent encompass software application components. Claim 1, however, does not positively recite the computing system, memory, processor or other physical structure on which agents are executed. Although the preamble recites a “system”, the body of the claim encompasses a collection of software components without the recited physical structure. A system claim to a software that does not also contain at least one structural limitation has no physical or tangible form, and thus does not fall within any statutory category (see MPEP 2106.03). Therefore, claim1 fails Step 1 of the subject-matter-eligibility analysis and is non-statutory under 35 U.S.C. 101. Claims 1-20 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more. Per Step 1 of the multi-step eligibility analysis, claims 1-20 are directed to a system. Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention. Per Step 2A.1. The limitations of independent claim 1 shown in bold recite an abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. [A] A system for transacting over a network, the system comprising a first agent and a second agent, the second agent operable to: [B] transact with a third agent for use of a network-enabled service based on a first transaction policy from a fourth agent, the third agent enabled to communicate with a fifth agent; and [C] the first agent operable to: communicate with the second agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service based on the first transaction policy; and [D] communicate with the fifth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. Claim 1 recites: a system for transacting using agent with transaction policy ([A]-[B]); communicating with agent to process transaction ([C]-[D]), which, based on the claim language and in view of the application disclosure, represents a process aimed at completing transaction by following specific rules This overall claim elements in combination, covers following rules or instructions because the claim recites transacting by following policy (i.e., rules). These fall under the Certain Methods of Organizing Human Activity, i.e., Managing Personal Behavior or Relationships, or Interactions Between People grouping of abstract ideas (see MPEP 2106.04(a)(2)). Accordingly, it is reasonable to conclude that claim 1 recites an abstract idea that represents a judicial exception. Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the additional element “network,” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. The additional element in the independent claims, shown not bolded above, recite: network ([A]-[D]), When considered individually, they amount to nothing more than generally linking the use of the judicial exception to particular technological environment or field of use. Therefore, the additional steps of claim 1 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception. Per Step 2B. Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same as under Step 2A.2. Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional elements (limitations [A]-[D]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of completing transaction could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claim 1 is deemed ineligible. Dependent Claims: Claims 2-20 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons: Claim 2, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the first agent further operable to transact with a sixth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. The claim further recites the abstract idea of processing transaction by following rules or instructions identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 2 is ineligible. Claim 3, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the second agent further operable to transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 3 is ineligible. Claim 3 recite the additional element “cryptographically”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 3 is deemed ineligible. Claim 4, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the second agent further operable to transmit the first transaction policy and to transmit the first cryptographically verifiable credential to the third agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 4 is ineligible. Claim 4 recite the additional element “cryptographically”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 4 is deemed ineligible. Claim 5, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein: the fourth agent is further operable to transmit an unlock signature for the first cryptographically verifiable credential to the first agent; and [B] the first agent is further operable to transmit based on the first transaction policy the unlock signature for the first cryptographically verifiable credential to the fifth agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 5 is ineligible. Claim 5 recite the additional element “cryptographically”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 5 is deemed ineligible. Claim 6, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the fifth agent, the fifth agent operable to transmit the unlock signature for the first cryptographically verifiable credential to the third agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 6 is ineligible. Claim 6 recite the additional element “cryptographically”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 6 is deemed ineligible. Claim 7, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] a first computing device on which the first agent is enabled; and [B] a second computing device on which the second agent is enabled. The claim further recites the abstract idea of processing transactions using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 7 is ineligible. Claim 7 recite the additional element “computing”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 7 is deemed ineligible. Claim 8, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] a sixth agent operable to receive a first transaction proof from the first agent and transmit a transaction receipt to the first agent responsive to receiving the first transaction proof; and [B] the fifth agent, the fifth agent operable to: [C] receive the first transaction policy from the third agent; [D] transmit the first transaction proof based on the first transaction policy to the first agent; and [E] receive the transaction receipt from the first agent and to transmit the transaction receipt to the third agent; [F] wherein the second agent is further operable to transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; and [G] the second agent is further operable to transmit the first transaction policy and transmit the first cryptographically verifiable credential to the third agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 8 is ineligible. Claim 8 recite the additional element “cryptographically”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 8 is deemed ineligible. Claim 9, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein the transaction receipt comprises an unlock signature for the first cryptographically verifiable credential, and the fifth agent is further operable to unlock the first cryptographically verifiable credential using the unlock signature. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 9 is ineligible. Claim 9 recite the additional element “cryptographically”, however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 9 is deemed ineligible. Claim 10, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein the transaction receipt comprises an unlock signature for the first cryptographically verifiable credential, and the fifth agent is further operable to unlock the first cryptographically verifiable credential using the unlock signature. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 10 is ineligible. Claim 10 recite the additional element “cryptographically,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 10 is deemed ineligible under Step 2A.1 and Step 2B. Claim 11, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the second agent further operable to: transact with the third agent for the use of the network-enabled service further based on a second transaction policy from a seventh agent; and [B] the first agent further operable to: communicate with the second agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service further based on the second transaction policy of the seventh agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 11 is ineligible. Claim 12, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the first agent further operable to: transact with a sixth agent and an eighth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; and [B] the second agent further operable to: transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy; [C] transact with the seventh agent for a second cryptographically verifiable credential and the second transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; and [D] transmit the first transaction policy, the second transaction policy, the first cryptographically verifiable credential, and the second cryptographically verifiable credential to the third agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 12 is ineligible. Claim 12 recite the additional element “cryptographically,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 12 is deemed ineligible under Step 2A.1 and Step 2B. Claim 13, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the first agent further operable to: receive a first transaction proof based on the first transaction policy from the fifth agent; [B] deidentify a source of the first transaction proof; [C] transmit the deidentified first transaction proof to the sixth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; [D] receive a second transaction proof based on the second transaction policy from the fifth agent; [E] deidentify a source of the second transaction proof; and [F] transmit the deidentified second transaction proof to the eighth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 13 is ineligible. Claim 14, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein: the sixth agent is further operable to transmit a first unlock signature for the first cryptographically verifiable credential to the first agent; [B] the eighth agent is operable to transmit a second unlock signature for the second cryptographically verifiable credential to the first agent; and [C] the first agent is further operable to transmit the first unlock signature for the first cryptographically verifiable credential and the second unlock signature for the second cryptographically verifiable credential to the fifth agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 14 is ineligible. Claim 14 recite the additional element “cryptographically,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 14 is deemed ineligible under Step 2A.1 and Step 2B. Claim 15, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein: the sixth agent is further operable to transmit a first unlock signature for the first cryptographically verifiable credential to the first agent; [B] the eighth agent is operable to transmit a second unlock signature for the second cryptographically verifiable credential to the first agent; and [C] the first agent is further operable to transmit the first unlock signature for the first cryptographically verifiable credential and the second unlock signature for the second cryptographically verifiable credential to the fifth agent. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 15 is ineligible. Claim 15 recite the additional element “cryptographically,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 15 is deemed ineligible under Step 2A.1 and Step 2B. Claim 16, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the second agent further operable to: receive from the third agent the digitally signed transaction; and [B] transmit to the first agent the digitally signed transaction. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 16 is ineligible. Claim 16 recite the additional elements “digital”, and “digitally,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 16 is deemed ineligible under Step 2A.1 and Step 2B. Claim 17, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein the first transaction policy comprises at least one of a date on which the first transaction policy applies or a payment term. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 17 is ineligible. Claim 18, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] a datastore, wherein the second agent is further operable to: to transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; [B] save the first cryptographically verifiable credential in a digital wallet to enable reuse of the first cryptographically verifiable credential; and [C] save the first transaction policy in the datastore to enable reuse of the first transaction policy. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 18 is ineligible. Claim 18 recite the additional element “cryptographically” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 18 is deemed ineligible under Step 2A.1 and Step 2B. Claim 19, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] wherein the second agent is further operable to: receive from the third agent a digitally signed transaction comprising a digital signature; and [B] the first agent is further operable to: receive from the second agent the digitally signed transaction and the first transaction policy; and [C] capture first metrics based on the digitally signed transaction and the first transaction policy. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 19 is ineligible. Claim 19 recite the additional elements “digital”, and “digitally,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 19 is deemed ineligible under Step 2A.1 and Step 2B. Claim 20, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites: [A] the fifth agent, the fifth agent operable to: receive from the third agent the first transaction policy and the digitally signed transaction comprising the digital signature; and [B] capture second metrics based on the digitally signed transaction and the first transaction policy. The claim further recites the abstract idea of processing transaction using rules or instruction identified in claim 1. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Therefore, claim 20 is ineligible. Claim 20 recite the additional elements “digital”, and “digitally,” however, the computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of completing transaction by following rules. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. And the additional element in the claim amounts to instructions to apply the abstract idea on a computer. Therefore, it is concluded that independent claim 20 is deemed ineligible under Step 2A.1 and Step 2B. When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more. (See MPEP 2106.05). In sum, Claims 1-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 19-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 19 recites the limitation “capture first metrics based on the digitally signed transaction and the first transaction policy”. Additionally, the specification does recite “A challenge to the SSI system 300 arises where providers of software and services enabling transactions or services via the SSI system 300 want to track, audit, and monetize the transactions or services, for example to enhance system security and usability and to protect privacy of a holder’s use of credentials” (see [0053]). One skilled in the art could not determine if the metrics regarding the digital signature are the quantitative measurement for tracking auditing and monetizing. The remainer of the claims are rejected by virtue of dependency. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or non-obviousness. Claims 1-4, 7-13, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 20230259922 A1) in view of Toth (US 20190097812 A1). Regarding Claim 1. Rao discloses: A system for transacting over a network, the system comprising a first agent and a second agent, [see at least Figs. 9 and (0021) a trust system 100 includes a server system 110, a server system 122, a server system 170, decentralized network 160, issuer device 130, holder device 150 (i.e., second agent), and verifier device 140. (0036) Agents discussed herein (issuer agent 216, holder agent 228, and verifier agent 236) include portions of program code associated with wallets of different entities that make secure connections with other agents and wallets in order to communicate identity or other information (e.g., user credentials) to complete a transaction. (0084) Remote computer 830, in the illustrated embodiment, communicates with verification service 810 to complete a verification process facilitated by the identity service 120 via holder service 106), verification service 810 (i.e., first agent), and verifier service 108.] the second agent operable to: transact with a third agent for use of a network-enabled service based on a first transaction policy from a fourth agent, [see at least (0024) a holder (i.e., second agent) may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier (i.e., third agent). (0033) The issuer service 204 includes the following components: issuer frontend 218, issuer application programming interface (API) 214, issuer controller 222, wallet storage 224, revocation server 226, issuer agent 216 (i.e., fourth agent), and payment processor 220. (0034) Issuer API 214 includes various issuer rules (i.e., first transaction policy). These rules may be business rules indicating e.g., steps or conditions that a holder entity (i.e., second agent) must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity prior to a credential being issued, an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity (i.e., fourth agent)] the third agent enabled to communicate with a fifth agent; and [see at least Fig. 9, and (0040) Verifier service 208 includes … Payment processor 244 allows verifiers (i.e., third agent) to pay for each received and verified credential … The governance body proxy 246 (i.e., fifth agent) proxies requests to one or more governance bodies 280 that may perform a verification process on issuer DIDs to verify the integrity of the issuer entity.] the first agent operable to: communicate with the second agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service based on the first transaction policy; and [see at least (0079) a go-between verification service that facilitates communication between various entities operating within a multi-sided network during an online transaction process. (0080) verification service facilitates virtual communication between a holder entity and a verifier entity for a verification process. (0086) Holder API 230, included in holder service 206 facilitates the transfer of proofs from verifiable credentials of the holder that are stored in the wallet of the holder entity. The request includes an attestation proof 932 of the verifiable credentials and one or more corresponding issuer DIDs. Online platform 930 transmits the attestation proof 932 e.g., generated from less than the entirety of verifiable credentials and the issuer DIDs to verification service 810.] The Rao reference discloses performing verification; however, the Rao reference does not disclose: [the first agent operable to:] communicate with the fifth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. Nonetheless, Toth discloses: [the first agent operable to:] communicate with the fifth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. [see at least Fig. 20 and (0020) [consent token] an artifact that can be used to specify and communicate express consent granting access to specified resources of an owner, including update and usage permissions, and disposal obligations, of collaborating parties and custodial services. (0585) 2030 (karl) (i.e., third agent) who has requested access to selected resources of owner 2010. In response, resource owner 2010 (chris) (i.e., first and second agent) specifies a consent token listing pertinent resource of chris. 2050 illustrates owner 2010 (chris) sending a request to custodian 2020 (i.e., fifth agent) who employs his digital identity 1530 to digitally seal the consent token. (0586) Relying party 2030 (karl) verifies the affixed digital seals and attestations sending an access request and the consent token 2054 to custodian 2020 who verifies 2055 the affixed digital seals, and honors the accepted access permissions up to the expiry date and time of the token.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the go-between verification of Rao with the direct agent to agent identity exchange of Toth to improve third party’s security as agents will be able to complete policy-governed transaction between agents without requiring direct access to third party’s credentials (see Toth [0516]). Rao discloses facilitating a credential based transaction. Toth teaches exchanging identity between agents to complete a transaction. Accordingly, the claimed subject matter is obvious over Rao in view of Toth. Regarding Claim 2. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: the first agent further operable to transact with a sixth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. [(0089) Verification service 810 (i.e., first agent) … sends updates 914 to one or more webhooks 920 (i.e., sixth agent) based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] Regarding Claim 3. Rao, Toth discloses the claim limitations of claim 2. Rao further discloses: the second agent further operable to transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. [(0034) Issuer API 214 (i.e., fourth agent) includes various issuer rules (i.e., first transaction policy). These rules may be business rules indicating e.g., steps or conditions that a holder entity must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity (i.e., second agent) prior to a credential being issued, an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity, etc. In situations in which the issuer rules include a charge for a credential, the holder entity may pay the issuer entity via the use of their wallet. (0035) holder device connect for transmission of a verifiable credential from the issuer to the holder, the issuer controller 222 manages a proper sequence of messages executed by an agent between the issuer and the holder] Regarding Claim 4. Rao, Toth discloses the claim limitations of claim 3. Rao further discloses: the second agent further operable to transmit the first transaction policy and to transmit the first cryptographically verifiable credential to the third agent. [see at least (0037) Holder API 230, in the illustrated embodiment, includes holder rules that are deployed to meet criteria for managing the identities and credentials of the holder when receiving credentials from issuer entities and providing attestations to verifier entities. (0041) a compound verifiable credential is sent to the verifier device 252 from the holder device 250.] Regarding Claim 7. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: a first computing device on which the first agent is enabled; and a second computing device on which the second agent is enabled. [see at least Fig. 8 and (0021) issuer device 130, holder device 150, and verifier device 140. In various embodiments, devices 130, 140 and 150 are mobile devices (e.g., a tablet or a mobile phone), a desktop computer, a laptop, etc. (0083) server system 110 (which includes mediator service 190, identity service 120, holder service 106, and verification service 810), and remote computer 830.] Regarding Claim 8. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: a sixth agent operable to receive a first transaction proof from the first agent and transmit a transaction receipt to the first agent responsive to receiving the first transaction proof; and [(0089) Verification service 810, in the illustrated embodiment, sends updates 914 to one or more webhooks 920 based on the verification result 916. Webhook(s) 920 (i.e., sixth agent) may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] the fifth agent, the fifth agent operable to: receive the first transaction policy from the third agent; [(0087) Verification service 810 sends a verification request 918 including an attestation proof 932 of verifiable credentials and the issuer DIDs to verifier service 208 (i.e., fifth agent) to perform a verification of the holder entity for the verifier entity.] transmit the first transaction proof based on the first transaction policy to the first agent; and [(0090) Depending on rules specified by a verifier entity for an identity verification (e.g., the user initiating the transaction must be at least 65 years old), the disclosed holder service 206 builds a proof for the holder entity for the verification process using one or more verifiable credentials stored for the holder. In some situations, this proof is a compound proof built using multiple verifiable credentials of the holder. If the proof is approved during the verification process according to rules specifies by the verifier entity for the transaction, then the verification is successful and the transaction may proceed. Otherwise, the verification process may return an error, indicating that the verification process failed.] receive the transaction receipt from the first agent and to transmit the transaction receipt to the third agent; [(0092) After performing a verification of the credential proof provided by the holder entity via blockchain using the issuer DID, verifier service 1010 sends verification result 1038 to verification service 1008. At element 1042, verification service 1008 updates the v-token based on the verification result 1038. At element 1048, verification service 1008 sends the v-token (e.g., indicating the verification result) to verifier entity 1004.] wherein the second agent is further operable to transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; and [see at least (0024) a holder (i.e., second agent) may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier (i.e., third agent). (0033) The issuer service 204 includes the following components: issuer frontend 218, issuer application programming interface (API) 214, issuer controller 222, wallet storage 224, revocation server 226, issuer agent 216 (i.e., fourth agent), and payment processor 220. (0034) Issuer API 214 includes various issuer rules (i.e., first transaction policy). These rules may be business rules indicating e.g., steps or conditions that a holder entity (i.e., second agent) must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity prior to a credential being issued, an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity (i.e., fourth agent)] the second agent is further operable to transmit the first transaction policy and transmit the first cryptographically verifiable credential to the third agent. [see at least (0024) a holder (i.e., second agent) may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier (i.e., third agent). (0033) The issuer service 204 includes the following components: issuer frontend 218, issuer application programming interface (API) 214, issuer controller 222, wallet storage 224, revocation server 226, issuer agent 216 (i.e., fourth agent), and payment processor 220. (0034) Issuer API 214 includes various issuer rules (i.e., first transaction policy). These rules may be business rules indicating e.g., steps or conditions that a holder entity (i.e., second agent) must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity prior to a credential being issued, an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity (i.e., fourth agent)] Regarding Claim 9. Rao, Toth discloses the claim limitations of claim 8. Rao further discloses: wherein the transaction receipt comprises an unlock signature for the first cryptographically verifiable credential, and the fifth agent is further operable to unlock the first cryptographically verifiable credential using the unlock signature. [(0076) the verifier service also check the revocation registry on the blockchain to ensure that the DID of the issuer entity is valid. In some embodiments, the verifier service confirms receipt of the attestation proof to the holder service. In some embodiments, the holder service receives the confirmation and the second transaction proposed by the verifier service is complete.] Toth further discloses: wherein the transaction receipt comprises an unlock signature … the fifth agent is further operable to unlock the first cryptographically verifiable credential using the unlock signature. [see at least (0444) other parties having 220 can use verification key v to verify that the digital signature applied to the message, document or e-credential must have been originated by owner 201; (0484) d) using inspect 541 and the inspection key 524 to decrypt the extracted digital seal signature 533 yielding expected hash 546; (0485) e) using compare 543 to match hashed result 545 to expected hash 546 indicating “digital seal verified” 547 if 545 and 546 matches, else indicating “digital seal failed to verify” 548 if 545 and 546 do not match.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the go-between verification of Rao with the direct agent to agent identity exchange of Toth to complete policy-govern transaction between agents without requiring direct access to third party’s credentials (see Toth [0516]). Rao discloses facilitating a credential based transaction. Toth teaches exchanging identity between agents to complete a transaction. Accordingly, the claimed subject matter is obvious over Rao in view of Toth. Regarding Claim 10. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: the first agent further operable to: receive a first transaction proof based on the first transaction policy from the fifth agent; [(0024) Verifier service 108 allows verifier entities that want to verify claims (e.g., of identity) received from a holder in order to perform a transaction …. a holder may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier and the verifier may access blockchain 162 to determine whether the proof of income was issued by a credible entity and whether documentation used to provide this proof of income have been revoked by the issuer.] deidentify a source of the first transaction proof; and [(0024) Metadata included in verifiable credentials are claims that may be used to respond to a request for attestation using a zero-knowledge proof method of authentication. A zero-knowledge proof is a method of authentication that employs cryptography, allowing an entity to prove to another entity that certain requirements for a transaction are met without that other entity seeing (all of) the proof itself. For example, in many situations, just enough information to complete the transaction is shared.] transmit the deidentified first transaction proof to a sixth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. [see at least (0028) zero-knowledge proof methods are used to verify information, verifier entities do not need to contact issuer entities to verify credentials received from holders (due to the use of DIDs on the blockchain), and respective peer-to-peer pair-wise DIDs (used to form secure connections between devices sharing data) is unique for a given action/exchange of information. (0089) Verification service 810 (i.e., first agent) … sends updates 914 to one or more webhooks 920 (i.e., sixth agent) based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] Regarding Claim 11. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: the second agent further operable to: transact with the third agent for the use of the network-enabled service further based on a second transaction policy from a seventh agent; and [see at least Fig. 3, and (0052) The holder wallet 334 securely stores a set of holder data 310 including a plurality of credentials 312A-312N issued by different issuers 322A-322N. For example, a first issuer 322A issued credentials 312A and 312B, a second issuer 322B issued credential 312C, while a third issuer 322N issued credential 312N.] the first agent further operable to: communicate with the second agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service further based on the second transaction policy of the seventh agent. [see at least (0024) a holder (i.e., second agent) may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier (i.e., third agent). (0033) The issuer service 204 includes the following components: issuer frontend 218, issuer application programming interface (API) 214, issuer controller 222, wallet storage 224, revocation server 226, issuer agent 216 (i.e., fourth agent), and payment processor 220. (0034) Issuer API 214 includes various issuer rules (i.e., first transaction policy). These rules may be business rules indicating e.g., steps or conditions that a holder entity (i.e., second agent) must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity prior to a credential being issued, an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity (i.e., fourth agent)] Note: Examiner notes, the combination of Rao in view of Toth does not expressly teach second transaction policy. However, the Applicant’s specification discloses on [00153] “The transaction policy is provided in machine readable format (e.g., JSON, JSON-LD). The holder agent 42 and issuer agent 22 interact (step 1110) in order to satisfy conditions that need to be met for the issuer agent 22 to be able to issue the requested verifiable credential based on the use case, type of credential, and assurance level”. One of skilled in the art, under broadest reasonable interpretation, the transaction policy are steps or conditions that need to be met. The rule of Rao is the same as the transaction policy of claimed invention. The Applicant’s specification does differentiate between first and second transaction policy. Thus, the Examiner interprets, the transaction policy are steps/rules/conditions that are needed to be met before transaction can be completed. Regarding Claim 12. Rao, Toth discloses the claim limitations of claim 11. Rao further discloses: the first agent further operable to: transact with a sixth agent and an eighth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; and [(0089) Verification service 810 (i.e., first agent) … sends updates 914 to one or more webhooks 920 (i.e., sixth agent) based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] the second agent further operable to: transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy; [see at least (0052) The holder wallet 334 securely stores a set of holder data 310 including a plurality of credentials 312A-312N issued by different issuers 322A-322N (i.e., one or more verifiable credential). (0089) Verification service 810 (i.e., first agent) … sends updates 914 to one or more webhooks 920 (i.e., sixth agent) based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] transact with the seventh agent for a second cryptographically verifiable credential and the second transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; and [see at least (0052) The holder wallet 334 securely stores a set of holder data 310 including a plurality of credentials 312A-312N issued by different issuers 322A-322N (i.e., one or more verifiable credential). (0089) Verification service 810 (i.e., first agent) … sends updates 914 to one or more webhooks 920 (i.e., sixth agent) based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] transmit the first transaction policy, the second transaction policy, the first cryptographically verifiable credential, and the second cryptographically verifiable credential to the third agent. [see at least (0052) The holder wallet 334 securely stores a set of holder data 310 including a plurality of credentials 312A-312N issued by different issuers 322A-322N (i.e., one or more verifiable credential). For example, a first issuer 322A issued credentials 312A and 312B, a second issuer 322B issued credential 312C, while a third issuer 322N issued credential 312N. (0063) trust anchors/auditors 512 ensure that players in the ecosystem follow guidelines, providing transparency that permits stakeholders to access information in order to understand incentives, rules, and policies that govern participants (issuers, holders, and verifiers) of the ecosystem. (i.e., one or more rules)] Note: Examiner notes, the claim recites different issuer of the credentials, and different conditions to be met. However, as highlighted in notes of claim 11, the specification does not indicate the difference between first and second transaction policy. Additionally, the Rao references discloses receiving credentials from issuers. Thus, the cited portion of the Rao reference reads on the claim limitations. Regarding Claim 13. Rao, Toth discloses the claim limitations of claim 12. Rao further discloses: the first agent further operable to: receive a first transaction proof based on the first transaction policy from the fifth agent; [(0024) Verifier service 108 allows verifier entities that want to verify claims (e.g., of identity) received from a holder in order to perform a transaction …. a holder may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier and the verifier may access blockchain 162 to determine whether the proof of income was issued by a credible entity and whether documentation used to provide this proof of income have been revoked by the issuer.] deidentify a source of the first transaction proof; [(0024) Metadata included in verifiable credentials are claims that may be used to respond to a request for attestation using a zero-knowledge proof method of authentication. A zero-knowledge proof is a method of authentication that employs cryptography, allowing an entity to prove to another entity that certain requirements for a transaction are met without that other entity seeing (all of) the proof itself. For example, in many situations, just enough information to complete the transaction is shared.] transmit the deidentified first transaction proof to the sixth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; [see at least (0028) zero-knowledge proof methods are used to verify information, verifier entities do not need to contact issuer entities to verify credentials received from holders (due to the use of DIDs on the blockchain), and respective peer-to-peer pair-wise DIDs (used to form secure connections between devices sharing data) is unique for a given action/exchange of information. (0089) Verification service 810 (i.e., first agent) … sends updates 914 to one or more webhooks 920 (i.e., sixth agent) based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] receive a second transaction proof based on the second transaction policy from the fifth agent; [(0034) Issuer API 214 includes various issuer rules (i.e., different transaction policy). These rules may be business rules indicating e.g., steps or conditions that a holder entity must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity prior to a credential being issued, an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity, etc. In situations in which the issuer rules include a charge for a credential, the holder entity may pay the issuer entity via the use of their wallet (wallet API 235).] deidentify a source of the second transaction proof; and [(0024) Metadata included in verifiable credentials are claims that may be used to respond to a request for attestation using a zero-knowledge proof method of authentication. A zero-knowledge proof is a method of authentication that employs cryptography, allowing an entity to prove to another entity that certain requirements for a transaction are met without that other entity seeing (all of) the proof itself. For example, in many situations, just enough information to complete the transaction is shared.] transmit the deidentified second transaction proof to the eighth agent to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service. [see at least (0028) zero-knowledge proof methods are used to verify information, verifier entities do not need to contact issuer entities to verify credentials received from holders (due to the use of DIDs on the blockchain), and respective peer-to-peer pair-wise DIDs (used to form secure connections between devices sharing data) is unique for a given action/exchange of information. (0089) Verification service 810 … sends updates 914 to one or more webhooks 920 based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants). In addition, based on results 916, verification service 810 updates a verification status for the verification by updating a verification status stored in verify status database 902 that corresponds to the verification session.] Note: Examiner notes, the claim recites different issuer of the credentials, and different conditions to be met. However, as highlighted in notes of claim 11, the specification does not indicate the difference between first and second transaction policy. Additionally, the Rao references discloses receiving credentials from issuers. Thus, the cited portion of the Rao reference reads on the claim limitations. Regarding Claim 15. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: the first agent further operable to: receive a digitally signed transaction from the second agent, the digitally signed transaction received by the second agent from the third agent and comprising a digital signature; [see at least (0074) the reduced subset may be referred to as a “minimal set of user data” and includes a DID document (DDO) including a formal description of a verifiable credential, a public key for verification, a set of authentication protocols, one or more service endpoints, a timestamp, and a signature … the holder service receives, from the verifier service, a confirmation message indicating that the less than the entirety of the one or more credentials included in the response are accepted by the verifier. (0075) the server system receives, by the holder service from the verifier service, a confirmation message … where the confirmation message is received in response to the verifier service verifying via a blockchain a decentralized identifier (DID) of an issuer entity corresponding to one or more credentials used to generate the attestation proof. (0086) Online platform 930 transmits the attestation proof 932 e.g., generated from less than the entirety of verifiable credentials and the issuer DIDs to verification service 810.] access via the network a public key corresponding to the digitally signed transaction; [see at least (0029) DDO includes descriptions of a corresponding DID, a public key for verification, a set of authentication protocols, service endpoints, a timestamp, and a signature. A DID resolver is a portion of program code that assists in locating a DID on a public blockchain. (0068) prior to the holder entity receiving the one or more credentials, the issuer service, writes, to the blockchain for respective credentials, a DID of the issuer entity, a schema of respective ones of the one or more credentials, and a public key.] cryptographically verify the digitally signed transaction based on the public key; [see at least (0070) the DID of the issuer entity is usable by the verifier device to verify authenticity via the blockchain of one or more holder credentials received by the verifier service, where verification of credential authenticity is performed by comparing the DID of the issuer entity received with the attestation proof from the holder service with DIDs of the issuer stored on the blockchain. (0087) Verifier service, 208, in the illustrated embodiment, uses an issuer DID received with the verifiable credentials from the verification service 810 to look up an issuer associated with the credentials via blockchain 202.] receive a first transaction proof based on the first transaction policy from the fifth agent; and [(0024) a holder may wish to apply for a loan from a loan company or bank and may supply a proof of income attestation to the verifier and the verifier may access blockchain 162 to determine whether the proof of income was issued by a credible entity and whether documentation used to provide this proof of income have been revoked by the issuer.] transmit the first transaction proof to a sixth agent based on the cryptographically verifying the digitally signed transaction. [(0089) Verification service 810, in the illustrated embodiment, sends updates 914 to one or more webhooks 920 based on the verification result 916. Webhook(s) 920 may be services, for example, that are utilized by verification service 810 to send updates for verification statuses to verifier entities (e.g., merchants).] Regarding Claim 16. Rao, Toth discloses the claim limitations of claim 15. Rao further discloses: the second agent further operable to: receive from the third agent the digitally signed transaction; and [see at least (0074) the reduced subset may be referred to as a “minimal set of user data” and includes a DID document (DDO) including a formal description of a verifiable credential, a public key for verification, a set of authentication protocols, one or more service endpoints, a timestamp, and a signature … the holder service receives, from the verifier service, a confirmation message indicating that the less than the entirety of the one or more credentials included in the response are accepted by the verifier. (0075) the server system receives, by the holder service from the verifier service, a confirmation message … where the confirmation message is received in response to the verifier service verifying via a blockchain a decentralized identifier (DID) of an issuer entity corresponding to one or more credentials used to generate the attestation proof. (0086) Online platform 930 transmits the attestation proof 932 e.g., generated from less than the entirety of verifiable credentials and the issuer DIDs to verification service 810.] transmit to the first agent the digitally signed transaction. [(0086) Holder API 230, included in holder service 206 facilitates the transfer of proofs from verifiable credentials of the holder that are stored in the wallet of the holder entity … Online platform 930 transmits the attestation proof 932 e.g., generated from less than the entirety of verifiable credentials and the issuer DIDs to verification service 810.] Regarding Claim 17. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: wherein the first transaction policy comprises at least one of a date on which the first transaction policy applies or a payment term. [(0034) Issuer API 214 includes various issuer rules. These rules may be business rules indicating e.g., steps or conditions that a holder entity must meet prior to a credential being issued to the holder, an amount to be charged to the holder entity prior to a credential being issued (i.e., a payment term), an amount of time that certain issued credentials are valid for before they are to be revoked by the issuer entity, etc.] Regarding Claim 18. Rao, Toth discloses the claim limitations of claim 1. Rao further discloses: a datastore, wherein the second agent is further operable to: to transact with the fourth agent for a first cryptographically verifiable credential and the first transaction policy to facilitate the transacting by the second agent with the third agent for the use of the network-enabled service; [(Abstract) The verification request includes an attestation proof generated from one or more credentials and the verification service communicates with a holder service that manages an identity storage storing credentials for the holder entity. The verification service transmits, to the verifier service, the attestation proof and then receives, from the verifier service based on the proof, verification results that are usable by the verifier to determine whether to process an action requested by the holder prior to requesting verification.] save the first cryptographically verifiable credential in a digital wallet to enable reuse of the first cryptographically verifiable credential; and [see at least Fig. 7 and (0010) a method for providing less than an entirety of credentials stored in a holder's wallet in response to a verification request of a verifier entity, according to some embodiments.] save the first transaction policy in the datastore to enable reuse of the first transaction policy. [(0037) Holder API 230, in the illustrated embodiment, includes holder rules that are deployed to meet criteria for managing the identities and credentials of the holder when receiving credentials from issuer entities and providing attestations to verifier entities.] Claims 5-6, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rao, in view of Toth, as applied to claims [1, 4] above, in further view of Novotny (US 20220272085). Regarding Claim 5. Rao, Toth discloses the claim limitations of claim 4. Rao further discloses: wherein: the fourth agent is further operable to transmit … first cryptographically verifiable credential to the first agent; and [(0062) The given verifier can verify the combined attestation received from the holder by verifying a revocation registry stored on the blockchain indicating whether the one or more verifiable credentials used to generate the combined attestation are valid.] The combination of Rao in view of Toth discloses performing transaction using agents. However, the above combination of Rao, Toth does not disclose: wherein: the fourth agent is further operable to transmit an unlock signature for the first cryptographically verifiable credential to the first agent; and the first agent is further operable to transmit based on the first transaction policy the unlock signature for the first cryptographically verifiable credential to the fifth agent. Nonetheless, Novotny discloses wherein: the fourth agent is further operable to transmit an unlock signature for the first cryptographically verifiable credential to the first agent; and [(0062) a client node 260 transmitting a transaction proposal 291 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved.] the first agent is further operable to transmit based on the first transaction policy the unlock signature for the first cryptographically verifiable credential to the fifth agent. [(0062) The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the verification service of Rao, Toth to relay a signature received from the issuer agent onward to a second, downstream node as taught by Novotny, in order to allow that second node to independently confirm the signature prior to enabling further action. Accordingly, the claimed subject matter is obvious over Rao in view of Toth, in further view of Novotny. Regarding Claim 6. Rao, Toth, Novotny discloses the claim limitations of claim 5. Novotny further discloses: the fifth agent operable to transmit the unlock signature for the first cryptographically verifiable credential to the third agent. [see at least (0062) the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293. (0088) In 520, the method may include attaching, via a blockchain node, a verifiable credential as a signature to the blockchain transaction which was created by a self-sovereign identity (SSI) network, where the verifiable credential includes a claim of the blockchain node that signed the request and a proof of the SSI network that created the verifiable credential … The blockchain node may attach the VC to the execution results of the transaction and transmit the executed result and the attached VC to another blockchain peer, client, orderer, etc. In 530, the method may include transmitting the blockchain transaction and the attached verifiable credential to one or more other blockchain nodes. Furthermore, in 540, the method may include storing the blockchain transaction and the attached verifiable credential via a data block on the blockchain.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the verification service of Rao, Toth to relay a signature received from the issuer agent onward to a second, downstream node as taught by Novotny, in order to allow that second node to independently confirm the signature prior to enabling further action. Accordingly, the claimed subject matter is obvious over Rao in view of Toth, in further view of Novotny. Regarding Claim 19. Rao, Toth discloses the claim limitations of claim 1. The combination of Rao in view of Toth discloses performing transaction using agents. However, the above combination of Rao, Toth does not disclose: wherein the second agent is further operable to: receive from the third agent a digitally signed transaction comprising a digital signature; and the first agent is further operable to: receive from the second agent the digitally signed transaction and the first transaction policy; and capture first metrics based on the digitally signed transaction and the first transaction policy. Nonetheless, Novotny discloses: wherein the second agent is further operable to: receive from the third agent a digitally signed transaction comprising a digital signature; and [(0038) when a blockchain peer signs a transaction for inclusion in a block, it uses only the credential (or a portion of a credential) that was issued to it for the purpose of signing transactions within that network. Though the DID of this peer may contain various other attributes and affiliations (e.g., that peer may belong to an organization which participates in multiple business networks), none of that information is exposed in the transaction cycle. Validating peers just check the VP (verifiable presentation) of the verifiable credential as do auditors (at some later date).] the first agent is further operable to: receive from the second agent the digitally signed transaction and the first transaction policy; and capture first metrics based on the digitally signed transaction and the first transaction policy. [(0044) the participant can request for and obtain VCs from credentialing authorities that comprise the SSI network. Each VC can serve a different (and limited) purpose, like signing a transaction for inclusion in a block, or signing an asset state that is traded with a different network. How a VC may be used (using a VP, or verifiable presentation) may depend on policy; e.g., transaction commitment policy requires a signing peer to prove its membership in an organization that is part of a network.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the verification service of Rao, Toth to relay a signature received from the issuer agent onward to a second, downstream node as taught by Novotny, in order to allow that second node to independently confirm the signature prior to enabling further action. Accordingly, the claimed subject matter is obvious over Rao in view of Toth, in further view of Novotny. Regarding Claim 20. Rao, Toth, Novotny discloses the claim limitations of claim 19. Novotny further discloses: the fifth agent operable to: receive from the third agent the first transaction policy and the digitally signed transaction comprising the digital signature; and capture second metrics based on the digitally signed transaction and the first transaction policy. [(0044) the participant can request for and obtain VCs from credentialing authorities that comprise the SSI network. Each VC can serve a different (and limited) purpose, like signing a transaction for inclusion in a block, or signing an asset state that is traded with a different network. How a VC may be used (using a VP, or verifiable presentation) may depend on policy; e.g., transaction commitment policy requires a signing peer to prove its membership in an organization that is part of a network.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the verification service of Rao, Toth to relay a signature received from the issuer agent onward to a second, downstream node as taught by Novotny, in order to allow that second node to independently confirm the signature prior to enabling further action. Accordingly, the claimed subject matter is obvious over Rao in view of Toth, in further view of Novotny. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Rao, in view of Toth, as applied to claim 13 above, in further view of Anderson (US 20210287770 A1). Regarding Claim 14. Rao, Toth discloses the claim limitations of claim 13. The combination of Rao in view of Toth discloses performing transaction using agents. However, the above combination of Rao, Toth does not disclose: wherein: the sixth agent is further operable to transmit a first unlock signature for the first cryptographically verifiable credential to the first agent; the eighth agent is operable to transmit a second unlock signature for the second cryptographically verifiable credential to the first agent; and the first agent is further operable to transmit the first unlock signature for the first cryptographically verifiable credential and the second unlock signature for the second cryptographically verifiable credential to the fifth agent. Nonetheless, Anderson discloses: wherein: the sixth agent is further operable to transmit a first unlock signature for the first cryptographically verifiable credential to the first agent;[(0083) Upon receiving the signed and encrypted vaccination credential, the verifier agent 466 decrypts the signed and encrypted vaccination credential using the public key of the private DID of the wallet 442 to obtain the signed vaccination credential. (0090) A compound proof behaves the same as the proofs described above, but utilizes claims from multiple credentials. The proof itself includes the patient's blinded link secret. This link secret provides a cryptographic means for the provider to verify that the multiple credentials used to satisfy the proof can be combined together. In this scenario, the predicate combines plan information from the coverage record with an EMR record number from the patient's demographic credential to satisfy the proof request.] the eighth agent is operable to transmit a second unlock signature for the second cryptographically verifiable credential to the first agent; and [see at least (0046) when patient 304 receives the credential, the patient agent 444, or the wallet 442 when wallet 442 incorporates the functions of the agent 444, signs the received credential with two pieces of information: a blinded link secret and a blinded proving secret unique to the patient 304. The blinded proving secret provides a means for a verifier 306 to verify that the credential belongs to the patient 304. The blinded link secret enables that credentials containing the same blinded link secrets can be combined. The attached secret information of the patient 304, along with the cryptographic signature of the issuer 302 on the credential, provides a secure means to verify that the issuer 302 issues the credential to the patient 304. (0084) credentials are presented by the wallet 442, e.g., a vaccination credential and an identification credential, the verifier agent 466 determines, through the blinded link secret of each of the credentials obtained using the public key of the public DID of the patient 304, that the multiple credentials are linked to one another and all belong to the same patient 304] the first agent is further operable to transmit the first unlock signature for the first cryptographically verifiable credential and the second unlock signature for the second cryptographically verifiable credential to the fifth agent. [see at least (0046) when patient 304 receives the credential, the patient agent 444, or the wallet 442 when wallet 442 incorporates the functions of the agent 444, signs the received credential with two pieces of information: a blinded link secret and a blinded proving secret unique to the patient 304. The blinded proving secret provides a means for a verifier 306 to verify that the credential belongs to the patient 304. The blinded link secret enables that credentials containing the same blinded link secrets can be combined. The attached secret information of the patient 304, along with the cryptographic signature of the issuer 302 on the credential, provides a secure means to verify that the issuer 302 issues the credential to the patient 304. (0084) credentials are presented by the wallet 442, e.g., a vaccination credential and an identification credential, the verifier agent 466 determines, through the blinded link secret of each of the credentials obtained using the public key of the public DID of the patient 304, that the multiple credentials are linked to one another and all belong to the same patient 304] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the verification service of Rao in view of Toth with the signature of user to lock the credentials as taught by Anderson, in order to secure the user’s verification credentials and requiring additional key to access user’s verification credentials to verify the user. Accordingly, the claimed subject matter is obvious over Rao in view of Toth, in further view of Novotny. Relevant Prior Art Not Relied Upon The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure: US 20240187238 A1 2024-06-06 POURTABATABAIE; Arya et al. SYSTEM AND METHOD FOR ZERO-KNOWLEDGE FACIAL RECOGNITION - A computer implemented system for electronic verification of credentials including at least one processor and data storage is described in various embodiments. The approach describes the architecture and use of a “max gate,” which can be used as a structural component of the neural network. US 20220222656 A1 2022-07-14 Adham; Mohammed et al. BATCH PROCESSING OF CRYPTOCURRENCY TRANSACTIONS USING UNSPENT TRANSACTION OUTPUTS - [0060] At optional step 222, the system identifies a predefined period of time passing without receiving a signature from one or more digital wallets in the transaction. The system is configured such that each digital wallet is associated with a “ranking”, e.g., a score, percentage, listing, comparison, or other metric, representing the reliability of the digital wallet in signing transactions. Every time a digital wallet participates in a transaction and signs the transaction, the ranking can be increased to indicate the wallet is a reliable signer. If a digital wallet does not sign due to a lost connection or other issue, the ranking can be decreased to indicate the wallet is less reliable. This is because the wallet has held up every other wallet in completing the transaction, so ranking penalties accrue. In some cases, people or entities associated with wallets may be intentional malicious actors attempting to, for example, purposefully slow down the system. In such cases, ranking penalties will continue to accrue as the malicious actor continues to operate until that actor is removed from rebroadcasted transactions and, eventually, all future transactions within the system. In some embodiments, all entities and wallets which are new to the system (i.e., have no history of transactions within the system) are assigned a low ranking, and as the wallet shows ability to sign and operate in a reliable way over time with multiple transactions, the ranking for the wallet is only then increasingly improved. In some embodiments, “signing pools” or groups of wallets assigned within a certain ranking or range of rankings can be established. As a wallet's ranking increases, the wallet can be categorized into better and better signing pools and grouped for transactions with increasingly more reliable wallets also placed in those signing pools. US 20220329653 A1 2022-10-13 Govindarajan; Chander et al. BLOCKCHAIN DECLARATIVE DESCRIPTOR FOR CROSS-NETWORK COMMUNICATION - [0032] Each verifiable credential may be issued from an authority within a SSI network of the blockchain network, for example, a membership service provider (MSP), a certificate authority (CA), or the like. The verifiable credential may include “proof” such as a signature of the issuer of the verifiable credential. The SSI network may maintain all allocated DIDs, VCs, and the like. In addition, the SSI network may maintain schema information of each VC, a public key of the issuer that signed the public key, and the like. Members of the blockchain can access the registry to obtain the schema information and the public key of the issuer to verify the schema of the verifiable credential and the signature of the issuer, respectively. In this way, any of the blockchain entities can validate the verifiable credential without relying on a central authority. US 6327578 B1 2001-12-04 Linehan; Mark Four-party credit/debit payment protocol - A method, system, program, and method of doing business are disclosed for electronic commerce that includes the feature of a "thin" consumer's wallet by providing issuers with an active role in each payment. This is achieved by adding an issuer gateway and moving the credit/debit card authorization function from the merchant to the issuer. This enables an issuer to independently choose alternate authentication mechanisms without changing the acquirer gateway. It also results in a significant reduction in complexity, thereby improving the ease of implementation and overall performance. WO 2023044128 A1 2023-03-23 MULLEN JEFFREY et al. PROVIDING HIGH EFFICIENCY META MARKETS WITH DIGITAL OWNERSHIP TRANSACTIONS OF PHYSICAL COLLECTIBLE ITEMS - A system includes a secure vault or system of vaults that store items such as collectible items. A market ecosystem is provided where buyers and sellers can buy, sell and trade the vaulted items without physically moving the location of the items. Items may be shipped to an intermediary item management and vaulting system and such items may be manually or automatically unboxed, permanently encapsulated (e.g., via ultrasonic welding or permanent adhesive), image captured, stored, and listed on a transactional marketplace. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /M.S.H./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698