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 1, 7-8, 14-15, 18-19, and 21-23 are currently amended.
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 4/14/2026 has been entered.
Response to Remarks
35 U.S.C. § 101
Remark 1: Applicant argues that claims 1-8 and 14-25 do not recite an abstract idea because the claimed DID/VC transfer protocol is not a mental process and does not fall within enumerated categories of certain methods of organizing human activity, particularly where a human mind cannot practically perform receiving a transfer peer DID or generating a VC. Applicant further argues that, even assuming an abstract idea is recited, the claims integrate it into a practical application and provide significantly more because they allegedly solve a technical problem, namely, the absence of a standard protocol for DID holders to authorize transfers using DID and VCs, through the claimed use of transfer peer DIDs, authorization services, VCs, authorization amounts, and institution-signed credentials.
(Applicant Arguments, 2026-03-31)
Response to Remark 1: Applicants argument is unpersuasive because the claims recite the abstract idea of authorizing, recording, and communicating a transfer between account records using identifiers. The use of DIDs and VCs does not remove the claim from the ‘certain methods of organizing human activity’ grouping because the claimed focus remains a commercial transfer authorization and account-balance update, not an improvement to DID or VC technology itself. The fact that a human mind cannot literally generate a digital credential does not control where the claim is directed, because the claim still automates an underlying financial authorization and recordkeeping process using generic computing components. We should further note that MPEP 2106.04(a)(2)(III) explains that mental processes include concepts that can be performed in the human mind with or without the use of a physical aid, and that merely implementing such processes on a computer does not remove them from the mental-process grouping. Thus, the applicants reliance on DIDs, VCs, and digital signatures is not dispositive, because the claim remains directed to receiving, evaluating, authorizing, and recording transfer information, activities that reflect abstract data processing and decision-making merely performed using generic computer implementation.
Remark 2: Applicant argues “In addition, assuming solely for the sake of argument, and without conceding that the claims were directed to an abstract idea, claims 1-8 and 14-25 are nevertheless patent-eligible because claims 1-8 and 14-25 recite a technical solution to a technical problem as determined under Step 2A, Prong 2. In the discussion of whether a claim is directed to patent-ineligible subject matter under Step 2A, MPEP § 2106.04(d)(1) states that "[a] claim reciting a judicial exception is not directed to the judicial exception if it also recites additional elements demonstrating that the claim as a whole integrates the exception into a practical application. One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field." (emphasis added). Moreover, as stated in MPEP § 2106.05(a) "[a]n indication that the claimed invention provides an improvement [to the functioning of a computer or to any other technology or technical field] can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art." Claims 1-8 and 14-25 satisfy this standard. Applicant's Specification discusses how claims 1-8 and 14-25 serve to at least improve the functioning of computers in a technological environment related to transfer protocols using decentralized identifiers and verifiable credentials. Applicant's Specification at paragraphs [0015] states (with emphasis added): [0015] Disclosed are various approaches for a transfer protocol using decentralized identifiers (DIDs) and verifiable credentials (VCs). DIDs are unique identifiers that enable individuals, organizations, or things to have verifiable and self-owned digital identities. DIDs can be used for various purposes, but no standard protocol exists for holders of DIDs to authorize a transfer of information by another party using DIDS and VCs. By utilizing DIDs and VCs, fraud could be prevented, and users can gain greater trust in the system. Applicant respectfully submits that "no standard protocol exists for holders of DIDs to authorize a transfer of information by another party using DIDS and VCs" represents a technical problem which can be solved by using a technical solution, as claimed in claims 1-8 and 14-25. For example, claim 1 recites: 1. 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; authorize a transfer with an authorization service based at least in part on the transfer peer DID; receive, from the authorization service, a confirmation that the transfer has been completed; 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. Claim 1 recites a technical improvement by including elements such as "a transfer peer decentralized identifier," a "verifiable credential," "an authorization service," and "an authorization amount." Additionally, the machine-readable instructions cause the computing device to "receive a transfer peer DID" and "authorize a transfer... based at least in part on the transfer peer DID" by performing various claims operations. Applicant submits that at least these features of amended claim 1 provide a technical solution to a technical problem as the features of amended claim 1 allow for "holders of DIDs to authorize a transfer of information by another party using DIDS and VCs" (Applicant's Specification, [0015]). Because Applicant is claiming a technical solution to a technical problem, claim 1 integrates any alleged abstract idea into a practical application under Step 2A Prong Two. Insofar as claims 14 and 21 recite subject matter similar to that recited in claim 1, Applicant respectfully submits that claims 14 and 21 are patent-eligible for similar reasons, to the extent applicable. Applicant also respectfully submits that claims 2-8, 15-20, and 22-25 are patent-eligible as depending from claims 1, 14, and 21, respectively. Moreover, Applicant also respectfully submits that at least one of claims 2- 8, 15-20, and 22-25 may also be patent-eligible due to the additional subject matter recited therein that would integrate at least one of these claims into a practical application of an alleged abstract idea. Accordingly, Applicant respectfully requests that the rejections of claims 1-8 and 14-25 under 35 U.S.C. § 101 be withdrawn.” (id).
Response to Remark 2: Applicants asserted ‘technical problem’ is framed as the lack of a standard protocol for DID/VC-based transfer authorization, but the claim does not recite a specific improvement to computer functionality, cryptographic processing, network operation, or DID resolution. Richardson shows that using DIDs, schemas, keys, public datastores, signed VCs, and transmission to holders were known credential operations, including that the holder may be associated with a DID and that the VC may include issuer and holder DIDs. The claim merely applies those known credential operations to a transfer authorization workflow, which does not integrate the abstract idea into a practical application.
Remark 3: Applicant argues “In addition, assuming solely for the sake of argument, and without conceding that the claims were directed to an abstract idea, claims 1-8 and 14-25 are nevertheless patent-eligible because at least claims 1, 14, and 21 as amended recite additional elements that are sufficient so as to amount to significantly more than the judicial exception as determined under Step 2B. According to MPEP § 2106.05, Step 2B asks (emphasis added):
Does the claim recite additional elements that amount to significantly more than the judicial exception? Examiners should answer this question by first identifying whether there are any additional elements (features/limitations/steps) recited in the claim beyond the judicial exception(s), and then evaluating those additional elements individually and in combination to determine whether they contribute an inventive concept (i.e., amount to significantly more than the judicial exception(s)). Further, MPEP § 2106.05(I)(A) states that claims recite "significantly more" than an abstract idea when they are found to: [add] a specific limitation other than what is well-understood, routine, conventional activity in the field, or [add] unconventional steps that confine the claim to a particular useful application, e.g., a non-conventional and non-generic arrangement of various computer components for filtering Internet content, as discussed in BASCOM Global Internet v. AT&T Mobility, LLC, 827 F.3d 1341, 1350-51, 119 USPQ2d 1236, 1243 (Fed. Cir. 2016) (see MPEP § 2106.05(d)). Applicant respectfully submits that claims 1-8 and 14-25 satisfy this standard. Even if the claims are considered to recite only elements that are well- understood, routine, and conventional when considered individually, 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, amended claim 1 recites "receiv[ing] a transfer peer decentralized identifier (DID) comprising at least a first account peer DID, a second account peer DID, instructions to initiate a transfer for a transfer amount" (emphasis added) and "authoriz[ing] a transfer with an authorization service based at least in part on the transfer peer DID" (emphasis added) and "generat[ing] a verifiable credential (VC)." The recited elements of the claim are directed to using a verifiable credential and at least one decentralized identifier in relation to authorizing 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.” (id).
Response to Remark 3: Applicants step 2B argument is also unpersuasive because the alleged ‘non-conventional arrangement’ is recited only at a functional level: receive identifier/instructions, authorize transfer, generate credential, and send credential. Richardson teaches generating a VC with attributes/values corresponding to a schema and signing it with a private key, while Michelson teaches receiving a requested transfer amount, sender identifier, authorization, and transferring funds, showing the claimed components and functions were known in the art.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “The Office Action indicates on page 29 that claims 1-8 and 14-25 stand rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Richardson, IV et al. U.S. Pub. No. 2023/0164143, hereinafter "Richardson") in view of Michelsen (U.S. Pub. No. 2011/0225088, hereinafter "Michelsen"). Applicant requests that the rejection of claim 1 be withdrawn for at least the following reasons. Applicant respectfully submits that the cited references fail to teach, disclose, or suggest at least the elements of claim 1 emphasized below: 1. 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; authorize a transfer with an authorization service based at least in part on the transfer peer DID; receive, from the authorization service, a confirmation that the transfer has been completed; 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.
The Office Action asserts on pages 29 and 30: 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. Briefly, in making this rejection, the Office Action (page 30 and 31) makes reference to a "holder 120" that "may be associated with a decentralized identifier ('DID') that uniquely identifies the holder" (paragraph [0014] of Richardson), "a verifiable credential 130 [that] may further include a plurality of attributes that includes values such as a DID of the issuer 110, the DID of the holder 120" (paragraph [0015] of Richardson), and "[t]he 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" (paragraph [0033] of Richardson). Applicant respectfully disagrees with this assessment. Paragraph [0016] of Richardson, states that "[t]o facilitate the generation of verifiable credentials 130, the issuer 110 may generate and store verification data 115... In some embodiments, the verification data 115 may include a public DID 116" (emphasis added). Further, in paragraph [0053], Richardson states that "[a]t 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" (emphasis added). As states in paragraph [0031] of the Applicant's Specification "[p]eer decentralized identifiers (peer DIDs) are an extension of the traditional DID concept, such that it allows for the creation of DIDs without the need for an external blockchain or distributed ledger" (emphasis added). Therefore, Applicant respectfully submits that Richardson fails to teach, disclose, or suggest receiving a "transfer peer decentralized identifier" of amended claim 1. Furthermore, Applicant respectfully asserts that Richardson fails to teach, disclose, or suggest a DID or a "transfer peer 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" of amended claim 1. The Office Action further asserts on page 30 that Richardson discloses "generate a verifiable credential (VC) for the first account peer DID,... by the transfer amount, ("holder 120 verify the amount that was deposited." Applicant respectfully disagrees. Applicant notes that referenced paragraph [0050] of Richardson relates to an example use case of "proof of bank account control" where "[t]he holder 120 may be an individual that has an account with the bank," "[t]he verifier 140 may be an entity that wants to make a payment to the account of the holder 120," and "[t]he credentials 130 in this case would serve as proof that the holder 120 is in control of the bank account." The reference to "the holder 120 verify[ing] the amount that was deposited" of paragraph [0050] is stated in the context of: "[c]urrently such proof is provided by the verifier 140 depositing a few cents into the account, and then having the holder 120 verify the amount that was deposited" which is provided as a comparison to the example use case of proof of bank account control but not as an example use case itself. Therefore, Applicant respectfully submits that Richardson fails to teach, disclose, or suggest receiving a "generate a verifiable credential (VC) for the first account peer DID,... by the transfer amount" of amended claim 1. The Office Action asserts on page 34 that 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." Applicant agrees. However, Applicant respectfully disagrees with the Office Action's assertion on page 34 that Michelsen teaches this element of claim 1. In making this assertion, the Office Action refers to paragraphs [0026], [0033], and [0034] of Michelsen. 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 host computer system 105 may receive a first amount of funds associated with the funds transfer and sourced from the sender" (paragraph [0026]) and "[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]). Michelsen makes refers to "a first amount of funds associated with the funds transfer" (paragraph [0026]) and "a requested funds transfer amount" (paragraph [0033]). However, Applicant respectfully submits that Michelsen fails to teach, disclose, or suggest "the VC comprising at least an authorization amount, the authorization amount represent[s] an account balance that has been increased or decreased by the transfer amount" of amended claim 1 (emphasis added). Furthermore, Applicant respectfully submits that the combination of Richardson and Michelsen fail to teach, disclose, or suggest "authoriz[ing] a transfer with an authorization service based at least in part on the transfer peer DID" and "receiving, from the authorization service, a confirmation that the transfer has been completed" of amended claim 1.” (id).
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 26, 34, and 25 of Michelsen, and as further outlined in paragraph 43-45 of this action. Indeed, the rejection relies on Richardson for the DID/VC credential framework and Michelson for the transfer-amount and authorization workflow. Richardson teaches a holder DID, issuer DID, VC attributes, issuer signing, verification data, and transmission of the generated credential, while Michelson teaches receiving authorization, and transferring funds responsive to the receiver initiation. 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;
authorize a transfer with an authorization service based at least in part on the transfer peer DID;
receive, from the authorization service, a confirmation that the transfer has been completed
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 peer 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 peer 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 that cause the first computing device to authorize the transfer with the authorization service, when executed by the processor, further cause the first computing device to at least authorize the transfer with the authorization service based at least in part on the first transfer peer DID and the second transfer peer DID.
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;
authorize a transfer with an authorization service based at least in part on the transfer peer DID;
receive, from the authorization service, a confirmation that the transfer has been completed
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 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 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 peer 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 peer 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 peer 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;
authorizing a transfer with an authorization service based at least in part on the transfer peer DID;
receiving, from the authorization service, a confirmation that the transfer has been completed
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 peer 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, 14, and 21, 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:
• “authorize a transfer with an authorization service based at least in part on the transfer peer DID; receive, from the authorization service, a confirmation that the transfer has been completed” (claim 1).
However, as per Claim 1, Michelsen in the analogous art of secured digital transactions, teaches: “authorize a transfer with an authorization service based at least in part on the transfer peer DID; receive, from the authorization service, a confirmation that the transfer has been completed”. (See “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 sender module 225 may receive data 205 to authorize the funds transfer from the sender, and store this data in data store(s) 220.” (para. 0035); “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.” (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 authorizing a transfer with an authorization service based at least in part on the transfer peer DID and receiving, from the authorization service, a confirmation that the transfer has been completed. Therefore, the incentives of improving transfer security provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
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 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 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
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