DETAILED ACTION
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 .
Claim Status
As of the Office Action issued on November 18, 2025 claims 1-20 were pending and claims 1-20 stood rejected. Claims 1-2, 5-9, 12-16 and 19-20 have been amended. No claims have been added or cancelled. Claims 1-20 are therefore currently pending and are presented for examination on the merits.
Response to Arguments
Applicant’s argument with regard to the 35 U.S.C. § 101 has been fully considered but is not persuasive. Making a transfer request, validating a balance credential and verifying that the user owns the balance credential (i.e. that the credential is legitimate) are clearly part of a fundamental economic practice under Prong One of Step 2A because while the form may be different in a computer environment the actions of making transfer requests, validating balances and verifying that the validated balance is clearly tied to the user making the transfer request (such as having a notary stamped document or certified check) constitute practices that have been practiced in some form for decades if not centuries. Therefore the claim is clearly directed towards an abstract idea and is ineligible under Prong One. With regard to Prong Two of Step 2A Applicant cites the portions of the claim that encompass the abstract idea as being evidence that the claim is directed towards eligible subject matter. However MPEP § 2106.05(f) assigns these types of operations to the category of mere instructions to apply an exception that would factor against a determination of eligibility. The remainder of the elements amount to either insignificant extra solution activity as they relate to data gathering and outputting (MPEP § 2106.05(g)) or tie the abstract idea to a particular technological environment (MPEP § 2106.05(h)). Viewing the claim as a whole does not change the results of the analysis as there is no technological problem being solved as defined by MPEP § 2106.05(f). Therefore under Prong Two of Step 2A the claims are deemed ineligible. With regard to Step 2B the only consideration is to whether any of the operations identified in Prong Two of Step 2A involving data gathering and outputting involve any activity that is not well-understood, routine and conventional. Further examination indicates that these activities only involve receiving and transmitting data over a network such as the Internet which has been held as being insufficient to provide an inventive concept under Step 2B (MPEP § 2106.05(d)). Therefore as the eligibility analysis has been performed exactly as the MPEP requires the present rejection under section 101 is clearly valid and the present rejection will be maintained.
Applicant’s argument with regard to the 35 U.S.C. § 112 (b) of claims 1-20 has been fully considered and is persuasive. Accordingly the rejection is being withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 112 (b) of claims 1-20 as being unpatentable over Oberhauser in view of Sporny and in view of Reed has been fully considered but is not persuasive. Sporny is not “silent” with regard to a DID document as Sporny teaches the use of JSON Web Tokens at 6.3.1 to express claims to be transferred between parties which teaches an example of a DID document. Furthermore the previously cited example 4 on page 35 contains an id element which per the definition of the label ID provided immediately above Example 4 is “…The value of the id property MUST be a single URI. It is RECOMMENDED that dereferencing the URIresults in a document containing machine-readable information about the identifier” where the document being referenced is the DID document URI for obtaining the DID document. Examiner would also point out that the recitation from the discussion “variable credentials do not depend on DIDs and DIDs do not depend on verifiable credentials” is being read out of context as Example 4 contains the label ID for the DID identifier and Example 4 is teaching a case where the verifiable credential and the DID are linked. Therefore as the arguments have been addressed and held as unpersuasive the present rejection under section 103 is being maintained.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In examining claim 1 Examiner first will establish the broadest reasonable interpretations of the terminology in the claim by providing definitions of the terms “credential” and “decentralized identity identifier” as used in the claim as part of the finding as to whether particular language either can be construed as being an abstract idea as defined by MPEP § 2106.04 or an element under MPEP § 2106.05. A decentralized identifier is defined by the World Wide Web Consortium (hereinafter W3C, the organization responsible for managing the standard regarding decentralized identifiers) as follows:
“Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URLs that associate a DID subject with a DID document allowing trustable interactions associated with that subject” (Abstract)
“As individuals and organizations, many of us use globally unique identifiers in a wide variety of contexts. They serve as communications addresses (telephone numbers, email addresses, usernames on social media), ID numbers (for passports, drivers licenses, tax IDs, health insurance), and product identifiers (serial numbers, barcodes, RFIDs)… The Decentralized Identifiers (DIDs) defined in this specification are a new type of globally unique identifier designed to enable individuals and organizations to generate our own identifiers using systems we trust, and to prove control of those identifiers (authenticate) using cryptographic proofs (for example, digital signatures, privacy-preserving biometric protocols, and so on)”. (Section 1 Introduction)
“This specification does not require any particular technology or cryptography to underpin the generation, persistence, resolution or interpretation of DIDs…This enables implementers to design specific types of DIDs to work with the computing infrastructure they trust (e.g., blockchain, distributed ledger, decentralized file system, distributed database, peer-to-peer network).” (Section 1 Introduction)
(From Reed et al. “Decentralized Identifiers (DIDs) v1.0 core architecture, data model and representations, W3C Working Draft 13 July 2020”, 113 pages, retrieved from https://web.archive.org/web/20200929122223/https://www.w3.org/TR/2020/WD-did-core-20200713/ hereinafter referred to as Reed)
A decentralized identifier per Reed is simply therefore a form of globally unique identifier which is data per se and is neither an abstract idea under MPEP § 2106.04 or an element under MPEP § 2106.05.
With regard to the balance credential Reed defines a verifiable credential (under the context of a decentralized identifier) as follows:
“A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate presentations and then share these presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance.”
Therefore the balance credential is a verifiable credential per Reed representing the balance in an account which is also data per se and is neither an abstract idea under MPEP § 2106.04 or an element under MPEP § 2106.05. Examiner will now proceed
Claim 1 recites a system comprising a computing device comprising a processor and a memory and therefore meets Eligibility Step 1 of MPEP § 2106.03 (I) as a system that comprises a processor and a memory is a machine as the system is recited as consisting of a combination of devices and is therefore directed towards eligible subject matter under MPEP § 2106.03.
The analysis then proceeds to Prong One of Eligibility Step 2A (MPEP § 2106.04) where the claim is evaluated in order to determine whether the claim is directed towards a judicial exception under MPEP § 2106.04(a)(2) (Abstract Idea Grouping) or MPEP § 2106.04(b) (Law of Nature, Natural Phenomena & Products of Nature). The claim recites receiving a transfer request, validating a balance credential based at least in part on a decentralized identity identifier (DID) received from the user device satisfies a minimum balance, verifying ownership of the balance credential and executing the transfer request in response to validating the balance credential and verifying the ownership of the balance credential. These operations can be viewed as fundamental economic practices or principles as making and receiving a transfer request, validating that a balance satisfies a minimum balance for the transfer, verifying that the balance is actually the balance for the user making the transaction request and if the balance is sufficient and is verified as being for the user who made the request than executing the transfer request is analogous to mitigating settlement risk (MPEP § 2106.04(a)(2)(A)(i)), which also can be viewed as being directed towards a commercial interaction (MPEP § 2106.04(a)(2)(B)). It should also be pointed that cryptography in general and zero-knowledge proof algorithms in particular involve computations using mathematical formulas and therefore can also be viewed as falling under a separate category of abstract ideas (MPEP § 2106.04(a)(2)(I)(B)). Therefore claim 1 is directed towards an abstract idea and is deemed as being ineligible under Prong One of Step 2A.
The analysis then proceeds to Prong Two of Step 2A where the claim is evaluated in order to determine whether the claim recites additional elements that integrate the abstract idea into a practical application of the abstract idea (MPEP § 2106.04(d)). The claim recites elements of a computing device comprising a processor and a memory along a distributed ledger and with one of either a cryptographic challenge or a zero-knowledge proof algorithm for verifying ownership of the credential. The cryptographic challenge per paragraph 0033 relies on encryption of data by a private key of the user device which would rely on either elliptic curve cryptography or RSA algorithm per paragraph 0044 such that the encrypted challenge may be verified with the corresponding public key. The zero-knowledge proof algorithm is not specified in the written disclosure and is being interpreted as being directed towards any algorithm known in the prior art that allows a prover to prove the truth of a statement to another party (a verifier) without revealing any information beyond the validity of the statement. The written disclosure does not describe anything that would appear to be directed towards an improvement of the functioning of the processor or the memory (0013 “The first computing environment 103 can include one or more computing devices that include a processor, a memory, and/or a network interface”) (MPEP § 2106.04(d), MPEP § 2106.05(a)(I)) and while the written disclosure describes the addressing of security and privacy concerns (0007 “…Typically, to verify that the minimum balance is satisfied, the financial entity associated with the one or more financial accounts can be contacted using a third-party entity (e.g., Yoodle®, Plaid®, etc.) to obtain the financial account data associated with the one or more financial accounts…this can lead to security and privacy concerns as credential data for accessing the financial account data may be required and the third-party entities accessing the financial account data must be trusted to not sell and/or improperly use the accessed data or the credential data”) however these improvements would appear to rely only on the use of known cryptographic algorithms (0044 “…elliptic curve cryptography (ECC) approaches or using the Rivest-Shamir-Adleman (RSA) algorithm”) and zero-knowledge proofs where the proof algorithm is simply described as a “zero-knowledge proof algorithm” (0023) where the written disclosure only references a term used by those of ordinary skill to describe any algorithm that exhibits the property of allowing a verifier to prove the truth of a statement with respect to a variable without knowledge of the underlying variable (0023 “As such, the proving party is in possession of information that is not provided to the verifying party, and the verifying party is able to prove that the information is what the proving party asserts the information to be through a performance of the steps of the zero-knowledge proof”). No technological improvement is apparent in either the cryptographic algorithms or the zero-knowledge proof algorithm. The distributed ledger only serves as a storage for the credential information (0031 “…the balance claim 124 included in the DID document 121 that is associated with the DID 127 of the user and stored in the distributed identity ledger 112”) and no technological improvement is apparent to this element (MPEP § 2106.05(a)(I)). No other technological field is described in the written disclosure and therefore there is no improvement to any other technology or technical field (MPEP § 2106.05(a)(II)). No other meaningful limitations are present that would integrate the abstract idea into a practical application (MPEP § 2106.05(e)). The operations of receiving a transfer request and executing the transfer request can be viewed as data gathering and outputting and are therefore categorized under insignificant extra solution activity as all claims require inputting and outputting of data (MPEP § 2106.05(g)). The operations of initiating a verification session, validating a balance credential and verifying that the user owns the balance credential are merely instructions to implement the abstract idea (MPEP § 2106.05(f)). Therefore under Prong Two of Step 2A claim 1 is deemed as being ineligible.
The analysis then proceeds to Step 2B where the claim is evaluated in order to determine whether a claim amounts to significantly more than the abstract idea itself (MPEP § 2106.05). The claim recites elements of a computing device comprising a processor and a memory along a distributed ledger and with one of either a cryptographic challenge or a zero-knowledge proof algorithm for verifying ownership of the credential. The cryptographic challenge per paragraph 0033 relies on encryption of data by a private key of the user device which would rely on either elliptic curve cryptography or RSA algorithm per paragraph 0044 such that the encrypted challenge may be verified with the corresponding public key. The zero-knowledge proof algorithm is not specified in the written disclosure and is being interpreted as directed towards any algorithm that allows for the proving of the truth of an assertion regarding a variable without knowledge of the underlying variable. The written disclosure does not describe anything that would appear to be directed towards an improvement of the functioning of the processor or the memory (0013 “The first computing environment 103 can include one or more computing devices that include a processor, a memory, and/or a network interface”) (MPEP § 2106.05(a)(I)) and while the written disclosure describes the addressing of security and privacy concerns (0007 “…Typically, to verify that the minimum balance is satisfied, the financial entity associated with the one or more financial accounts can be contacted using a third-party entity (e.g., Yoodle®, Plaid®, etc.) to obtain the financial account data associated with the one or more financial accounts…this can lead to security and privacy concerns as credential data for accessing the financial account data may be required and the third-party entities accessing the financial account data must be trusted to not sell and/or improperly use the accessed data or the credential data”) these improvements would appear to rely only on the use of known cryptographic algorithms (0044 “…elliptic curve cryptography (ECC) approaches or using the Rivest-Shamir-Adleman (RSA) algorithm”) and zero-knowledge proofs where the proof algorithm is simply described as a “zero-knowledge proof algorithm” (0023) where the algorithm is not actually disclosed (0023 “As such, the proving party is in possession of information that is not provided to the verifying party, and the verifying party is able to prove that the information is what the proving party asserts the information to be through a performance of the steps of the zero-knowledge proof”). No technological improvement is apparent in either the cryptographic algorithms or the zero-knowledge proof algorithm. The distributed ledger only serves as a storage for the credential information (0031 “…the balance claim 124 included in the DID document 121 that is associated with the DID 127 of the user and stored in the distributed identity ledger 112”) and no technological improvement is apparent to this element (MPEP § 2106.05(a)(I)). No other technological field is described in the written disclosure and therefore there is no improvement to any other technology or technical field (MPEP § 2106.05(a)(II)). The operations of receiving a transfer request and executing the transfer request can be viewed as data gathering and outputting and are therefore categorized under insignificant extra solution activity as all claims require inputting and outputting of data (MPEP § 2106.05(g)). The operations of initiating a verification session, validating a balance credential and verifying that the user owns the balance credential are merely instructions to implement the abstract idea (MPEP § 2106.05(f)). The operations of receiving a transfer request and executing the transfer request are among the types of operations that courts have recognized as well-understood, routine and conventional activity as the merely require receiving and transmitting data over a network. No other meaningful limitations are present that would integrate the abstract idea into a practical application (MPEP § 2106.05(e)). Therefore under Step 2B claim 1 is deemed as being ineligible.
Claim 2 contains much of the language of claim 1 with regard to the balance credential being verified based at least in part on a DID document stored on the distributed ledger and adds that the DID document comprises a public key of a cryptographic key pair generated by a wallet of the user device. The generation of a cryptographic key pair may be considered as an additional element under MPEP § 2106.05 but as previously noted with regard to claim 1 a reliance is placed on known techniques for generating key pairs (0044 “The key-pair can be generated using various approaches, such as elliptic curve cryptography (ECC) approaches or using the Rivest-Shamir-Adleman (RSA) algorithm”) where the absence of any detailed description is indicative that these “approaches” and algorithm are not undergoing any technological improvement per MPEP § 2106.05(a)(I). Therefore claim 2 is also deemed ineligible under Prongs One and Two of Step 2A.
Claim 3 contains the operation from claim 1 of validating the balance credential and further adds language that the validating comprises determining that the balance credential is issued by a trusted entity based at least in part on a signature associated with the DID document. The written disclosure treats the signature validation in a manner that does not suggest any technological improvement (0034 “Upon receiving the signed cryptographic challenge from the client device 109, the verifier service 155 can validate the digital signature of the challenge based on the public key 141 included in the DID document 121 and extracted from the DID document. For example, the public key 141 can be used to decrypt the digital signature”) (MPEP § 2106.05(a)(I)) and only describes an obtained result MPEP § 2106.05(f)(1). Therefore claim 3 is also deemed ineligible under Prongs One and Two of Step 2A.
Claim 4 depends on claims 1 and 2 and further recites that the instructions further cause the computing device to at least extract the public key from the DID document. The extraction of a public key from the DID document can be viewed as necessary data gathering (MPEP § 2106.05(g)) as part of pre-solution activity prior to using the public key to validate the signature associated with the document. Therefore claim 4 is also deemed ineligible under Prongs One and Two of Step 2A.
Claim 5 depends on claims 1, 2 and 4 and recites “…generate the cryptographic challenge; transmit the cryptographic challenge to the user device; and receive a signed cryptographic challenge from the user device, the ownership being verified in response to determining that the cryptographic challenge is signed with a private key associated with the public key”. Here the language of the claim does not provide any restriction to how the challenge is generated which can be viewed as a recitation of an outcome (MPEP § 2106.05(f)(1)) in conjunction with language regarding the ownership being verified in response to determining that the cryptographic challenge is signed with a private key associated with the public key which relies on the language of paragraphs 0033 and 0034 as noted above with regard to claims 1 and 3 where no technological improvement is being made to a computer as the validation of a digital signature is treated by the written disclosure in a manner that suggests that no improvement is being made and that the computer is simply being used as a tool for performing the verification (MPEP § 2106.05(a)(1)). Therefore claim 5 is also deemed ineligible under Prongs One and Two of Step 2A.
Claim 6 depends on claim 1 and additionally recites that “…the ownership is verified based at least in part on the zero-knowledge proof algorithm, and the machine-readable instructions further cause the computing device to at least receive a user verification proof from the user device”. The first part of the recitation merely describes which option from claim 1 is being used to verify ownership which recited that verification could be based on “a cryptographic challenge or a zero-knowledge proof algorithm” and the language “…receive a user verification proof from the user device” is an operation that requires mere data gathering and is therefore insignificant pre-solution activity per MPEP § 2106.05(g) as the written disclosure at paragraph 0034 suggests no improvement in how the data is being gathered. Therefore claim 6 is also deemed as ineligible under Prongs One and Two of Step 2A.
Claim 7 depends on claim 6 and recites “…wherein the user verification proof is generated by a prover kit executed by the user device, and verifying the ownership further comprises verifying the user verification proof by executing a verifier kit, the prover kit and the verifier kit being based at least in part on the zero-knowledge proof algorithm”. The most detailed description in the written disclosure of the prover kit is at paragraph 0046 (“…The prover kit 146 is generated by the credential service 118 and transmitted to the client device 109 upon registration of the balance credential (e.g., DID document 121 and balance claim 124) for the user associated with the corresponding DID 127. The prover kit 146 can represent a script, application, or process that can be executed by the wallet application 136 or client application 130 generate a zero-knowledge proof for verifying user information such as user name, user address, account balance, and/or other type of user information that may need to be verified”). The verifier kit as described in the written disclosure at paragraph 0026 is nearly identical to that of the prover kit (…The verifier kit 149 can represent a script, application, or process that can be executed by the verifier service 155 in the second computing environment 106 to verify the proof that is a result of the prover kit 146 executed on the client device 109”). The recitations in the claim can be viewed as reciting only the idea of a solution because both the claim and the underlying disclosure fail to recite any details regarding the prover kit and the verifier kit other than a general recitation of representing “a script, application or process” that can be viewed as encompassing every mode of accomplishing the proving and verifying that includes every and any type of zero-knowledge proof algorithm which is also not described in any detail in the written disclosure as noted above with regard to paragraph 0023 (“As such, the proving party is in possession of information that is not provided to the verifying party, and the verifying party is able to prove that the information is what the proving party asserts the information to be through a performance of the steps of the zero-knowledge proof”) and amounts to mere instructions to apply an exception per MPEP § 2106.05(f). Therefore claim 7 is also deemed as ineligible under Prongs One and Two of Step 2A.
Claims 8-14 are directed towards the method implemented by the system of claims 1-7 and claims 15-20 are directed towards the non-transitory computer-readable medium comprising the instructions for executing the operations for performing the operations of claims 1-7 and the method of claims 8-14. No additional elements are recited in either the method or the medium claims that would alter the eligibility analysis under either Prong One or Prong Two of Step 2A. Therefore claims 8-20 are also held as being directed towards ineligible subject matter as they recite an abstract idea without integrating the abstract idea into a practical application of the abstract idea.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Oberhauser et al. (U.S. Patent Publication 2023/0039214, hereinafter referred to as Oberhauser) in view of Sporny et al. “Verifiable Credentials Data Model 1.0 Expressing verifiable information on the Web W3C Candidate Recommendation 28 March 2019, 143 pages, retrieved from https://web.archive.org/web/20190330211125/https://www.w3.org/TR/2019/CR-verifiable-claims-data-model-20190328/, hereinafter referred to as Sporny) in view of Reed et al. (“Decentralized Identifiers (DIDs) v1.0 Core architecture, data model and representations, W3C Working Draft 13 July 2020, 113 pages, retrieved from https://web.archive.org/web/20200929122223/https://www.w3.org/TR/2020/WD-did-core-20200713/ , hereinafter referred to as Reed).
As per claims 1, 8 and 15
Oberhauser discloses a processor and a memory (0317 “In the example shown in FIG. 8, the computer 1000 includes a processing unit 1001 having one or more computer hardware processors and one or more articles of manufacture that comprise at least one non-transitory computer-readable medium (e.g., memory 1002) that may include, for example, volatile and/or non-volatile memory”)
Oberhauser discloses machine-readable instructions stored in the memory executed by the processor (0322 “Also, the various methods or processes outlined herein may be coded as software that is executable on one or more processors running any one of a variety of operating systems or platforms”)
Oberhauser discloses receiving a transfer request from a user device (0027 “If the asset owner wishes to transfer the digital asset to an asset recipient, the asset owner may submit a transfer request to the custodial key service”)
Oberhauser discloses executing the transfer request in response to validating the balance credential on the distributed ledger and verifying the ownership of balance credential (0158-0163 “For instance, the data management service 110B may check that: (i) the entity that published and/or accepted the referenced attribute attestation is trusted by the entity B (e.g., by looking up a list of trusted entities); (ii) the corresponding attribute value has been verified by the trusted entity using a procedure that is acceptable to the entity B (e.g., physical examination of at least two forms of government-issued photo identification); iii) a cryptographic proof in the referenced attribute attestation is generated from the attribute value received from the entity A, and is generated using a cryptographic scheme indicated in the referenced attribute attestation; (iv) the referenced attribute attestation is in a VALID state in the distributed ledger; and/or (v) the referenced attribute attestation is signed using a private key associated with the trusted entity (e.g., a private key associated with a distributed ledger address of the trusted entity).”, 0165 “As another example, the received attribute value may be a current balance of an account of the entity A, and the entity B may check if the balance is above a selected threshold (e.g., a minimum required balance plus a proposed amount for an out-going transfer)” 0084 “Upon receiving the attribute value and the signature, the entity B (or the entity A, respectively) may use a distributed ledger address associated with the badge and/or the one or more attribute attestations to look up a public key from the distributed ledger, and may use that public key to check that both the attribute value and the distributed ledger transaction have been signed using the same private key”, claim 8 “in response to successfully checking the attestation against the commitment C and successfully performing the proof of knowledge, authorizing a proposed transfer of one or more digital assets”
Oberhauser, while disclosing the verification of a balance (0029 “As yet another example, a custodial key service may reject an attempted transfer that would cause a cryptocurrency account balance to fall below, or exceed, a selected threshold”, see also 0165), does not explicitly disclose validating a balance credential on a distributed ledger based at least in part on a decentralized identity identifier (DID) received from the user device, the balance credential claiming that a user account balance associated with a user account of a user associated with the user device satisfies a minimum balance. Sporny teaches validating a balance credential on a distributed ledger based at least in part on the DID received from the user device, the balance credential comprising a DID document and a balance claim, and the balance claim claiming that a user account balance associated with a user account of a user associated with the user device satisfies a minimum balance (7.14 “…provide a token that enables the verifier to check if the balance is above a certain amount. In this case, the bank could issue a verifiable credential containing a balance checking token to a holder. The holder would then include the verifiable credential in a verifiable presentation and bind the token to a credit checking agency using a digital signature. The verifier could then wrap the verifiable presentation in their digital signature, and hand it back to the issuer to dynamically check the account balance”, 4.2 in reference to Example 4 on page 35 “The example above uses two types of identifiers. The first identifier is for the credential and uses an HTTP-based URL. The second identifier is for the subject of the credential (the thing the claims are about) and uses a decentralized identifier, also known as a DID”, 6.1.3 “JSON Web Token (JWT) [RFC7519] is still a widely used means to express claims to be transferred between two parties. Providing a representation of the Verifiable Credentials Data Model for JWT allows existing systems and libraries to participate in the ecosystem described in Section § 1.2 Ecosystem Overview. A JWT encodes a set of claims as a JSON object that is contained in a JSON Web Signature (JWS) [RFC7515] or JWE [RFC7516]. For this specification, the use of JWE is out of scope… kid MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, the kid can refer to a key in a DID document, or can be the identifier of a key inside a JWKS.”))
Sporny teaches initiating a verification session with a wallet application of the user device in response to receiving the transfer request, the verification session being initiating to obtain a decentralized identity identifier stored in the wallet application of the user device (2 “decentralized identifier A portable URL-based identifier, also known as a DID, associated with an entity. These identifiers are most often used in a credential and are associated with subjects such that a credential itself can be easily ported from one repository to another without the need to reissue the credential. An example of a DID is did:example:123456abcdef.”, 3.4 “Storage of verifiable credentials in a credential repository (such as a digital wallet).”, 4.2 in reference to Example 4 on page 35 “The example above uses two types of identifiers. The first identifier is for the credential and uses an HTTP-based URL. The second identifier is for the subject of the credential (the thing the claims are about) and uses a decentralized identifier, also known as a DID”)
Sporny teaches verifying that the user owns the balance credential based at least in part on a zero-knowledge proof algorithm (7.14 “…provide a token that enables the verifier to check if the balance is above a certain amount. In this case, the bank could issue a verifiable credential containing a balance checking token to a holder. The holder would then include the verifiable credential in a verifiable presentation and bind the token to a credit checking agency using a digital signature. The verifier could then wrap the verifiable presentation in their digital signature, and hand it back to the issuer to dynamically check the account balance”, page 17 definition of presentation, “Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs)”, see also section 5.8 regarding zero-knowledge proofs)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
Oberhauser in view of Sporny do not explicitly disclose the verification of an ownership of a balance credential that is tied to a decentralized identity identifier and based at least in part on a cryptographic challenge. Reed (which is also published by W3C and references Sporny at pages 21 and 86 at section 9.2.3 in defining a verifiable credential “A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C [VC-DATA-MODEL].”, see also page 113 where the Sporny document is listed by title, date, authors with hyperlink to Sporny) (9.2.2 Proving Control of a Public key “If the DID document is not signed, control of a public key described in the DID document can still be proven dynamically as follows:
Send a challenge message containing a public key description from the DID document and a nonce to an appropriate service endpoint described in the DID document.
Verify the signature of the response message against the public key description.”, 9.2.3 Authentication and Verifiable Claims “A DID and DID document do not inherently carry any PII (personally-identifiable information). The process of binding a DID to something in the real world, such as a person or a company, for example with credentials with the same subject as that DID, is out of scope for this specification. For more information, see the [VC-DATA-MODEL] instead”) (Where VC-DATA-MODEL is a reference to Sporny)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny with the decentralized identifiers of Reed for the purpose of proving that the entity (holder) of the decentralized identifier was in control of the private key corresponding to a public key description in the DID document (9.2.1 and 9.2.2)
As per claims 2, 9 and 16
Sporny teaches wherein the balance credential is verified based at least in part on the DID document stored on the distributed ledger, the DID document comprising a public key of a cryptographic key pair generated by a wallet of the user device (page 11 “verifiable data registry: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas and revocation registries, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem”, page 15 in section 2 “decentralized identifier document A document that is accessible using an verifiable data registry and contains information related to a specific decentralized identifier, such as the associated repository and public key information”, page 20 in section 3.2 “A credential is a set of one or more claims made by the same entity. Credentials might also include an identifier and metadata to describe properties of the credential, such as the issuer, the expiry date and time, a representative image, a public key to use for verification purposes, the revocation mechanism, and so on. The metadata might be signed by the issuer. A verifiable credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
As per claims 3, 10 and 17
Sporny teaches wherein validating the balance credential further comprises determining that the balance credential is issued by a trusted entity based at least in part on a signature associated with the DID document (page 124 “A.2 Issuer The value associated with the issuer property is expected to identify an issuer that is known to and trusted by the verifier. Relevant metadata about the issuer property is expected to be available to the verifier. For example, an issuer can publish information containing the public keys it uses to digitally sign verifiable credentials that it issued. This metadata is relevant when checking the proofs on the verifiable credentials”, page 15 “credential A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects… decentralized identifier document A document that is accessible using an verifiable data registry and contains information related to a specific decentralized identifier, such as the associated repository and public key information”, page 17 “issuer A role an entity might perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Presentation Data derived from one or more credentials, issued by one or more issuers, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).”
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
As per claims 4, 11 and 18
Sporny teaches extracting the public key from the DID document (page 124 “The value associated with the issuer property is expected to identify an issuer that is known to and trusted by the verifier. Relevant metadata about the issuer property is expected to be available to the verifier. For example, an issuer can publish information containing the public keys it uses to digitally sign verifiable credentials that it issued. This metadata is relevant when checking the proofs on the verifiable credentials”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
As per claims 5, 12 and 19
Sporny teaches a balance credential (7.14 “…provide a token that enables the verifier to check if the balance is above a certain amount. In this case, the bank could issue a verifiable credential containing a balance checking token to a holder. The holder would then include the verifiable credential in a verifiable presentation and bind the token to a credit checking agency using a digital signature. The verifier could then wrap the verifiable presentation in their digital signature, and hand it back to the issuer to dynamically check the account balance”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
Reed teaches generating the cryptographic challenge (9.2.2 Proving Control of a Public key “If the DID document is not signed, control of a public key described in the DID document can still be proven dynamically as follows:
1. Send a challenge message containing a public key description from the DID document and a nonce to an appropriate service endpoint described in the DID document”)
Reed teaches transmitting the cryptographic challenge to the user device (9.2.2 Proving Control of a Public key “If the DID document is not signed, control of a public key described in the DID document can still be proven dynamically as follows:
1. Send a challenge message containing a public key description from the DID document and a nonce to an appropriate service endpoint described in the DID document”)
Reed teaches receive a signed cryptographic challenge from the user device, the ownership being verified in response to determining that the cryptographic challenge is signed with a private key associated with the public key (9.2.2 Proving Control of a Public key
“2. Verify the signature of the response message against the public key description.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny with the decentralized identifiers of Reed for the purpose of proving that the entity (holder) of the decentralized identifier was in control of the private key corresponding to a public key description in the DID document (9.2.1 and 9.2.2)
As per claims 6 and 13
Sporny teaches wherein ownership of the balance credential by the user is verified based at least in part on the zero-knowledge proof algorithm, and the machine-readable instructions further cause the computing device to at least receive a user verification proof from the user device (7.14 “…provide a token that enables the verifier to check if the balance is above a certain amount. In this case, the bank could issue a verifiable credential containing a balance checking token to a holder. The holder would then include the verifiable credential in a verifiable presentation and bind the token to a credit checking agency using a digital signature. The verifier could then wrap the verifiable presentation in their digital signature, and hand it back to the issuer to dynamically check the account balance”, page 17 definition of presentation, “Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs)”, see also section 5.8 regarding zero-knowledge proofs)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
As per claims 7 and 14
Sporny teaches wherein the user verification proof is generated by a prover kit executed by the user device, and verifying that the user owns the balance credential further comprises verifying the user verification proof by executing a verifier kit, the prover kit and the verifier kit being based at least in part on the zero-knowledge proof algorithm (A.4 “In general, when verifying proofs implementations are expected to ensure that: The proof is available in the form of a known proof suite. All required proof suite properties are present. The proof verification suite algorithm, when applied to the data, results in an acceptable proof.”, 5.8 “The key capabilities introduced by zero-knowledge proof mechanisms are: 1. The ability of a holder to combine multiple verifiable credentials from multiple issuers into a single presentation without revealing credential or subject identifiers to the verifier. This makes it more difficult for the verifier to collude with any of the issuers regarding the issued credentials. 2. The ability of a holder to selectively disclose the claims in a credential to a verifier without requiring the issuance of multiple atomic credentials. This allows a holder to provide a verifier with precisely the information they need and nothing more. 3. The ability of a holder to produce a derived credential that is formatted according to the verifier's data schema rather than the issuer's, without needing to involve the issuer after credential issuance. This provides a great deal of flexibility for holders to use the credentials they have been issued”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
As per claim 20
Sporny teaches wherein ownership of the balance credential by the user is verified based at least in part on the zero-knowledge proof algorithm, and the machine-readable instructions, when executed by the processor, further cause the computing device to at least receive a user verification proof from the user device (7.14 “…provide a token that enables the verifier to check if the balance is above a certain amount. In this case, the bank could issue a verifiable credential containing a balance checking token to a holder. The holder would then include the verifiable credential in a verifiable presentation and bind the token to a credit checking agency using a digital signature. The verifier could then wrap the verifiable presentation in their digital signature, and hand it back to the issuer to dynamically check the account balance”, page 17 definition of presentation, “Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs)”, see also section 5.8 regarding zero-knowledge proofs)
Sporny teaches the user verification proof being generated by a prover kit executed by the user device, and verifying that the user owns the balance credential further comprises verifying the user verification proof by executing a verifier kit, the prover kit and the verifier kit being based at least in part on the zero-knowledge proof algorithm (A.4 “In general, when verifying proofs implementations are expected to ensure that: The proof is available in the form of a known proof suite. All required proof suite properties are present. The proof verification suite algorithm, when applied to the data, results in an acceptable proof.”, 5.8 “The key capabilities introduced by zero-knowledge proof mechanisms are: 1. The ability of a holder to combine multiple verifiable credentials from multiple issuers into a single presentation without revealing credential or subject identifiers to the verifier. This makes it more difficult for the verifier to collude with any of the issuers regarding the issued credentials. 2. The ability of a holder to selectively disclose the claims in a credential to a verifier without requiring the issuance of multiple atomic credentials. This allows a holder to provide a verifier with precisely the information they need and nothing more. 3. The ability of a holder to produce a derived credential that is formatted according to the verifier's data schema rather than the issuer's, without needing to involve the issuer after credential issuance. This provides a great deal of flexibility for holders to use the credentials they have been issued”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the system and method for compliance checks of Oberhauser with the verifiable credentials of Sporny for the purpose of expressing credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
Pertinent Art not Cited
Smith et al. (U.S. Patent Publication 2020/0211099, hereinafter referred to as Smith) discloses the creation of a digital wallet and use of zero-knowledge proofs for determining that a credit score exceeds a minimum value and that a bank balance exceeds a minimum value (Abstract, 0010). Smith discloses the use of decentralized identifiers (DIDs) (0053) and the use of verifiable credentials (Abstract).
Lopez, “Self-Sovereign Identity The Future of Identity: Self-Sovereignty, Digital Wallets, and Blockchain”, Inter-American Development Bank, September 14, 2020, 106 pages discloses digital identities in general including different types of identity providers and provides an overview of methods and types of identity verification including those involving decentralized identifiers, distributed ledgers and blockchain.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 6:00 to 9:45 and 10:30 to 2:45.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. 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.
/JAMES D NIGH/Senior Examiner, Art Unit 3699
Prosecution Insights