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 .
Acknowledgements
This Office Action is in response to the amendment received on 09/09/2025.
Claims 1, 6, 9 and 16 were amended.
Claims 1-20 are pending.
Claims 1-20 were examined.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-8 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 was amended to recite “in response to the verification request, determining, by the holder service, a least amount of user data included in the one or more credentials that meets one or more identification requirements of the verification request; generating, by the holder service based on the determining, an attestation proof that does not include an entirety of the one or more verifiable credentials stored in the holder wallet...”. The specification as filed recites, inter alia:
[0065] At 740, the server system generates, by the holder service in response to receiving the verification request, an attestation proof that does not include an entirety of the one or more credentials stored in the holder wallet. In some embodiments, the attestation proof is generated using one or more portions of user data included in one or more credentials stored in the holder wallet based on determining whether the one or more portions of user data include information meeting requirements of the verification request received from the verifier service for credentials of the holder entity. For example, the server system may determine whether one or more individual verifiable credentials include the necessary user data to satisfy an identification request from a verifier entity. As one specific example, the server system may determine if a first verifiable credential includes passport number for the user and determine if a second verifiable credential includes a bank account number for the user, when a verifier entity is an airline requesting identification and payment information for the user for an international flight the user is attempting to book.
[0068] At 750, the server system sends, by the holder service to the verifier service, a response to the verification request that includes the attestation proof. In some embodiments, a response that includes less than the entirety of the one or more credentials stored in the holder wallet is a reduced subset of the available user data stored in the holder wallet. For example, the reduced subset may be referred to as a “minimal set of user data” and includes a DID document (DDO) including a formal description of a verifiable credential, a public key for verification, a set of authentication protocols, one or more service endpoints, a timestamp, and a signature. In some embodiments, the holder service receives, from the verifier service, a confirmation message indicating that the less than the entirety of the one or more credentials included in the response are accepted by the verifier.”
Therefore, the specification as filed does not recite the manner in which “a least amount of user data” is determined by the holder service as part of a "determining" step, prior to generating the attestation proof, since the claims recite the attestation proof is generated “based on” this determining. It appears Applicant attempts to equate “a least amount of user data… that meets the one or more identification requirements of the verification request” to “the server system may determine whether one or more individual verifiable credentials include the necessary user data to satisfy an identification request from a verifier entity.” as described in the specification. The claims require a determination which would require an algorithm in order to determine what is a “least amount of data”, otherwise the claim scope would cover all algorithms for this determination, known or not yet known. The specification as filed, however, merely discloses determining if one or more credentials have sufficient data to fulfill the request. Examiner also notes that the claims do not require this “least amount of user data” of the determining step to be part of the attestation proof or any other subsequent step. Examiner also notes the “reduced subset” as described in paragraph [0068] is directed to additional embodiments describing data elements included in a response that includes the attestation proof. Therefore, the specification as filed does not provide sufficient written description for the claimed language (see MPEP 2161.01). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. Dependent claims 2-8 are also rejected since they depend on claim 1.
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.
Examiner notes the independent claims are not commensurate in scope. Therefore, for compact prosecution purposes and in order to avoid overlooking diverging scopes, the claims were addressed individually below.
Claims 1-20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over w3.org Verifiable Credentials Use Cases (NPL 2022) hereinafter W3UC, in view of w3.org Verifiable Credentials Data Model v1.1 (NPL 2021), hereinafter W3DM, in view of Lux et al. (NPL 2020) and in view of Li et al. (US 2020/0274713 A1).
With respect to claim 1, W3UC teaches a method (w3.org Verifiable Credentials Use Cases) comprising:
receiving, by a holder service executing on a server computer system from an issuer service, one or more verifiable credentials of a holder entity (see Fig. 4, page 27, Example credential creation flow, page 28: "5. The issuer delivers the verifiable credential back to Jane's User Agent". Examiner considers the "holder service" as the "user agent" and the "credential repository");
storing, by the holder service in a wallet of the holder entity, the one or more verifiable credentials (see Fig. 4, page 27, Example credential creation flow, page 28: "7. When she is satisfied, she instructs her User Agent to save the verifiable credential so she can use it in the future. 8. The UA communicates with her credential repository, instructing it to store the new verifiable credential.");
receiving, by the holder service from a verifier service, a verification request for credentials of the holder entity, the verification request including one or more identification requirements (see Fig. 5, pages 28 and 29, "6.2 How a Verifiable Credential Might Be Used"; page 29: "2. The merchant's site requires Jane be 21 years of age and requests (via a user agent-supported API call) that Jane prove this." Examiner notes the "credential consumer" is the verifier (see item 7));
in response to the verification request, determining, by the holder service, [a derived credential] (see Fig. 5, pages 28 and 29: "5. The credential repository shows Jane some verifiable credentials it holds that can support her age claim (e.g., her passport, driving license, and birth certificate). 6.Jane selects one of these, and authorizes that it be shared with the merchant.");
sending, by the holder service to the verifier service, a response to the verification request (see Fig. 5, pages 28 and 29, "6. The credential repository returns the selected credential as a response to the user agent-supported API call, which in turn delivers it to the merchant."); and
receiving, by the holder service from the verifier service, a confirmation message for the attestation proof (see Fig. 5, pages 28 and 29, "7. The merchant's server verifies that the claim is valid and satisfies the requirement; 8. The merchant redirects the user agent to the web site with appropriate authorization").
W3UC does not explicitly disclose a method comprising: [the derived credential] is a least amount of user data included in the one or more verifiable credentials that meets the one or more identification requirements of the verification request; generating, by the holder service based on the determining, an attestation proof that does not include an entirety of the one or more verifiable credentials stored in the holder wallet; the response to the verification request includes the attestation proof, a formal description of the one or more verifiable credentials used to generate the attestation proof, and a public key; and wherein the confirmation message is received in response to the verifier service verifying, via a blockchain and based on the formal description and the public key, a decentralized identifier (DID) of an issuer entity corresponding to the one or more verifiable credentials used to generate the attestation proof.
However, W3DM discloses a method (Verifiable Credentials Data Model v1.1) comprising:
generating, by the holder service based on the determining, an attestation proof that does not include an entirety of the one or more verifiable credentials stored in the holder wallet (see verified presentation, page 43: "Presentations MAY be used to combine and present credentials. They can be packaged in such a way that the authorship of the data is verifiable. The data in a presentation is often all about the same subject, but there is no limit to the number of subjects or issuers in the data. The aggregation of information from multiple verifiable credentials is a typical use of verifiable presentations. A verifiable presentation is typically composed of the following properties:.. verifiableCredential: If present, the value of the verifiableCredential property MUST be constructed from one or more verifiable credentials, or of data derived from verifiable credentials in a cryptographically verifiable format." page 44, presentations used derived credentials, "Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer. For example, a verifiable credential containing the claim date of birth might be used to derive the presented value over the age of 15 in a manner that is cryptographically verifiable. That is, a verifier can still trust the derived value if they trust the issuer... Selective disclosure schemes using zero-knowledge proofs can use claims expressed in this model to prove additional statements about those claims. For example, a claim specifying a subject's date of birth can be used as a predicate to prove the subject's age is within a given range, and therefore prove the subject qualifies for age-related discounts, without actually revealing the subject's birthdate. The holder has the flexibility to use the claim in any way that is applicable to the desired verifiable presentation.");
the response to the verification request includes the attestation proof, a formal description of the one or more verifiable credentials used to generate the attestation proof, and a public key (see pages 24 and 25, Example 2, a simple example of a verifiable presentation, including "proof" (i.e. attestation proof), "type" (i.e. a formal description of the one or more verifiable credentials used to generate the attestation proof / "AlumniCredential") and "verification method" (i.e. public key - Examiner notes Example 1, page 22, discloses "the identifier of the public key that can verify the signature" as the "verification method" in page 23)). wherein the confirmation message is received in response to the verifier service verifying... based on the formal description and the public key, a... [credential]... of an issuer entity corresponding to the one or more verifiable credentials used to generate the attestation proof (see pages 101, 102, A. Validation, 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.')
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the urging verifiers to only request information that is absolutely necessary for a specific transaction to occur as disclosed by W3DM in the method of W3UC, the motivation being to reducing the liability on the verifier for handling highly sensitive information that it does not need to and enhancing the privacy of the individual by only asking for information required for a specific transaction. (see W3DM, page 86).
Although W3DM discloses a verifiable data registry, which is a role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, 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, and one of ordinary skill in the art would reasonably determine a blockchain being a distributed ledger (see page 8), the combination of W3UC and W3DM does not explicitly disclose a method comprising: [the derived credential] is a least amount of user data included in the one or more verifiable credentials that meets the one or more identification requirements of the verification request; [the verifier service verifying the DID] via a blockchain, and the credential being a decentralized identifier (DID).
However, Lux et al. disclose a method (Distributed-Ledger based Authentication with decentralized identifier and verifiable credentials) comprising:
[the derived credential] is a least amount of user data included in the one or more verifiable credentials that meets the one or more identification requirements of the verification request (see page 72: "VCs support selective disclosure, so end users can prove claims about their identity without revealing more information than they intend and need for performing a specific action. For example, when Jane orders her preferred wine in an online wine store, she only proves to the seller that she is older than 18 (assuming 18 to be the legal drinking age), which can be achieved by generating a proof about this date of birth using her passport VC. Furthermore, Jane does not even have to share the exact date, as it is sufficient for her to generate a zero-knowledge proof stating that she is older than 18.")
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the verifiable credentials details like zero knowledge proofs and PKI/connection establishment mechanisms as disclosed by Lux et al. in the method of W3UC and W3DM, the motivation being to allow users to freely choose from a very large pool of identity providers instead of just a select few corporations and to create a straightforward and verifiable way to retrieve digital certificates (see Lux et al., abstract).
The combination of W3UC, W3DM and Lux et al. does not explicitly disclose a method comprising: [the verifier service verifying the DID] via a blockchain, and the credential being a decentralized identifier (DID).
However, Li et al. disclose a method (Credential verification and issuance through credential service providers) comprising:
[the verifier service verifying the DID] via a blockchain, and the credential being a decentralized identifier (DID) (see paragraph [0022]: “To perform the verification, the second credential management system 150 also needs to retrieve credential verification information from a distributed ledger stored in a distributed identify blockchain 170 via a second node 160 of the blockchain 170. In one embodiment, the first node 130 of the blockchain 170 is operated by the first credential service provider, e.g. SoftBank and the second node 160 of the blockchain 170 is operated by the second credential service provider, e.g. ATT. If the verifier IBM office management successfully verifies the requested credentials, it will issue an office access permission (a new credential) to the credential owner, e.g. John Smith. The office access permission can be represented by a separate QR code or even in other forms/formats.”; paragraph [0027]: “...Through their credential service providers, issuers and credential owners can create their DIDs and publish the DIDs, associated public keys, credential schemas, credential definitions, and revocation accumulators in the blockchain 170 by recording related information in blocks of a distributed ledger...” ).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the decentralized credential verification via a blockchain as disclosed by Li et al. in the method of W3UC, W3DM and Lux et al., the motivation being to avoid the need of centralized verification infrastructure, which is very expensive to build/maintain. Since a centralized database is usually not available to the general public because of privacy data protection concerns, the verifier has to contact the centralized server to verify the document, and when the centralized site is down, the verifications stop (see Li et al., paragraph [0003]).
With respect to claim 2, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, W3UC disclose a method wherein the attestation proof is a compound proof that is generated by the holder service using one or more portions of user data included in multiple different credentials stored in the holder wallet (see, inter alia, page 17 Focal use cases, "where a blend of features from verifiable credentials standard may be used together to solve complex or challenging market needs"; page 18, 5.1 Citizenship by Parentage, Verifiable credentials including birth certificate, marriage license, mother's passport, Sam's passport in order to present a US citizenship claim.); Regarding the BRI of the claim, Examiner notes that claim 2 recites “wherein the attestation proof is a compound proof that is generated by the holder service using one or more portions of user data included in multiple different credentials stored in the holder wallet.”, language directed to non-functional descriptive material. See MPEP 2111.05. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 3, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Li et al. disclose a method wherein prior to the holder entity receiving the one or more credentials, the issuer service: writes, to the blockchain for respective credentials, a DID of the issuer entity, a schema of respective ones of the one or more credentials, and a public key; and adds, to a revocation registry of the blockchain for respective ones of the one or more credentials, entries specifying whether the respective credentials have been revoked (see paragraph [0025]: “Each credential has a number of attributes. For example, a driver license credential may have attributes of driver license number, last name, first name, date of birth, height, weight, gender, photo, signature, expiration date, and issuing state. A credential schema is a machine-readable definition of a set of attribute data types and formats that can be used for the claims on a credential. Each credential has its schema. For example, a schema for creating driver license credentials would include definition of above described attributes. An issuer can use a schema to create its own credential definition containing the schema and the attribute specific public verification keys that are paired with the private signing keys of the issuer. For example, California DMV has its own driver license credential definition stored in the distributed identify blockchain. Thus, a verifier or its credential service provider can retrieve the CA driver license credential definition to verify the origin and integrity of that data provided by a credential owner or his/her credential service provider.”; paragraph [0027]: “...Through their credential service providers, issuers and credential owners can create their DIDs and publish the DIDs, associated public keys, credential schemas, credential definitions, and revocation accumulators in the blockchain 170 by recording related information in blocks of a distributed ledger...” Examiner notes the "revocation registry of the blockchain" maps to the "revocation accumulators in the blockchain 170). Examiner also notices Hamel discloses, in Fig. 2A, paragraph [0122]: “FIG. 2A is a diagram illustrating an embodiment of a system for credential storing and verifying using a distributed ledger.... DCIAMS 2A04 is able to verify the credential by checking the credential against information placed in distributed ledger 2A08. In various embodiments, a credential schema, the credential itself, and a revocation table that are stored by issuer 2A00 on distributed ledger 2A08 can be used to check that a credential is legitimate. DCIAMS 2A04 can then provide requestor 2A06 with a verification that the credential supplied by a user held on holder device 2A02.”). Regarding the BRI of the claim, Examiner notes that claim 3 is a method claim and recites “the issuer service: writes, to the blockchain for respective credentials, a DID of the issuer entity, a schema of respective ones of the one or more credentials, and a public key; and adds, to a revocation registry of the blockchain for respective ones of the one or more credentials, entries specifying whether the respective credentials have been revoked....”, language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 4, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 1. W3UC disclose a method wherein the one or more credentials of the holder entity are received from at least one issuer entity (see Fig. 4, page 29, item 5: "The issuer delivers the verifiable credential back to Jane's User Agent.").
Further, Li et al. teach a method wherein the holder service receives the one or more credentials by:
causing, by the holder service via a user interface of a holder device of the holder entity, display of a scannable code; in response to the scannable code being scanned by an issuer device of the issuer entity, establishing, by the holder service, a... connection between the holder device and the issuer device; and receiving, by the holder service from the issuer service via the... connection, a transmission of at least one of the one or more credentials (see paragraph [0021]: “The first credential management system 120 of the first credential service provider generates a QR code and submits it back to the requesting device 110. The QR code comprises the information of sharing credential token and service endpoint of the first credential management system. Such information can be represented and transmitted in other forms and formats. The credential owner John then presents the QR code on the requesting device 110 to the verifier IBM office management which uses a verifying device 140, e.g. a mobile phone or an internet device, to scan the QR code. The verifying device 140 sends the QR code to a second credential service provider, e.g. ATT, a US telecommunication carrier IBM subscribes. A second credential management system 150 of the second credential service provider receives the QR code. The second credential management system 150 identifies the first credential management system 120 to be contacted for the proof of credentials from the information in the QR code. Then the second credential management system 150 of ATT communicates directly with the first credential management system 120 of SoftBank to obtain a proof of the credentials.”; Examiner notes that Fig. 5 describes an embodiment of credential issuance, in which "a verifier becomes an issuer at a second stage if the verification is successful", see paragraph [0038]: “FIG. 5 illustrates an embodiment of the process flow of issuing a new credential. This embodiment assumes that the second credential management system 150 of the second service provider has the service endpoint of the first credential management system 120 of the first credential service provider. One possibility is that the second credential management system 150 received the service endpoint when it performed the credential verification for the issuer who previously acted as a verifier. In another embodiment, the requesting device 110 of the credential owner may provide such service endpoint to the second credential management system via the verifier. At the beginning, the credential owner requests for a new credential. The issuer notifies the second credential management system if it approves the new credential request. At step 510, the second credential management system generates a credential offer for the issuer, which comprises the data of the required attributes for the new credential, e.g. visitor's name and date for a daily office access permission. At step 520, the second credential management system 150 sends the credential offer to the first credential management system 120. At step 530, the first credential management system 120 signs the credential offer with the credential owner's private key to generate the credential request. At step 540, the first credential management system 120 sends the credential request back to the second credential management system 150. At step 550, the second credential management system 150 signs the credential request with the issuer's private key to generate the new credential. At step 560, the second credential management system 150 sends the new credential to the first credential management system 120. At step 570, the first credential management system 120 stores the new credential for the credential owner and notifies the credential owner. Below is an embodiment of the pseudo code performing the following process steps where a verifier becomes an issuer at a second stage if the verification is successful.”).
Lastly, Lux et al. further teach a method the connection is a secure connection (see Page 75: "A design decision about DID authentication for OIDC is if we conduct the VC proof and DID exchanges in one or two steps. Note, that a single step VC exchange can only be done once the SSI OIDC Provider has already established a pairwise DID connection, i.e., unique DIDs and related keys are already exchanged, with the end user, or if both parties have a public DID written on the distributed ledger. Furthermore, the SSI OIDC Provider also needs to know the DID of the user beforehand, so the proof request can be sent to the holder. For the one-step proof exchange communication between the holder and verifier can be encrypted and decrypted with the public and private keys of their DIDs. 1) Authentication via an SSI mobile wallet app: We need three things when using Hyperledger Indy: (1) an established pairwise connection between the IdP (issuer) and the user (holder), (2) knowledge about matching VC types, and (3) knowing which user we are authenticating. A pairwise connection between the SSI IdP and the holder can be established via scanning a QR code displayed on the SSI IdP’s website with an SSI smartphone wallet app.");
Regarding the BRI of the claim, Examiner notes that claim 4 recites “in response to the scannable code being scanned by an issuer device of the issuer entity, establishing, by the holder service, a secure connection between the holder device and the issuer device; and receiving, by the holder service from the issuer service via the secure connection, a transmission of at least one of the one or more credentials” , language directed to contingent limitations. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 5, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 4. Furthermore, Lux et al. disclose a method wherein the one or more credentials transmitted via the secure connection are encrypted using a DID of the issuer entity, and wherein the secure connection is a pairwise connection formed using a pairwise DID of the issuer entity and a pairwise DID of the holder entity (see Fig. 1, issuer signs and issues digital credentials, Identity holder countersigns credential definition and presents verifiable credentials to verifier. Page 75: "A design decision about DID authentication for OIDC is if we conduct the VC proof and DID exchanges in one or two steps. Note, that a single step VC exchange can only be done once the SSI OIDC Provider has already established a pairwise DID connection, i.e., unique DIDs and related keys are already exchanged, with the end user, or if both parties have a public DID written on the distributed ledger. Furthermore, the SSI OIDC Provider also needs to know the DID of the user beforehand, so the proof request can be sent to the holder. For the one-step proof exchange communication between the holder and verifier can be encrypted and decrypted with the public and private keys of their DIDs. 1) Authentication via an SSI mobile wallet app: We need three things when using Hyperledger Indy: (1) an established pairwise connection between the IdP (issuer) and the user (holder), (2) knowledge about matching VC types, and (3) knowing which user we are authenticating. A pairwise connection between the SSI IdP and the holder can be established via scanning a QR code displayed on the SSI IdP’s website with an SSI smartphone wallet app."). Regarding the BRI of the claim, Examiner notes that claim 5 recites “wherein the one or more credentials transmitted via the secure connection are encrypted using a DID of the issuer entity”; “wherein the secure connection is a pairwise connection formed using a pairwise DID of the issuer entity and a pairwise DID of the holder entity”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 6, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Lux et al. disclose a method wherein the verification request for credentials of the holder entity from the verifier service is received in response to: causing, by the holder service, a scan of a quick response (QR) code displayed via a user interface of a verifier device associated with a verifier entity utilizing the verifier service; and transmitting, by the holder service in response to the scanning establishing a secure connection between the holder service and the verifier service, the one or more credentials from a holder device to the verifier device. (see Fig. 2. connection request via display/scan QR, user logged in, page 76: "Sequence diagram of integrating OIDC-Authorization-Code-Flow-based SSO with SSI... If the user does not yet have a connection, then this can be established by scanning a QR code with the identity wallet mobile app. The OIDC Provider then sends a proof request to the end user (identity holder). Next, the identity holder can decide whether to respond to the proof and thereby perform the login... 4) OpenID connect client: In order to test our prototype, we have created a website, where the user logs in with his/her SSI credentials. The website then redirects the user to the SSI OIDC Provider, where the authentication is performed. If the process succeeds, then the client website receives the ID token"). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 7, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 6. Furthermore, Li et al. disclose a method
wherein the DID of the issuer entity is usable by the verifier service to verify authenticity via the blockchain of one or more holder credentials received by the verifier service (see paragraph [0027]: “The distributed identity blockchain 170 comprises a plurality of nodes. In one embodiment, the first node 130 is operated by the first credential service provider and the second node 160 is operated by the second credential service provider. In one embodiment, TBCASOFT Inc. (“TBCA”) can be an administrator of the distributed identity blockchain 170. TBCA can admit credential service providers to operate nodes of the blockchain 170 and select some of the nodes to serve as validators for the consensus mechanism. Through their credential service providers, issuers and credential owners can create their DIDs and publish the DIDs, associated public keys, credential schemas, credential definitions, and revocation accumulators in the blockchain 170 by recording related information in blocks of a distributed ledger..."; paragraph [0035]: “At step 246, the first credential management system 120 sends the proof to the second credential management system 150. At step 250, the second credential management system 150 requests the second node 160 of the distributed identity blockchain 170 to retrieve credential cryptography information, including the schema, the schema definition, the issuer's public key, the credential owner's public key, from the distributed ledger stored in the distributed identity blockchain 170.”; ) and
wherein verification of credential authenticity is performed by comparing the DID of the issuer entity received with the attestation proof from the holder service with one or more DIDs of the issuer entity stored on the blockchain (see paragraph [0036]: “At step 255, the second node 160 provides the above credential cryptography information back to the second credential management system 150. At step 260, the second credential management system 150 verifies the proof based on the above credential cryptography information retrieved from the distributed ledger. The zero knowledge proof algorithm may be used for verifying the proof.”).
Regarding the BRI of the claim, Examiner notes that claim 7 is a method claim and recites “wherein the DID of the issuer entity is usable by the verifier service to verify authenticity via the blockchain of one or more holder credentials received by the verifier service...”“wherein verification of credential authenticity is performed by comparing the DID of the issuer entity received with the attestation proof from the holder service with one or more DIDs of the issuer entity stored on the blockchain...” , language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 8, the combination of W3UC, W3DM, Lux et al. and Li et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, W3UC disclose a method wherein the confirmation message for the attestation proof is further received in response to the verifier service determining, via the blockchain, whether the issuer entity has revoked one or more of the one or more credentials used to generate the attestation proof. (see 4.6 Revoke Claim Requirement: It MUST be possible for the issuer of a claim to revoke it, after which it will no longer satisfy verification procedures. Motivation: An entity (issuer) discovers that a claim they have issued and are endorsing for an end user (subject), is no longer valid and wishes to revoke the issued claim. Examples: F.3 Closing account, C.2 Busy doctor, C.3 Bad university. Examiner notes w3.org Data Model discloses the verification being performed via a distributed ledger, and Li et al disclose the verification being performed "via a blockchain"). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 9, W3UC teaches a non-transitory computer-readable medium having program instructions stored thereon (w3.org Verifiable Credentials Use Cases) comprising:
receiving, from an issuer service, a set of holder data of a holder entity (see Fig. 4, page 27, Example credential creation flow, page 28: "5. The issuer delivers the verifiable credential back to Jane's User Agent". Examiner considers the "holder service" as the "user agent" and the "credential repository");
storing the set of holder data in a wallet of the holder entity (see Fig. 4, page 27, Example credential creation flow, page 28: "7. When she is satisfied, she instructs her User Agent to save the verifiable credential so she can use it in the future. 8. The UA communicates with her credential repository, instructing it to store the new verifiable credential.");
receiving, from a verifier service, a verification request for credentials of the holder entity, the verification request including identification requirements (see Fig. 5, pages 28 and 29: "6.2 How a Verifiable Credential Might Be Used”; "2. The merchant's site requires Jane be 21 years of age and requests (via a user agent-supported API call) that Jane prove this". Examiner notes the "credential consumer" is the verifier (see item 7));
in response to the verification request, determining a subset of holder data included in the set of holder data (see Fig. 5, pages 28 and 29: "5. The credential repository shows Jane some verifiable credentials it holds that can support her age claim (e.g., her passport, driving license, and birth certificate). 6.Jane selects one of these, and authorizes that it be shared with the merchant");
sending, to the verifier service, a response to the verification request (see Fig. 5, pages 28 and 29: "6. The credential repository returns the selected credential as a response to the user agent-supported API call, which in turn delivers it to the merchant."); and
receiving, by the holder service from the verifier service, a confirmation message for the attestation proof (see Fig. 5, pages 28 and 29:, "7. The merchant's server verifies that the claim is valid and satisfies the requirement; 8. The merchant redirects the user agent to the web site with appropriate authorization").
W3UC does not explicitly disclose a medium comprising: the subset of holder data satisfies the identification requirements of the verification request; generating, based on the determining, an attestation proof that includes the subset of the set of holder data stored in the holder wallet; the response to the verification request includes the attestation proof, a formal description of the subset of the set of holder data used to generate the attestation proof, and a public key; and wherein the confirmation message is received in response to the verifier service verifying, via a blockchain and based on the formal description and the public key, a DID of an issuer entity corresponding to the subset of the set of holder data used to generate the attestation proof.
However, W3DM discloses a medium (w3.org Verifiable Credentials Data Model v1.1) comprising:
generating, based on the determining, an attestation proof that includes the subset of the set of holder data stored in the holder wallet (see verified presentation, page 43: "Presentations MAY be used to combine and present credentials. They can be packaged in such a way that the authorship of the data is verifiable. The data in a presentation is often all about the same subject, but there is no limit to the number of subjects or issuers in the data. The aggregation of information from multiple verifiable credentials is a typical use of verifiable presentations. A verifiable presentation is typically composed of the following properties:.. verifiableCredential: If present, the value of the verifiableCredential property MUST be constructed from one or more verifiable credentials, or of data derived from verifiable credentials in a cryptographically verifiable format." page 44, presentations used derived credentials, "Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer. For example, a verifiable credential containing the claim date of birth might be used to derive the presented value over the age of 15 in a manner that is cryptographically verifiable. That is, a verifier can still trust the derived value if they trust the issuer... Selective disclosure schemes using zero-knowledge proofs can use claims expressed in this model to prove additional statements about those claims. For example, a claim specifying a subject's date of birth can be used as a predicate to prove the subject's age is within a given range, and therefore prove the subject qualifies for age-related discounts, without actually revealing the subject's birthdate. The holder has the flexibility to use the claim in any way that is applicable to the desired verifiable presentation.");
the response to the verification request includes the attestation proof, a formal description of the subset of the set of holder data used to generate the attestation proof, and a public key (see pages 24 and 25, Example 2, a simple example of a verifiable presentation, including "proof" (i.e. attestation proof), "type" (i.e. a formal description of the one or more verifiable credentials used to generate the attestation proof / "AlumniCredential") and "verification method" (i.e. public key - Examiner notes Example 1, page 22, discloses "the identifier of the public key that can verify the signature" as the "verification method" in page 23)). wherein the confirmation message is received in response to the verifier service verifying... based on the formal description and the public key, a... [credential]... of an issuer entity corresponding to the one or more verifiable credentials used to generate the attestation proof (see pages 101, 102, A. Validation, 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.').
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the urging verifiers to only request information that is absolutely necessary for a specific transaction to occur as disclosed by W3DM in the medium of W3UC, the motivation being to reducing the liability on the verifier for handling highly sensitive information that it does not need to and enhancing the privacy of the individual by only asking for information required for a specific transaction. (see W3DM, page 86).
The combination of W3UC and W3DM does not explicitly disclose a medium comprising: the subset of holder data satisfies the identification requirements of the verification request; [the verifier service verifying the DID] via a blockchain, and the credential being a decentralized identifier (DID).
However, Lux et al. disclose a medium (Distributed-Ledger based Authentication with decentralized identifier and verifiable credentials) comprising:
the subset of holder data satisfies the identification requirements of the verification request (see page 72: "VCs support selective disclosure, so end users can prove claims about their identity without revealing more information than they intend and need for performing a specific action. For example, when Jane orders her preferred wine in an online wine store, she only proves to the seller that she is older than 18 (assuming 18 to be the legal drinking age), which can be achieved by generating a proof about this date of birth using her passport VC. Furthermore, Jane does not even have to share the exact date, as it is sufficient for her to generate a zero-knowledge proof stating that she is older than 18.").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the verifiable credentials details like zero knowledge proofs and PKI/connection establishment mechanisms as disclosed by Lux et al. in the medium of W3UC and W3DM, the motivation being to allow users to freely choose from a very large pool of identity providers instead of just a select few corporations and to create a straightforward and verifiable way to retrieve digital certificates (see Lux et al., abstract).
The combination of W3UC, W3DM and Lux et al. does not explicitly disclose a medium comprising: [the verifier service verifying the DID] via a blockchain, and the credential being a decentralized identifier (DID).
However, Li et al. disclose a medium (Credential verification and issuance through credential service providers) comprising:
[the verifier service verifying the DID] via a blockchain, and the credential being a decentralized identifier (DID) (see paragraph [0022]: “To perform the verification, the second credential management system 150 also needs to retrieve credential veri