Detailed Action
Claims 1-8, and 14-25 are pending and are examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 18 and 23 are currently amended.
35 U.S.C. § 101
Remark 1: Applicant argues “The claims recite subject matter that the human mind is not equipped to perform, such as at least the step of "generat[ing] a verifiable credential (VC) for the first account peer DID" as recited in claim 1. As noted in paragraph [0032] of the Applicant's Specification: "[t]he addition of technologies, such as digital signatures, makes VCs 115 more tamper-evident and more trustworthy than their physical counterparts." As such, Applicant submits that claim 1 does not recite a mental process because the human mind is not equipped to perform at least the element of "generat[ing] a verifiable credential (VC) for the first account peer DID" of claim 1”. (Applicant Arguments, 2025-09-17). The applicant further contends “the combination of the additional elements amount to significantly more than the alleged abstract idea. The claims contain an inventive concept of a non-conventional arrangement of elements that addresses a lack of available transfer protocols for "holders of DIDs to authorize a transfer of information by another party using DIDs and VCs" (paragraph [0015] of Applicant's Specification). For example, claim 1 recites "receiv[ing] a transfer peer decentralized identifier""and "generat[ing] a verifiable credential." The recited elements of the claim are directed to using a verifiable credential and at least one decentralized identifier in relation to a transfer, thereby addressing the problem of "no standard protocol exist[ing] for holders of DIDs to authorize a transfer of information by another party using DIDS and VCs.”. (Applicant Arguments, 2025-09-17).
Response to Remark 1: Examiner respectfully disagrees, as the claims purported technological steps (e.g. generating a verifiable credential and signing it with a decentralized identifier) are implemented using conventional computing components and cryptographic techniques, which do not rise to the level of technical improvement to a computer or network. The citations to the specification merely describe intended benefits or contextual problems, but do not provide technical specificity or non-generic mechanisms that transform the abstract idea. Accordingly, this contention is unpersuasive.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “Richardson fails to teach, disclose, or suggest "receiv[ing]
a transfer peer decentralized identifier (DID) comprising at least a first account peer DID
[and] a second account peer DID" of claim 1. . . Richardson fails to teach, disclose, or suggest "receiv[ing] a transfer peer decentralized identifier (DID) comprising... instructions to initiate a transfer for a transfer amount between a first user record and a second user record" of claim 1. . . Michelsen discloses a host computer system 105-a that "may include a network interface 210, receiver module 215, data store(s) 220, sender module 225, transfer decision module 230, and transmitter 235" (paragraph [0031], emphasis added). Furthermore, Michelsen discloses "[t]he receiver module 215 may also receive a requested funds transfer amount (which may be the same, or different, from the amount actually transferred, as there may be fees involved)" (paragraph [0033]). Applicant asserts that, even if one of ordinary skill in the art were motivated to combine Richardson and Michelsen . . . they would still not arrive at the element of claim 1 of "generat[ing] a verifiable credential (VC) for the first account peer DID, the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased by the transfer amount" of claim 1.”. (Applicant Arguments, 2025-09-17).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Richardson and Michelsen) still teach the current independent claims, as shown at least in paragraphs 25, 30 and 33 of Richardson, paragraphs 3 and 33 of Michelsen, and as further outlined in paragraph 42-45 of this action. Indeed, Richardson teaches the use of decentralized identifiers to identify parties and bind credentials to those identifiers, stating that a decentralized identifier (DID) may be used to uniquely identify an entity and that a credential may be bound to a DID associated with the user. Richardson continues, teaching issuing and transmitting such credentials, explaining that the issuer system may create a certifiable credential for the user and provide the credential to the user, which encompasses generating a VC for an account DID that reflects updated authorization information. Michealsen supplies the transactional detail by teaching receipt of a transfer request that includes an amount, stating that a prospective receiver of funds transfer may identify a funds transfer amount to thereby initiate and request the funds transfer and that the receiver module may also receive a requested funds transfer amount. Accordingly, this contention is unpersuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 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 therefor, subject to the conditions and requirements of this title.
Claims 1-8 and 14-25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-8:
Step 1
Claims 1-8 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of transacting between accounts. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A system, comprising:
a computing device comprising a processor and a memory; and
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
receive, from a client device, a transfer peer decentralized identifier (DID) comprising at least a first account peer DID, a second account peer DID, and instructions to initiate a transfer for a transfer amount between a first user record and a second user record, the first user record being identified by the first account peer DID, and the second user record being identified by the second account peer DID;
generate a verifiable credential (VC) for the first account peer DID, the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased by the transfer amount, and the VC being signed by an institution DID; and
send, to the client device, the VC.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 1 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 2-8 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 2 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 1. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 1, wherein: the VC is a second VC;
the authorization amount is a second authorization amount;
the account balance is a second account balance; and
the machine-readable instructions, when executed by the processor and prior to receiving the transfer peer DID, further cause the computing device to at least:
generate the first account peer DID that corresponds to the first user record;
generate a first VC for the first account peer DID, the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance, and the first VC being signed by a first private key associated with the institution DID; and
send, to the client device, the first account peer DID and the first VC.
Claim 3 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 2. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 2, wherein the machine-readable instructions further cause the computing device to at least revoke the first VC in response to generating the second VC.
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 1. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 1, wherein the institution DID is stored on a distributed ledger.
Claim 5 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 4. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 4, wherein: the institution DID is a first institution DID;
the first account peer DID is associated with the first institution DID;
the second account peer DID is associated with a second institution DID; and
the second institution DID is stored on the distributed ledger.
Claim 6 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 5. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 5, wherein: the transfer peer DID is a first transfer peer DID;
the computing device is a first computing device, the first computing device being identified by the first institution DID;
the first computing device being in data communication with a second computing device, the second computing device being identified by the second institution DID; and
the machine-readable instructions, when executed by the processor, further cause the first computing device to at least:
generate a first institution peer DID, the first institution peer DID being representative of the first computing device in a private peer relationship between the first computing device and the second computing device;
send the first institution peer DID to the second computing device; and receive, from the second computing device, a second institution peer DID, the second institution peer DID being representative of the second computing device in the private peer relationship between the first computing device and the second computing device.
Claim 7 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 6. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 6, wherein the machine-readable instructions, when executed by the processor, further cause the first computing device to at least:
generate a second transfer DID comprising the instructions to initiate the transfer for the transfer amount between the first user record and the second user record; and
send the second transfer DID to the second computing device.
Claim 8 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 7. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The system of claim 7, wherein the machine-readable instructions further cause the first computing device to at least initiate the transfer for the transfer amount between the first user record maintained by the first computing device and the second user record maintained by the second computing device.
Claims 14-20:
Step 1
Claims 14-20 are directed to a non-transitory computer-readable medium (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 14 recites (i.e., sets forth or describes) an abstract idea of transacting between accounts. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least:
receive, from a client device, a transfer decentralized identifier (DID) comprising at least a first account DID, a second account DID, and instructions to initiate a transfer for a transfer amount between a first user record and a second user record, the first user record being identified by the first account DID, and the second user record being identified by the second account DID;
generate a verifiable credential (VC) for the first account DID, the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased by the transfer amount, and the VC being signed by a first private key associated with an institution DID; and
send, to the client device, the VC.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 14 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 14, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 15-20 have also been analyzed. However, the subject matter of these claims also fail to recite patent eligible subject matter for the following reasons:
Claim 15 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 14. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The non-transitory, computer-readable medium of claim 14, wherein: the VC is a second VC;
the authorization amount is a second authorization amount;
the account balance is a second account balance; and
the machine-readable instructions, when executed by the processor and prior to receiving the transfer DID, further cause the computing device to at least:
generate the first account DID that corresponds to the first user record;
generate a first VC for the first account DID, the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance, and the first VC being signed by the first private key associated with the institution DID; and
send, to the client device, the first account DID and the first VC.
Claim 16 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 15. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The non-transitory, computer-readable medium of claim 15, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least revoke the first VC in response to generating the second VC.
Claim 17 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 14. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The non-transitory, computer-readable medium of claim 14, wherein: the institution DID is a first institution DID;
the first account DID is associated with the first institution DID;
the first institution DID is stored on a distributed ledger;
the second account DID is associated with a second institution DID; and
the second institution DID is stored on the distributed ledger.
Claim 18 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 17. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The non-transitory, computer-readable medium of claim 17, wherein: the transfer DID is a first transfer DID;
the computing device is a first computing device, the first computing device being identified by the first institution DID;
the first computing device being in data communication with a second computing device, the second computing device being identified by the second institution DID; and
the machine-readable instructions, when executed by the processor, further cause the first computing device to at least:
generate a first institution peer DID, the first institution peer DID being representative of the first computing device in a private peer relationship between the first computing device and the second computing device;
send the first institution peer DID to the second computing device; and
receive, from the second computing device, a second institution peer DID,
the second institution peer DID being representative of the second computing device in the private peer relationship between the first computing device and the second computing device.
Claim 19 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 18. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The non-transitory, computer-readable medium of claim 18, wherein the machine-readable instructions, when executed by the processor, further cause the first computing device to at least: generate a second transfer DID comprising the instructions to initiate the transfer for the transfer amount between the first user record and the second user record; and
send the second transfer DID to the second computing device.
Claim 20 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 17. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The non-transitory, computer-readable medium of claim 17, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least verify a third VC was signed by a second private key associated with the second institution DID, the third VC being associated with the second account DID.
Claims 21-25:
Step 1
Claims 21-25 are directed to a computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 21 recites (i.e., sets forth or describes) an abstract idea of transacting between accounts. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract idea are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, managing personal behavior or relationships or interactions between people, as they recite following rules or instructions, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite the abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A method, comprising:
receiving, from a client device, a transfer decentralized identifier (DID) comprising at least a first account DID, a second account DID, and instructions to initiate a transfer for a transfer amount between a first user record and a second user record, the first user record being identified by the first account DID, and the second user record being identified by the second account DID;
generating a verifiable credential (VC) for the first account DID, the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased by the transfer amount, and the VC being signed by an institution DID; and
sending, to the client device, the VC.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 21 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 21, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea and generally link the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims
Claims 22-25 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 22 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 21. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein: the VC is a second VC;
the authorization amount is a second authorization amount;
the account balance is a second account balance; and
the method, prior to receiving the transfer DID, further comprises:
generating the first account DID that corresponds to the first user record;
generating a first VC for the first account DID, the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance, and the first VC being signed by a first private key associated with the institution DID; and
sending, to the client device, the first account DID and the first VC.
Claim 23 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 21. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
further comprising revoking the first VC in response to generating the second VC.
Claim 24 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 21. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein: the institution DID is a first institution DID;
the first account DID is associated with the first institution DID;
the first institution DID is stored on a distributed ledger;
the second account DID is associated with a second institution DID; and
the second institution DID is stored on the distributed ledger.
Claim 25 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of claim 21. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined 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)), and generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
further comprising verifying a third VC was signed by a second private key associated with the second institution DID, the third VC being associated with the second account DID.
Claim Rejections - 35 USC § 103
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.
Claims 1-8, and 14-25 are rejected under 35 U.S.C. 103 as being unpatentable over Richardson et al. (US20230164143A1) (hereinafter “Richardson”) in view of Michelsen et al. (US20110225088A1) (hereinafter “Michelsen”).
As per Claim 1, Richardson teaches:
A system, comprising: a computing device comprising a processor and a memory; and
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: receive, from a client device, a transfer peer decentralized identifier (DID) comprising at least a first account peer DID, a second account peer DID, and instructions to initiate a transfer for a transfer amount between a first user record and a second user record, the first user record being identified by the first account peer DID, and the second user record being identified by the second account peer DID; (“The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130” (Para. 0014); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The credential application creator 150 may provide a graphical user interface, which an issuer 110 may use to create a verifiable credential 130. The issuer 110 may use the graphical user interface to select the attributes for the verifiable credential 130 and to provide values, or value ranges, for each attribute. Example attributes may include a name of the credential 130, a name or DID of the issuer 110, a name or DID of the holder 120 of the credential 130, the benefit or status associated with credential 130, whether or not the credential 130 is revokable or expires, and whether or not the credential 130 supports messaging. Other attributes may be specific to the intended use of the credential 130. For example, credential 130 that is for a concert ticket may include attributes for the seat number, date, and artist. A credential 130 that is a driver's license may include attributes for the name, address, date of birth, sex, and height of the holder 120.” (Para. 0033)
generate a verifiable credential (VC) for the first account peer DID, . . . by the transfer amount, (“holder 120 verify the amount that was deposited.” (para. 0045); VC includes authorization-related information - “Another example use case is as a proof of self. In such a case, the issuer 110 of the credentials 130 may be a government agency. The holder 120 may be an individual. The verifier 140 may be any entity who may need proof from an individual that they are who they say they are. The credentials 130 in this case would serve as a form of government identification and as proof that a holder 120 is who they purport to be. An individual holder 120 could download the credentials 130 to their smartphone and could provide them to anyone (e.g., verifier 140) who requests identification.” (para. 0045);
and the VC being signed by an institution DID; and (“On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The issuer may generate a verifiable credential 130 according to the stored verification data 115. In particular, the verifiable credential 130 may include attributes and values that correspond to the schema 118 and definition 117. In addition, the verifiable credential 130 may be signed using a private key that corresponds to the key 119 of the verification data 115.” (Para. 0019); “For example, an insurance company may use the credential application creator 150 to create a verifiable credential 130 for members that includes attributes such as account number, member name, and plan details such as deductible and co-pay information. The credential application creator 150 may generate a credential issuing application 155 that the insurance company may use to generate verifiable credentials 130 that are distributed to each member. In addition, the credential application creator 150 may generate credential verification applications 157 that the insurance company issuer 110 may distribute to medical providers (e.g., hospitals, clinics, and doctors' offices) who may want to verify the patients who present the credential 130 in exchange for medical services.” (Para. 0038)
send, to the client device, the VC. (“After generating the verifiable credential 130, the issuer 110 may transmit the verifiable credential 130 to the holder 120 through the network 190. The holder 120 may then store the verifiable credential 130 on the computing device (e.g., smart phone) associated with the holder 120.” (Para. 0020); “At 250, the signed credential is sent to a holder. The signed verifiable credential 130 may be sent by the issuer 110 to the holder 120. The holder 120 may then store the signed verifiable credential 130 on a computing device or smartphone associated with the holder 120.” (Para. 0056); “The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014).
Richardson does not disclose:
• “the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased” (claim 1).
However, as per Claim 1, Michelsen in the analogous art of secured digital transactions, teaches: “the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased”. (See “The host computer system 105-a may receive data 205 via the network interface 210, directly or indirectly, from a receiver of funds and a sender of funds (e.g., receiver 110 or sender 115 of FIG. 1). The receiver module 215 may receive various information to initiate a funds transfer from the funds receiver, and store the information in data stores(s) 220. The receiver module 215 may receive identification of the prospective sender by name, account number, email address, or another alphanumeric sender identifier unique to or otherwise identifying the sender. The receiver module 215 may also receive a requested funds transfer amount (which may be the same, or different, from the amount actually transferred, as there may be fees involved)”. (para. 0033); “When the sender identifier and amount is received, the transfer decision module 230 may determine whether further authorization is needed. If so, the transfer decision module 230 may cause the transmitter 235 to transmit data 240 requesting authorization to the prospective sender of funds.” (para. 0034); “The host computer system 105 may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount. The transfer may be made before, or after, the authorization is received and/or confirmation of receipt of payment. For example, in one embodiment, the transfer may occur only once the authorization has been received at the host computer system 105, and upon confirmation of receipt of payment. For example, the funds may be transferred upon receiving the funds or receiving a real time confirmation of receipt of payment from sender's 115 bank account, debit card, or credit card. The sender 115 may also have a balance maintained with the funds transfer service provider from which the funds may be debited.” (para. 0026).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include a feature to credentialize authorization amounts in an authentication process conducted by a server. Therefore, the incentives of providing increased data interoperability, auditability, and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Richardson teaches:
The system of claim 1, wherein: the VC is a second VC; the authorization amount is a second authorization amount; the account balance is a second account balance; and the machine-readable instructions, when executed by the processor and prior to receiving the transfer peer DID, further cause the computing device to at least: generate the first account peer DID that corresponds to the first user record; generate a first VC for the first account peer DID, . . ., and the first VC being signed by a first private key associated with the institution DID; and send, to the client device, the first account peer DID and the first VC. (“The issuer may generate a verifiable credential 130 according to the stored verification data 115. In particular, the verifiable credential 130 may include attributes and values that correspond to the schema 118 and definition 117. In addition, the verifiable credential 130 may be signed using a private key that corresponds to the key 119 of the verification data 115.” (Para. 0019); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “After generating the verifiable credential 130, the issuer 110 may transmit the verifiable credential 130 to the holder 120 through the network 190. The holder 120 may then store the verifiable credential 130 on the computing device (e.g., smart phone) associated with the holder 120.” (Para. 0020).
Richardson does not disclose:
• “the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance” (claim 2).
However, as per Claim 2, Michelsen in the analogous art of secured digital transactions, teaches: “the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance”. (See “The host computer system 105-a may receive data 205 via the network interface 210, directly or indirectly, from a receiver of funds and a sender of funds (e.g., receiver 110 or sender 115 of FIG. 1). The receiver module 215 may receive various information to initiate a funds transfer from the funds receiver, and store the information in data stores(s) 220. The receiver module 215 may receive identification of the prospective sender by name, account number, email address, or another alphanumeric sender identifier unique to or otherwise identifying the sender. The receiver module 215 may also receive a requested funds transfer amount (which may be the same, or different, from the amount actually transferred, as there may be fees involved)”. (para. 0033); “When the sender identifier and amount is received, the transfer decision module 230 may determine whether further authorization is needed. If so, the transfer decision module 230 may cause the transmitter 235 to transmit data 240 requesting authorization to the prospective sender of funds.” (para. 0034); “The host computer system 105 may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount. The transfer may be made before, or after, the authorization is received and/or confirmation of receipt of payment. For example, in one embodiment, the transfer may occur only once the authorization has been received at the host computer system 105, and upon confirmation of receipt of payment. For example, the funds may be transferred upon receiving the funds or receiving a real time confirmation of receipt of payment from sender's 115 bank account, debit card, or credit card. The sender 115 may also have a balance maintained with the funds transfer service provider from which the funds may be debited.” (para. 0026).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include a feature to credentialize authorization amounts in an authentication process conducted by a server. Therefore, the incentives of providing increased data interoperability, auditability, and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 3, Richardson teaches:
The system of claim 2, wherein the machine-readable instructions further cause the computing device to at least revoke the first VC in response to generating the second VC. (“In some embodiments, the issuers 110 may be able to withdraw a verifiable credential 130 once issued. In these embodiments, each issuer 110 may maintain a list or registry of the verifiable credential 130 that were withdrawn on the public datastore 125. The list may use the unique identifiers that are associated with each verifiable credential 130.” (Para. 0026); “An issuer 110 may desire to withdraw verifiable credential 130 for a variety of reasons. Examples include expiration of the verifiable credential 130 (e.g., an issuer 110 may issue a verifiable credential 130 that is only valid for a day, week, or year), failure to pay for the verifiable credential 130 (e.g., a user may pay a monthly to use the credential 130), and a change of circumstances of the holder 120 (e.g., a user may be no longer employed by the issuer 110 and may no longer be eligible for the credential 130).” (Para. 0027); “In addition, a holder 120 may lose the verifiable credential 130 and may request a new verifiable credential 130 from the issuer 110. The issuer 110 may provide the new verifiable credential 130 and may add an identifier of the lost verifiable credential 130 to the list of revoked verifiable credentials 130. For example, a holder 120 may lose the smartphone or mobile device that stores the verifiable credential 130 and may request that a new verifiable credential 130 be sent to a replacement device.” (Para. 0028)
As per Claim 4, Richardson teaches:
The system of claim 1, wherein the institution DID is stored on a distributed ledger. (“The issuer 110 may store the verification data 115 at a public datastore 125. In some embodiments, the public datastore 125 may be a blockchain-based cryptographic ledger. Other types of datastores may be supported.” (Para. 0018); “At 220, the verification data is written to a public datastore. The verification data 115 may be written to a public datastore 125 by the issuer 110. The public datastore 125 may be a blockchain ledger, for example. Other datastores may be used. At a later time , when the holder 120 presents the verifiable credential 130 to a verifier 140, the verifier 140 may retrieve the verification data 115 from the public datastore 125 and verify the verifiable credential 130 using the verification data 115.” (Para. 0053); “An issuer may desire to create a verifiable credential for certain parties which attest to some fact about which the issuer can speak authoritatively. For example, an employer may attest to the employment status of its employees or their eligibility for employer sponsored benefits plan participation in the form of verifiable credentials which can be independently verified by one or more unrelated verifiers. The issuer provides information about the desired verifiable credential including structure and purpose to a credential creating application that creates verification information for the verifiable credential and publishes the verification information to a public datastore such as a blockchain or distributed ledger. The creation application then creates a first application that can be used by the issuer to generate verifiable credentials according to the provided structure and purpose, and a second application that can be used by the verifiers to verify any credentials that they receive from holders using the published verification information. The verifiers may provide some benefit to the holders in response to verifying the credentials. For example, upon verifying eligibility status for an employer-sponsored benefit plan, a verifier might enable a provider to render services associated with the plan under its terms.” (Para. 0003)
As per Claim 5, Richardson teaches:
The system of claim 4, wherein: the institution DID is a first institution DID; the first account peer DID is associated with the first institution DID; the second account peer DID is associated with a second institution DID; and the second institution DID is stored on the distributed ledger. (“The public DID 116 may be the DID associated with the issuer 110. The key 119 may be a public key associated with the issuer 110. The public key 119 may be part of the key pair that includes the private key used by the issuer 110 to digitally sign the verifiable credential 130 generated by the issuer 110. The schema 118 may identify the attributes that are expected in the verifiable credential 130. The definition 117 may describe the values that are acceptable for the attributes of the schema. Depending on the embodiment, the attributes may include a unique identifier of verifiable credential, and the DID of the issuer 110.” (Para. 0017); “The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015)
As per Claim 6, Richardson teaches:
The system of claim 5, wherein: the transfer peer DID is a first transfer peer DID; the computing device is a first computing device, the first computing device being identified by the first institution DID; the first computing device being in data communication with a second computing device, the second computing device being identified by the second institution DID; and the machine-readable instructions, when executed by the processor, further cause the first computing device to at least: generate a first institution peer DID, the first institution peer DID being representative of the first computing device in a private peer relationship between the first computing device and the second computing device; send the first institution peer DID to the second computing device; and receive, from the second computing device, a second institution peer DID, the second institution peer DID being representative of the second computing device in the private peer relationship between the first computing device and the second computing device. (“The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014); “In some embodiments, for holders 120, rather than provide an entire verifiable credential 130 to a verifier 140 for validation purposes, the holder 120 may instead provide a proof presentation 135 that is generated by the holder 120 from the verifiable credential 130. The proof presentation 135 may include a subset of the attributes of the verifiable credential and may be validated by the verifier 140 using the verification data 115 as described above. As may be appreciated, depending on what information is being requested by a verifier 140, the holder 120 may desire to only present the minimum information requested by the verifier 140.” (Para. 0031).
As per Claim 7, Richardson teaches:
The system of claim 6, wherein the machine-readable instructions, when executed by the processor, further cause the first computing device to at least: generate a second transfer DID comprising the instructions to . . . between the first user record and the second user record; and send the second transfer DID to the second computing device. (“At 420, a plurality of attributes is received. The plurality of attributes may be received by the credential application creator 150 from the issuer 110 through the graphical user interface provided by the credential application creator 150. The plurality of attributes may be attributes that define the verifiable credential 130 and may include attributes such as the name of the credential, the name or DID of the issuers 110, the name or DID of the holder 120, an indication of the status or benefit associated with the verifiable credential 130, an expiration time associated with the verifiable credential 130, whether or not the verifiable credential 130 is revocable, and whether or not the verifiable credential 130 supports messaging.” (Para. 0064); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The holder 120 may provide their verifiable credential 130 to the verifier 140. Depending on the embodiment, the holder 120 may provide the verifiable credential 130 to the verifier 140 electronically through the network 190. For example, the app or application on the mobile device of the holder 120 may display a QR code or other code that when scanned by the verifier 140, causes the verifier 140 to download and receive the verifiable credential 130.” (Para. 0022).
Richardson does not disclose:
• “initiate the transfer for the transfer amount” (claim 7).
However, as per Claim 7, Michelsen in the analogous art of secured digital transactions, teaches: “initiate the transfer for the transfer amount”. (See “A prospective receiver of a funds transfer may identify a funds transfer amount and provide a sender identifier, to thereby initiate and request the funds transfer. Authorization for the funds transfer may be received from a sender corresponding to the sender identifier. Funds associated with the funds transfer and sourced from the sender may be received. The funds transfer may be made in response to the receiver-initiated request.” (para. 0003); “In some embodiments, a host computer system may be configured to receive, from a prospective receiver of a funds transfer, an identification of a requested funds transfer amount and a sender identifier to initiate the funds transfer. The host computer system may receive, from a sender corresponding to the sender identifier, authorization for the funds transfer. The host computer system may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount.” (para. 0004); “At block 505, an identification of a requested funds transfer amount and a sender identifier are received from a prospective receiver of a funds transfer, to thereby initiate the funds transfer. At block 510, authorization for the funds transfer is received from a sender corresponding to the sender identifier. At block 515, a first amount of funds associated with the funds transfer and sourced from the sender is received. At block 520, responsive to the receiver initiation, the transfer is made of a second amount of funds associated with the funds transfer, the second amount lower than the first amount.” (para. 0047).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include transfer amounts in a verifiable credentialing structure. Therefore, the incentives of providing verifiable initiation records for increased data auditability and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 8, Richardson teaches:
The system of claim 7, wherein the machine-readable instructions further cause the first computing device to at least . . . between the first user record maintained by the first computing device and the second user record maintained by the second computing device. (“The environment 100 may allow an issuer 110 to generate and provide a verifiable credential 130 to a holder 120. The holder 120 may then provide the verifiable credential 130 to a verifier 140 for verification. Once verified, the verifier 140 may provide one or more services, benefits, statuses, or goods to the holder 120. As will be described further below, the verifiable credential 130 solves the privacy issues described above in that the verifier 140 is able to verify the verifiable credential 130 provided by the holder 120 without involving the issuer 110.” (Para. 0012); “After retrieving the verification data 115, the verifier 140 may verify the verifiable credential 130 using the verification data 115. Initially, verifier 140 may verify the verifiable credential 130 using the key 119. If the key 119 is able to successfully decrypt the portion of the verifiable credential 130 that is digital signed using the key 119, then the verifier 140 may be ensured that the verifiable credential 130 was in fact signed by the issuer 110.” (Para. 0024); “An issuer may desire to create a verifiable credential for certain parties which attest to some fact about which the issuer can speak authoritatively. For example, an employer may attest to the employment status of its employees or their eligibility for employer sponsored benefits plan participation in the form of verifiable credentials which can be independently verified by one or more unrelated verifiers. The issuer provides information about the desired verifiable credential including structure and purpose to a credential creating application that creates verification information for the verifiable credential and publishes the verification information to a public datastore such as a blockchain or distributed ledger. The creation application then creates a first application that can be used by the issuer to generate verifiable credentials according to the provided structure and purpose, and a second application that can be used by the verifiers to verify any credentials that they receive from holders using the published verification information. The verifiers may provide some benefit to the holders in response to verifying the credentials. For example, upon verifying eligibility status for an employer-sponsored benefit plan, a verifier might enable a provider to render services associated with the plan under its terms.” (Para. 0003).
Richardson does not disclose:
• “initiate the transfer for the transfer amount” (claim 13).
However, as per Claim 13, Michelsen in the analogous art of secured digital transactions, teaches: “initiate the transfer for the transfer amount”. (See “A prospective receiver of a funds transfer may identify a funds transfer amount and provide a sender identifier, to thereby initiate and request the funds transfer. Authorization for the funds transfer may be received from a sender corresponding to the sender identifier. Funds associated with the funds transfer and sourced from the sender may be received. The funds transfer may be made in response to the receiver-initiated request.” (para. 0003); “In some embodiments, a host computer system may be configured to receive, from a prospective receiver of a funds transfer, an identification of a requested funds transfer amount and a sender identifier to initiate the funds transfer. The host computer system may receive, from a sender corresponding to the sender identifier, authorization for the funds transfer. The host computer system may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount.” (para. 0004); “At block 505, an identification of a requested funds transfer amount and a sender identifier are received from a prospective receiver of a funds transfer, to thereby initiate the funds transfer. At block 510, authorization for the funds transfer is received from a sender corresponding to the sender identifier. At block 515, a first amount of funds associated with the funds transfer and sourced from the sender is received. At block 520, responsive to the receiver initiation, the transfer is made of a second amount of funds associated with the funds transfer, the second amount lower than the first amount.” (para. 0047).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include transfer amounts in a verifiable credentialing structure. Therefore, the incentives of providing verifiable initiation records for increased data auditability and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 14, Richardson teaches:
A non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least: receive, from a client device, a transfer decentralized identifier (DID) comprising at least a first account DID, a second account DID, and instructions to initiate a transfer for a transfer amount between a first user record and a second user record, the first user record being identified by the first account DID, and the second user record being identified by the second account DID; (“The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130” (Para. 0014); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The credential application creator 150 may provide a graphical user interface, which an issuer 110 may use to create a verifiable credential 130. The issuer 110 may use the graphical user interface to select the attributes for the verifiable credential 130 and to provide values, or value ranges, for each attribute. Example attributes may include a name of the credential 130, a name or DID of the issuer 110, a name or DID of the holder 120 of the credential 130, the benefit or status associated with credential 130, whether or not the credential 130 is revokable or expires, and whether or not the credential 130 supports messaging. Other attributes may be specific to the intended use of the credential 130. For example, credential 130 that is for a concert ticket may include attributes for the seat number, date, and artist. A credential 130 that is a driver's license may include attributes for the name, address, date of birth, sex, and height of the holder 120.” (Para. 0033)
generate a verifiable credential (VC) for the first account DID, . . ., and the VC being signed by a first private key associated with an institution DID; and (“On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The issuer may generate a verifiable credential 130 according to the stored verification data 115. In particular, the verifiable credential 130 may include attributes and values that correspond to the schema 118 and definition 117. In addition, the verifiable credential 130 may be signed using a private key that corresponds to the key 119 of the verification data 115.” (Para. 0019); “For example, an insurance company may use the credential application creator 150 to create a verifiable credential 130 for members that includes attributes such as account number, member name, and plan details such as deductible and co-pay information. The credential application creator 150 may generate a credential issuing application 155 that the insurance company may use to generate verifiable credentials 130 that are distributed to each member. In addition, the credential application creator 150 may generate credential verification applications 157 that the insurance company issuer 110 may distribute to medical providers (e.g., hospitals, clinics, and doctors' offices) who may want to verify the patients who present the credential 130 in exchange for medical services.” (Para. 0038)
send, to the client device, the VC. (“After generating the verifiable credential 130, the issuer 110 may transmit the verifiable credential 130 to the holder 120 through the network 190. The holder 120 may then store the verifiable credential 130 on the computing device (e.g., smart phone) associated with the holder 120.” (Para. 0020); “At 250, the signed credential is sent to a holder. The signed verifiable credential 130 may be sent by the issuer 110 to the holder 120. The holder 120 may then store the signed verifiable credential 130 on a computing device or smartphone associated with the holder 120.” (Para. 0056); “The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014).
Richardson does not disclose:
• “the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased” (claim 14).
However, as per Claim 14, Michelsen in the analogous art of secured digital transactions, teaches: “the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased”. (See “The host computer system 105-a may receive data 205 via the network interface 210, directly or indirectly, from a receiver of funds and a sender of funds (e.g., receiver 110 or sender 115 of FIG. 1). The receiver module 215 may receive various information to initiate a funds transfer from the funds receiver, and store the information in data stores(s) 220. The receiver module 215 may receive identification of the prospective sender by name, account number, email address, or another alphanumeric sender identifier unique to or otherwise identifying the sender. The receiver module 215 may also receive a requested funds transfer amount (which may be the same, or different, from the amount actually transferred, as there may be fees involved)”. (para. 0033); “When the sender identifier and amount is received, the transfer decision module 230 may determine whether further authorization is needed. If so, the transfer decision module 230 may cause the transmitter 235 to transmit data 240 requesting authorization to the prospective sender of funds.” (para. 0034); “The host computer system 105 may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount. The transfer may be made before, or after, the authorization is received and/or confirmation of receipt of payment. For example, in one embodiment, the transfer may occur only once the authorization has been received at the host computer system 105, and upon confirmation of receipt of payment. For example, the funds may be transferred upon receiving the funds or receiving a real time confirmation of receipt of payment from sender's 115 bank account, debit card, or credit card. The sender 115 may also have a balance maintained with the funds transfer service provider from which the funds may be debited.” (para. 0026).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include a feature to credentialize authorization amounts in an authentication process conducted by a server. Therefore, the incentives of providing increased data interoperability, auditability, and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 15, Richardson teaches:
The non-transitory, computer-readable medium of claim 14, wherein: the VC is a second VC; the authorization amount is a second authorization amount; the account balance is a second account balance; and the machine-readable instructions, when executed by the processor and prior to receiving the transfer DID, further cause the computing device to at least: generate the first account DID that corresponds to the first user record; generate a first VC for the first account DID, . . ., and the first VC being signed by the first private key associated with the institution DID; and send, to the client device, the first account DID and the first VC. (“The credential application creator 150 may then generate a credential issuing application 155 that can generate and issue verifiable credentials 130 according to the verification data 115 stored on the public datastore 125. The credential application creator 150 may then provide the application 155 to the issuer 110 or any other entity that may be authorized to generate the verifiable credentials 130 on behalf of the issuer 110.” (Para. 0036); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “At 250, the signed credential is sent to a holder. The signed verifiable credential 130 may be sent by the issuer 110 to the holder 120. The holder 120 may then store the signed verifiable credential 130 on a computing device or smartphone associated with the holder 120.” (Para. 0056)
Richardson does not disclose:
• “the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance” (claim 15).
However, as per Claim 15, Michelsen in the analogous art of secured digital transactions, teaches: “the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance”. (See “The host computer system 105-a may receive data 205 via the network interface 210, directly or indirectly, from a receiver of funds and a sender of funds (e.g., receiver 110 or sender 115 of FIG. 1). The receiver module 215 may receive various information to initiate a funds transfer from the funds receiver, and store the information in data stores(s) 220. The receiver module 215 may receive identification of the prospective sender by name, account number, email address, or another alphanumeric sender identifier unique to or otherwise identifying the sender. The receiver module 215 may also receive a requested funds transfer amount (which may be the same, or different, from the amount actually transferred, as there may be fees involved)”. (para. 0033); “When the sender identifier and amount is received, the transfer decision module 230 may determine whether further authorization is needed. If so, the transfer decision module 230 may cause the transmitter 235 to transmit data 240 requesting authorization to the prospective sender of funds.” (para. 0034); “The host computer system 105 may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount. The transfer may be made before, or after, the authorization is received and/or confirmation of receipt of payment. For example, in one embodiment, the transfer may occur only once the authorization has been received at the host computer system 105, and upon confirmation of receipt of payment. For example, the funds may be transferred upon receiving the funds or receiving a real time confirmation of receipt of payment from sender's 115 bank account, debit card, or credit card. The sender 115 may also have a balance maintained with the funds transfer service provider from which the funds may be debited.” (para. 0026).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include a feature to credentialize authorization amounts in an authentication process conducted by a server. Therefore, the incentives of providing increased data interoperability, auditability, and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 16, Richardson teaches:
The non-transitory, computer-readable medium of claim 15, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least revoke the first VC in response to generating the second VC. (“In addition, a holder 120 may lose the verifiable credential 130 and may request a new verifiable credential 130 from the issuer 110. The issuer 110 may provide the new verifiable credential 130 and may add an identifier of the lost verifiable credential 130 to the list of revoked verifiable credentials 130. For example, a holder 120 may lose the smartphone or mobile device that stores the verifiable credential 130 and may request that a new verifiable credential 130 be sent to a replacement device.” (Para. 0028); “In some embodiments, the issuers 110 may be able to withdraw a verifiable credential 130 once issued. In these embodiments, each issuer 110 may maintain a list or registry of the verifiable credential 130 that were withdrawn on the public datastore 125. The list may use the unique identifiers that are associated with each verifiable credential 130.” (Para. 0026); “When the verifier 140 receives a verifiable credential 130, after verifying the credential 130 using the verification data 115, the verifier 140 may check if the identifier of the credential 130 is on the list of withdrawn credentials 130 associated with the issuer 110. If so, the verifier 140 may reject the verifiable credential 130.” (Para. 0029)
As per Claim 17, Richardson teaches:
The non-transitory, computer-readable medium of claim 14, wherein: the institution DID is a first institution DID; the first account DID is associated with the first institution DID; the first institution DID is stored on a distributed ledger; the second account DID is associated with a second institution DID; and the second institution DID is stored on the distributed ledger. (“The public DID 116 may be the DID associated with the issuer 110. The key 119 may be a public key associated with the issuer 110. The public key 119 may be part of the key pair that includes the private key used by the issuer 110 to digitally sign the verifiable credential 130 generated by the issuer 110. The schema 118 may identify the attributes that are expected in the verifiable credential 130. The definition 117 may describe the values that are acceptable for the attributes of the schema. Depending on the embodiment, the attributes may include a unique identifier of verifiable credential, and the DID of the issuer 110.” (Para. 0017); “The issuer 110 may store the verification data 115 at a public datastore 125. In some embodiments, the public datastore 125 may be a blockchain-based cryptographic ledger. Other types of datastores may be supported.” (Para. 0018); “At 420, a plurality of attributes is received. The plurality of attributes may be received by the credential application creator 150 from the issuer 110 through the graphical user interface provided by the credential application creator 150. The plurality of attributes may be attributes that define the verifiable credential 130 and may include attributes such as the name of the credential, the name or DID of the issuers 110, the name or DID of the holder 120, an indication of the status or benefit associated with the verifiable credential 130, an expiration time associated with the verifiable credential 130, whether or not the verifiable credential 130 is revocable, and whether or not the verifiable credential 130 supports messaging.” (Para. 0064)
As per Claim 18, Richardson teaches:
The non-transitory, computer-readable medium of claim 17, wherein: the transfer DID is a first transfer DID; the computing device is a first computing device, the first computing device being identified by the first institution DID; the first computing device being in data communication with a second computing device, the second computing device being identified by the second institution DID; and the machine-readable instructions, when executed by the processor, further cause the first computing device to at least: generate a first institution peer DID, the first institution peer DID being representative of the first computing device in a private peer relationship between the first computing device and the second computing device; send the first institution peer DID to the second computing device; and receive, from the second computing device, a second institution peer DID, the second institution peer DID being representative of the second computing device in the private peer relationship between the first computing device and the second computing device. (“The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014); “In some embodiments, for holders 120, rather than provide an entire verifiable credential 130 to a verifier 140 for validation purposes, the holder 120 may instead provide a proof presentation 135 that is generated by the holder 120 from the verifiable credential 130. The proof presentation 135 may include a subset of the attributes of the verifiable credential and may be validated by the verifier 140 using the verification data 115 as described above. As may be appreciated, depending on what information is being requested by a verifier 140, the holder 120 may desire to only present the minimum information requested by the verifier 140.” (Para. 0031).
As per Claim 19, Richardson teaches:
The non-transitory, computer-readable medium of claim 18, wherein the machine-readable instructions, when executed by the processor, further cause the first computing device to at least: generate a second transfer DID comprising the instructions to . . . between the first user record and the second user record; and send the second transfer DID to the second computing device. (“On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The credential application creator 150 may provide a graphical user interface, which an issuer 110 may use to create a verifiable credential 130. The issuer 110 may use the graphical user interface to select the attributes for the verifiable credential 130 and to provide values, or value ranges, for each attribute. Example attributes may include a name of the credential 130, a name or DID of the issuer 110, a name or DID of the holder 120 of the credential 130, the benefit or status associated with credential 130, whether or not the credential 130 is revokable or expires, and whether or not the credential 130 supports messaging. Other attributes may be specific to the intended use of the credential 130. For example, credential 130 that is for a concert ticket may include attributes for the seat number, date, and artist. A credential 130 that is a driver's license may include attributes for the name, address, date of birth, sex, and height of the holder 120.” (Para. 0033); “The environment 100 may allow an issuer 110 to generate and provide a verifiable credential 130 to a holder 120. The holder 120 may then provide the verifiable credential 130 to a verifier 140 for verification. Once verified, the verifier 140 may provide one or more services, benefits, statuses, or goods to the holder 120. As will be described further below, the verifiable credential 130 solves the privacy issues described above in that the verifier 140 is able to verify the verifiable credential 130 provided by the holder 120 without involving the issuer 110.” (Para. 0012).
Richardson does not disclose:
• “initiate the transfer for the transfer amount” (claim 19).
However, as per Claim 19, Michelsen in the analogous art of secured digital transactions, teaches: “initiate the transfer for the transfer amount”. (See “A prospective receiver of a funds transfer may identify a funds transfer amount and provide a sender identifier, to thereby initiate and request the funds transfer. Authorization for the funds transfer may be received from a sender corresponding to the sender identifier. Funds associated with the funds transfer and sourced from the sender may be received. The funds transfer may be made in response to the receiver-initiated request.” (para. 0003); “In some embodiments, a host computer system may be configured to receive, from a prospective receiver of a funds transfer, an identification of a requested funds transfer amount and a sender identifier to initiate the funds transfer. The host computer system may receive, from a sender corresponding to the sender identifier, authorization for the funds transfer. The host computer system may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount.” (para. 0004); “At block 505, an identification of a requested funds transfer amount and a sender identifier are received from a prospective receiver of a funds transfer, to thereby initiate the funds transfer. At block 510, authorization for the funds transfer is received from a sender corresponding to the sender identifier. At block 515, a first amount of funds associated with the funds transfer and sourced from the sender is received. At block 520, responsive to the receiver initiation, the transfer is made of a second amount of funds associated with the funds transfer, the second amount lower than the first amount.” (para. 0047).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include transfer amounts in a verifiable credentialing structure. Therefore, the incentives of providing verifiable initiation records for increased data auditability and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 20, Richardson teaches:
The non-transitory, computer-readable medium of claim 17, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least verify a third VC was signed by a second private key associated with the second institution DID, the third VC being associated with the second account DID. (“After retrieving the verification data 115, the verifier 140 may verify the verifiable credential 130 using the verification data 115. Initially, verifier 140 may verify the verifiable credential 130 using the key 119. If the key 119 is able to successfully decrypt the portion of the verifiable credential 130 that is digital signed using the key 119, then the verifier 140 may be ensured that the verifiable credential 130 was in fact signed by the issuer 110.” (Para. 0024); “At 210, verification data is generated. The verification data 115 may be generated by the issuer 110 and may be used by one or more verifiers 140 to verify a verifiable credential 130. In some embodiments, the verification data 115 may include, but is not limited to, a public DID 116 of the issuer 110, a schema 118 and definition 117 that describe the expected contents or format of the verifiable credential 130, and a key 119. The key 119 may be a public key associated with the issuer 110 and may be part of a key pair associated with the issuer 110 of the verifiable credential 130.” (Para. 0052).
As per Claim 21, Richardson teaches:
A method, comprising: receiving, from a client device, a transfer decentralized identifier (DID) comprising at least a first account DID, a second account DID, and instructions to initiate a transfer for a transfer amount between a first user record and a second user record, the first user record being identified by the first account DID, and the second user record being identified by the second account DID; (“The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130” (Para. 0014); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The credential application creator 150 may provide a graphical user interface, which an issuer 110 may use to create a verifiable credential 130. The issuer 110 may use the graphical user interface to select the attributes for the verifiable credential 130 and to provide values, or value ranges, for each attribute. Example attributes may include a name of the credential 130, a name or DID of the issuer 110, a name or DID of the holder 120 of the credential 130, the benefit or status associated with credential 130, whether or not the credential 130 is revokable or expires, and whether or not the credential 130 supports messaging. Other attributes may be specific to the intended use of the credential 130. For example, credential 130 that is for a concert ticket may include attributes for the seat number, date, and artist. A credential 130 that is a driver's license may include attributes for the name, address, date of birth, sex, and height of the holder 120.” (Para. 0033)
generating a verifiable credential (VC) for the first account DID, . . . by the transfer amount, (“holder 120 verify the amount that was deposited.” (para. 0045); VC includes authorization-related information - “Another example use case is as a proof of self. In such a case, the issuer 110 of the credentials 130 may be a government agency. The holder 120 may be an individual. The verifier 140 may be any entity who may need proof from an individual that they are who they say they are. The credentials 130 in this case would serve as a form of government identification and as proof that a holder 120 is who they purport to be. An individual holder 120 could download the credentials 130 to their smartphone and could provide them to anyone (e.g., verifier 140) who requests identification.” (para. 0045);
and the VC being signed by an institution DID; (“On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “The issuer may generate a verifiable credential 130 according to the stored verification data 115. In particular, the verifiable credential 130 may include attributes and values that correspond to the schema 118 and definition 117. In addition, the verifiable credential 130 may be signed using a private key that corresponds to the key 119 of the verification data 115.” (Para. 0019); “For example, an insurance company may use the credential application creator 150 to create a verifiable credential 130 for members that includes attributes such as account number, member name, and plan details such as deductible and co-pay information. The credential application creator 150 may generate a credential issuing application 155 that the insurance company may use to generate verifiable credentials 130 that are distributed to each member. In addition, the credential application creator 150 may generate credential verification applications 157 that the insurance company issuer 110 may distribute to medical providers (e.g., hospitals, clinics, and doctors' offices) who may want to verify the patients who present the credential 130 in exchange for medical services.” (Para. 0038)
and sending, to the client device, the VC. (“After generating the verifiable credential 130, the issuer 110 may transmit the verifiable credential 130 to the holder 120 through the network 190. The holder 120 may then store the verifiable credential 130 on the computing device (e.g., smart phone) associated with the holder 120.” (Para. 0020); “At 250, the signed credential is sent to a holder. The signed verifiable credential 130 may be sent by the issuer 110 to the holder 120. The holder 120 may then store the signed verifiable credential 130 on a computing device or smartphone associated with the holder 120.” (Para. 0056); “The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014).
Richardson does not disclose:
• “the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased” (claim 20).
However, as per Claim 20, Michelsen in the analogous art of secured digital transactions, teaches: “the VC comprising at least an authorization amount, the authorization amount representing an account balance that has been increased or decreased”. (See “The host computer system 105-a may receive data 205 via the network interface 210, directly or indirectly, from a receiver of funds and a sender of funds (e.g., receiver 110 or sender 115 of FIG. 1). The receiver module 215 may receive various information to initiate a funds transfer from the funds receiver, and store the information in data stores(s) 220. The receiver module 215 may receive identification of the prospective sender by name, account number, email address, or another alphanumeric sender identifier unique to or otherwise identifying the sender. The receiver module 215 may also receive a requested funds transfer amount (which may be the same, or different, from the amount actually transferred, as there may be fees involved)”. (para. 0033); “When the sender identifier and amount is received, the transfer decision module 230 may determine whether further authorization is needed. If so, the transfer decision module 230 may cause the transmitter 235 to transmit data 240 requesting authorization to the prospective sender of funds.” (para. 0034); “The host computer system 105 may receive a first amount of funds associated with the funds transfer and sourced from the sender, and transfer a second amount of funds associated with the funds transfer, the second amount lower than the first amount. The transfer may be made before, or after, the authorization is received and/or confirmation of receipt of payment. For example, in one embodiment, the transfer may occur only once the authorization has been received at the host computer system 105, and upon confirmation of receipt of payment. For example, the funds may be transferred upon receiving the funds or receiving a real time confirmation of receipt of payment from sender's 115 bank account, debit card, or credit card. The sender 115 may also have a balance maintained with the funds transfer service provider from which the funds may be debited.” (para. 0026).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Richardson with the technique of Michelsen to include a feature to credentialize authorization amounts in an authentication process conducted by a server. Therefore, the incentives of providing increased data interoperability, auditability, and security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 22, Richardson teaches:
The method of claim 21, wherein: the VC is a second VC: the authorization amount is a second authorization amount: the account balance is a second account balance; and the method, prior to receiving the transfer DID, further comprises: generating the first account DID that corresponds to the first user record; generating a first VC for the first account DID, the first VC comprising at least a first authorization amount, the first authorization amount representing a first account balance, and the first VC being signed by a first private key associated with the institution DID; and sending, to the client device, the first account DID and the first VC. (“The issuer may generate a verifiable credential 130 according to the stored verification data 115. In particular, the verifiable credential 130 may include attributes and values that correspond to the schema 118 and definition 117. In addition, the verifiable credential 130 may be signed using a private key that corresponds to the key 119 of the verification data 115.” (Para. 0019); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015); “After generating the verifiable credential 130, the issuer 110 may transmit the verifiable credential 130 to the holder 120 through the network 190. The holder 120 may then store the verifiable credential 130 on the computing device (e.g., smart phone) associated with the holder 120.” (Para. 0020)
As per Claim 23, Richardson teaches:
The method of claim 22, further comprising revoking the first VC in response to generating the second VC. (“In some embodiments, the issuers 110 may be able to withdraw a verifiable credential 130 once issued. In these embodiments, each issuer 110 may maintain a list or registry of the verifiable credential 130 that were withdrawn on the public datastore 125. The list may use the unique identifiers that are associated with each verifiable credential 130.” (Para. 0026); “An issuer 110 may desire to withdraw verifiable credential 130 for a variety of reasons. Examples include expiration of the verifiable credential 130 (e.g., an issuer 110 may issue a verifiable credential 130 that is only valid for a day, week, or year), failure to pay for the verifiable credential 130 (e.g., a user may pay a monthly to use the credential 130), and a change of circumstances of the holder 120 (e.g., a user may be no longer employed by the issuer 110 and may no longer be eligible for the credential 130).” (Para. 0027); “In addition, a holder 120 may lose the verifiable credential 130 and may request a new verifiable credential 130 from the issuer 110. The issuer 110 may provide the new verifiable credential 130 and may add an identifier of the lost verifiable credential 130 to the list of revoked verifiable credentials 130. For example, a holder 120 may lose the smartphone or mobile device that stores the verifiable credential 130 and may request that a new verifiable credential 130 be sent to a replacement device.” (Para. 0028)
As per Claim 24, Richardson teaches:
The method of claim 21, wherein: the institution DID is a first institution DID; the first account DID is associated with the first institution DID; the first institution DID is stored on a distributed ledger; the second account DID is associated with a second institution DID; and the second institution DID is stored on the distributed ledger. (“The public DID 116 may be the DID associated with the issuer 110. The key 119 may be a public key associated with the issuer 110. The public key 119 may be part of the key pair that includes the private key used by the issuer 110 to digitally sign the verifiable credential 130 generated by the issuer 110. The schema 118 may identify the attributes that are expected in the verifiable credential 130. The definition 117 may describe the values that are acceptable for the attributes of the schema. Depending on the embodiment, the attributes may include a unique identifier of verifiable credential, and the DID of the issuer 110.” (Para. 0017); “The holder 120 may be a computing device such as a smartphone or tablet computer associated with the individual entitled to the verifiable credential 130. In some embodiments, the holder 120 may execute an application or app (e.g., wallet app) that stores and manages the verifiable credential 130 on his/her computing device. Depending on the embodiment, the holder 120 may be associated with a decentralized identifier (“DID”) that uniquely identifies the holder 120. The issuer 110 may or may not know the identity of the holder 120 when providing the verifiable credential 130.” (Para. 0014); “On request of the holder 120 (or automatically in response to the holder 120 meeting one or more requirements or performing one or more tasks), the issuer 110 may generate a verifiable credential 130 for the holder 120. The verifiable credential 130 may be a digital certificate signed using a private key associated with the issuer 110. The verifiable credential 130 may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120, as well as descriptive data about the verifiable credential 130, such as a description of the status or achievement associated with the verifiable credential 130. For example, if the verifiable credential 130 is proof of participation in an insurance plan, the attributes may include the name of the insurance plan and a co-pay or deductible associated with the insurance plan. The attributes may also include an identifier that uniquely identifies the verifiable credential 130.” (Para. 0015)
As per Claim 25, Richardson teaches:
The method of claim 24, further comprising verifying a third VC was signed by a second private key associated with the second institution DID, the third VC being associated with the second account DID. (“After retrieving the verification data 115, the verifier 140 may verify the verifiable credential 130 using the verification data 115. Initially, verifier 140 may verify the verifiable credential 130 using the key 119. If the key 119 is able to successfully decrypt the portion of the verifiable credential 130 that is digital signed using the key 119, then the verifier 140 may be ensured that the verifiable credential 130 was in fact signed by the issuer 110.” (Para. 0024); “At 210, verification data is generated. The verification data 115 may be generated by the issuer 110 and may be used by one or more verifiers 140 to verify a verifiable credential 130. In some embodiments, the verification data 115 may include, but is not limited to, a public DID 116 of the issuer 110, a schema 118 and definition 117 that describe the expected contents or format of the verifiable credential 130, and a key 119. The key 119 may be a public key associated with the issuer 110 and may be part of a key pair associated with the issuer 110 of the verifiable credential 130.” (Para. 0052).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20210272120 (Murdoch), discussing “. . . a computing system of a subject entity is configured to generate one or more claims, each of which includes at least information related to (1) a DID, (2) a property of a subject entity that is an owner of the DID, and (3) a value corresponding to the property. The claim is then signed with a private key associated with the corresponding DID to generate a cryptographic signature. The cryptographic signature proves that the claim is issued by the owner of the corresponding DID. Since the claim is issued by the subject entity and is about the subject entity, the claim is called a self-issued claim. A portion of data related to the self-issued claim is then propagated onto a distributed ledger.” (Para. 0008)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697
Prosecution Insights