DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
Status of Claims
The following is a non-final First Office Action on the Merits is in reply to the application filed on 08/13/2024. Claims 1-20 are pending and have been considered below.
Claim Rejections - 35 USC § 101
35 USC 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1-10 are directed to a system, claims 11-19 are directed to a computer implemented method, claims 20 is directed to computer executable instructions stored on a non-transitory storage medium.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
Per Step 2A.1. Claim 1, (which is representative of Claims 11, 20) is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. The limitations of the independent claim 1 recite an abstract idea, shown in bold, while the non-bolded claim elements recite additional element according to MPEP 2106.04(a).
[A] A system for securely accessing information of an upstream entity by a downstream entity using a verifiable credential and decentralized identifier, comprising:
[B] a non-transitory memory;
[C] a processor communicatively coupled to the non-transitory memory, wherein the processor is configured to read a set of instructions to:
[D] generate an authorization request for access to information pertaining to an upstream entity by a downstream entity, wherein the authorization request includes a decentralized identifier associated with the downstream entity;
[E] transmit the authorization request to a content storage entity;
[F] receive an authorization notification corresponding to the authorization request;
[G] retrieve an authorization token based on at least a portion of the authorization notification, wherein the authorization token includes a verifiable credential generated by the upstream entity and incorporating the decentralized identifier;
[H] generate a request transaction including a request to access the information pertaining to the upstream entity and the authorization token;
[I] provide the request transaction to the content storage entity;
[J] receive a verification challenge corresponding to the request transaction based on the verifiable credential;
[K] transmit a response to the verification challenge; and
[L] receive a reply transaction granting access to the information pertaining to the upstream entity.
Claim 1 (which is representative of claims 11, 20) recites: verifying and reading credentials ([A], [C]); generating, transmitting, and retrieving authorization request ([D]-[F]); retrieving authorization token ([G]); generation and provide a transaction request ([H]-[I]); receive and transmit a verification challenge ([J]-[K]) and granting access ([L]), which, based on the claim language and in view of the application disclosure, represents a process aimed at enabling a system for managing credentials.
This overall combination, covers managing and authenticating credentials, including generation an authorization request, generating and transmitting a verification challenge, and granting access based on the response to the challenge, Such limitations expresses evaluation, judgement, which falls under Mental Processes, i.e., Concepts Performed in the Human Mind grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that claim 1 (which is representative of claims 11, 20) recites an abstract idea that represents a judicial exception.
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the added elements “processor,” “memory,” “decentralized,” and “content storage,” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of managing credentials. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application.
The additional elements in the independent claims, shown not bolded above, recite: a system … comprising ([A]), a processor communicatively coupled to the non-transitory memory ([C]), a non-transitory memory ([B]), decentralize ([A], [D], [G]), content storage ([E], [I]). When considered individually, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional steps of claim 1 (which is representative of claims 11, 20) do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Claim 1, (which is representative of claims 11, 20) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional elements (limitations [A]-[E], [G]-[I], [L]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of managing credentials could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claims 1, 11, 20 are deemed ineligible.
Dependent Claims: Claims 2-10, 12-19 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons:
Claim 2, which is representative of claims 12, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the authorization token enables access to the information pertaining to the upstream entity as stored in a database associated with the content storage entity.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 3, which is representative of claims 13, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the request corresponds to a confirmation request for an audit of the upstream entity, and the content storage entity is an institution that maintains the information pertaining to the upstream entity.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 4, which is representative of claims 14, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the request corresponds to a confirmation request for an audit of the upstream entity, and the content storage entity is an institution that maintains the information pertaining to the upstream entity.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 5, which is representative of claims 15, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the authorization token is decrypted using a symmetric encryption key.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 6, which is representative of claims 16, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the processor is configured to encrypt the request prior to providing the request transaction.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 7, which is representative of claims 17, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein encrypting the request includes using a symmetric encryption key.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 8, which is representative of claims 18, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein generating the request transaction includes: encrypting the symmetric encryption key using a public key associated with the content storage entity; and
[B] including the encrypted symmetric encryption key in the request transaction.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 9, which is representative of claims 19, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein generating the request transaction includes generating the request transaction including an address, on a blockchain, of the upstream entity.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 10, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the processor is configured to: obtain a first hash value of the authorization token from the authorization notification;
[B] calculate a second hash value the authorization token; and
[C] compare the first hash value to the second hash value to verify the authorization token.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly
more. (See MPEP 2106.05).
In sum, Claims 1-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Belchior (SSIBAC: Self-Sovereign Identity Based Access Control) in view of Li (US 11038670 B2).
Regarding Claims 1, 11, 20. Belchior discloses:
A system for securely accessing information of an upstream entity by a downstream entity using a verifiable credential and decentralized identifier, comprising: [see at least Figs, 1, 3 (pages 1935-1936) SSI provides a model for authentication and issuing credentials. However, a structured approach to use it for authorization and access control is still missing, arguably due to its novelty. To fill this gap, we leverage three emerging technologies: blockchain, decentralized identifiers (DIDs) [15], and verifiable credentials (VCs) [16]. (page 1937, lines 9-12) The subject (that we also call user) is the entity (i.e., upstream entity) that requires access to a resource. A client is a device (i.e., downstream entity) that requests access to a resource on behalf of a subject. ]
generate an authorization request for access to information pertaining to an upstream entity by a downstream entity, wherein the authorization request includes a decentralized identifier associated with the downstream entity; [see at least Fig. 1 steps 1, 2, 4 (page 1936, lines 18-23) An entity called issuer (i.e., downstream entity) generates and signs such credentials with its private key: this enables a third-party to verify the issuer of a VC (the DID of the issuer is typically associated with the credential). A verifier can look up the public key of a given DID, associated with a given credential on a verifiable data registry (e.g., a public blockchain). (page 1938, lines 19-20) A user (i.e., upstream entity) is issued verifiable credentials (steps 1 and 2), which are rooted in a verifiable credential registry (3). The user then requests access to a set of resources (4).]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that the issuer is the downstream entity, and the user is the downstream entity. The Applicant’s specification paragraph 0005 “steps of generating an authorization request for access to information pertaining to a target entity and a blockchain address of the target entity” and Belchior discloses an entity called the issuer that generates the request and Belchior further discloses the user requests to access the information. One with the ordinary skill in the art would conclude that issuer is the downstream entity and the user is the upstream entity as issuer and the user perform the same step as the upstream and downstream entity. And, therefore one of skill in the art would have understood the reference to teach the limitation.
transmit the authorization request to a content storage entity; [see at least Figs. 1 (page 1938, lines 19-20) A user is issued verifiable credentials (steps 1 and 2), which are rooted in a verifiable credential registry (3). The user then requests access to a set of resources (4).]
retrieve an authorization token based on at least a portion of the authorization notification, wherein the authorization token includes a verifiable credential generated by the upstream entity and incorporating the decentralized identifier; [see at least (page 1936, lines 18-23 and 37-45) An entity called issuer generates and signs such credentials with its private key: this enables a third-party to verify the issuer (i.e., upstream entity) of a VC (the DID of the issuer is typically associated with the credential). A verifier can look up the public key of a given DID, associated with a given credential on a verifiable data registry (e.g., a public blockchain) … At verification time, the holder of a verifiable credential (often the subject itself) creates a verifiable presentation (VP), which contains metadata and proofs for a subset of the contained claims. The VP creation process might be required by a verifier, through a verifiable presentation request (VPR). The VP is sent to a verifier, that confirms the VC held by the subject satisfies a specific predicate. The VP can be issued using ZKPs, “containing derived data instead of directly embedded verifiable credentials” [16].]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that the issuer is the upstream entity as the issuer as disclosed by Belchior perform the same step as upstream entity that generates the verifiable credentials. Additionally, it is also reasonable to infer that verifiable presentation reads on token. Applicant’s specification paragraph 0050 recites, “the content storage entity computing device 8 by providing a verifiable credential and/or a token including an embedded verifiable credential to the content storage entity computing device 8, which verifies the verifiable credential and provides access to the stored information.”; and Belchior discloses verifiable presentation contain metadata and proofs for a subset of claims and VP is used by the verifier to confirm the credentials. One of ordinary skill in the art would use the verifiable presentation (i.e., token) to verify the user. And, therefore one of skill in the art would have understood the reference to teach the limitation.
generate a request transaction including a request to access the information pertaining to the upstream entity and the authorization token; [see at least Figs. 1, 3 (page 1938, lines 19-22) The user (i.e., upstream entity) then requests access to a set of resources (4). The verifier creates a VPR from the access control policy underlying the requested resource. (page 1938, lines 23-31) The verifier assumes that the user owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that the user in this instance is the upstream entity as the user as disclosed by Belchior perform the same step as upstream entity that request to access information. And, therefore one of skill in the art would have understood the reference to teach the limitation.
provide the request transaction to the content storage entity; [see at least Figs. 1 (page 1938, lines 19-20) A user is issued verifiable credentials (steps 1 and 2), which are rooted in a verifiable credential registry (3). The user then requests access to a set of resources (4).]
receive a verification challenge corresponding to the request transaction based on the verifiable credential; [see at least Figs. 1, 3 (page 1938, lines 19-22) The user then requests access to a set of resources (4). The verifier creates a VPR from the access control policy underlying the requested resource. (page 1938, lines 23-31) The verifier assumes that the user owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10)]
transmit a response to the verification challenge; and [see at least Figs. 1, 3 (page 1938, lines 23-31) The verifier assumes that the user owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10)]
receive a reply transaction granting access to the information pertaining to the upstream entity. [see at least Figs. 1, 3 (page 1938, lines 23-31) The verifier assumes that the user (i.e., upstream entity) owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10). The result of the decision may be influenced by extra factors, e.g. the context of the request. If the decision from the access control engine is ALLOW, access to the resource is provided (11, 12)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that the user in this instance is the upstream entity as the user as disclosed by Belchior perform the same step as upstream entity as the user needs to verify its credentials to have access to its information. And, therefore one of skill in the art would have understood the reference to teach the limitation.
Belchior discloses allowing access to data, however, Belchior does not disclose:
a non-transitory memory;
a processor communicatively coupled to the non-transitory memory,
wherein the processor is configured to read a set of instructions to:
receive an authorization notification corresponding to the authorization request;
Li discloses:
a non-transitory memory; [see at least (4/1-7) a system for blockchain- based cross-entity authentication comprises one or more processors and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of the preceding embodiments.]
a processor communicatively coupled to the non-transitory memory, [see at least (4/1-7) a system for blockchain- based cross-entity authentication comprises one or more processors and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of the preceding embodiments.]
wherein the processor is configured to read a set of instructions to: [see at least (4/1-7) a system for blockchain- based cross-entity authentication comprises one or more processors and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of the preceding embodiments.]
receive an authorization notification corresponding to the authorization request; [see at least (13/8-16) The agent 321 may provide one or more application programming interfaces (APis), which may be used by the user-side system 310 to directly submit requests related to DIDs or VCs. The messenger 325 may provide notifications related to DIDs, VCs, or other information or data stored on one or more blockchains for the user-side system 310.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior to include the features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior with notification steps of Li. Belchior discloses steps for authenticating user to allow access to data. Li teaches sending notification related to the decentralized identifiers and verifiable credentials. Because both Belchior as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the notification steps of Li with technique of authenticating user as taught by Belchior to securely authenticate user prior to allowing access to data. Moreover, since the features disclosed by Belchior as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Belchior/Li.
Regarding Claims 2, 12. Belchior, Li discloses the limitations of Claims 1, 11. Belchior further discloses:
wherein the authorization token enables access to the information pertaining to the upstream entity as stored in a database associated with the content storage entity. [see at least (page 1936, lines 18-23 and 37-45) An entity called issuer generates and signs such credentials with its private key: this enables a third-party to verify the issuer of a VC (the DID of the issuer is typically associated with the credential). A verifier can look up the public key of a given DID, associated with a given credential on a verifiable data registry (e.g., a public blockchain) … At verification time, the holder (i.e., upstream entity) of a verifiable credential (often the subject itself) creates a verifiable presentation (VP), which contains metadata and proofs for a subset of the contained claims. The VP creation process might be required by a verifier, through a verifiable presentation request (VPR). The VP is sent to a verifier, that confirms the VC held by the subject satisfies a specific predicate. The VP can be issued using ZKPs, “containing derived data instead of directly embedded verifiable credentials” [16]. (page 1938, lines 23-31) The verifier assumes that the user owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10). The result of the decision may be influenced by extra factors, e.g. the context of the request. If the decision from the access control engine is ALLOW, access to the resource is provided (11, 12)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. The Belchior reference on page 1937, lines 9-10 recites The subject (that we also call user) is the entity that requires access to a resource. One of ordinary skill in the art would conclude the subject is the user, and the user is the upstream entity. Additionally, it is reasonable to infer that verifiable presentation reads on token. Applicant’s specification paragraph 0050 recites, “the content storage entity computing device 8 by providing a verifiable credential and/or a token including an embedded verifiable credential to the content storage entity computing device 8, which verifies the verifiable credential and provides access to the stored information.”; and Belchior discloses verifiable presentation contain metadata and proofs for a subset of claims and VP is used by the verifier to confirm the credentials. One of ordinary skill in the art would use the verifiable presentation (i.e., token) to verify the user. And, therefore one of skill in the art would have understood the reference to teach the limitation.
Regarding Claims 3, 13. Belchior, Li discloses the limitations of Claims 1, 11. Belchior further discloses:
wherein the request corresponds to a confirmation request for an audit of the upstream entity, and the content storage entity is an institution that maintains the information pertaining to the upstream entity.[see at least (page 1939, lines 36-40) issuers are held accountable for the VCs they issue. User (i.e., upstream entity) credentials are auditable, as the blockchain provides the trust anchor for checking its validity. In other words, a verifier can verify that the presented credentials are valid and come from a trusted party, at its description.]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that the user is the upstream entity. Applicant’s specification paragraph 0015 recites, “which an auditor (e.g., downstream entity) requests confirmation from a third party (e.g., content storage entity), such as a bank or financial institution, regarding information of a client, the audited entity (e.g., upstream entity).”; and Belchior discloses the user’s credentials are auditable. One of ordinary skill in the art would conclude that user is the audited entity (i.e., upstream entity). And, therefore one of skill in the art would have understood the reference to teach the limitation.
Regarding Claims 4, 14. Belchior, Li discloses the limitations of Claims 1, 11. Belchior further discloses:
the authorization token. [see at least (page 1936, lines 18-23 and 37-45) An entity called issuer generates and signs such credentials with its private key: this enables a third-party to verify the issuer of a VC (the DID of the issuer is typically associated with the credential). A verifier can look up the public key of a given DID, associated with a given credential on a verifiable data registry (e.g., a public blockchain) … At verification time, the holder of a verifiable credential (often the subject itself) creates a verifiable presentation (VP), which contains metadata and proofs for a subset of the contained claims. The VP creation process might be required by a verifier, through a verifiable presentation request (VPR). The VP is sent to a verifier, that confirms the VC held by the subject satisfies a specific predicate. The VP can be issued using ZKPs, “containing derived data instead of directly embedded verifiable credentials” [16]. (page 1938, lines 23-31) The verifier assumes that the user owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10). The result of the decision may be influenced by extra factors, e.g. the context of the request. If the decision from the access control engine is ALLOW, access to the resource is provided (11, 12)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that verifiable presentation reads on token. Applicant’s specification paragraph 0050 recites, “the content storage entity computing device 8 by providing a verifiable credential and/or a token including an embedded verifiable credential to the content storage entity computing device 8, which verifies the verifiable credential and provides access to the stored information.”; and Belchior discloses verifiable presentation contain metadata and proofs for a subset of claims and VP is used by the verifier to confirm the credentials. One of ordinary skill in the art would use the verifiable presentation (i.e., token) to verify the user. And, therefore one of skill in the art would have understood the reference to teach the limitation.
Li further discloses:
wherein the processor is configured to decrypt the authorization token prior to generating the request transaction. [see at least (43/65-67 and 44/1-2) at step 1631, the DIS 1603b may 65 obtain a public key of the user (e.g., from the blockchain 330) and decrypt the encrypted authorization with the public key of the user to verify that the authorization is endorsed by the user and to obtain the digital signature.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with encryption and decryption as taught by Li. Belchior, Li discloses authenticating user. Li further teaches encrypting and decrypting using cryptographic keys. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the encryption and decryption technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 5, 15. Belchior, Li discloses the limitations of Claims 4, 14. Belchior further discloses:
wherein the authorization token … [see at least (page 1936, lines 18-23 and 37-45) An entity called issuer generates and signs such credentials with its private key: this enables a third-party to verify the issuer of a VC (the DID of the issuer is typically associated with the credential). A verifier can look up the public key of a given DID, associated with a given credential on a verifiable data registry (e.g., a public blockchain) … At verification time, the holder of a verifiable credential (often the subject itself) creates a verifiable presentation (VP), which contains metadata and proofs for a subset of the contained claims. The VP creation process might be required by a verifier, through a verifiable presentation request (VPR). The VP is sent to a verifier, that confirms the VC held by the subject satisfies a specific predicate. The VP can be issued using ZKPs, “containing derived data instead of directly embedded verifiable credentials” [16]. (page 1938, lines 23-31) The verifier assumes that the user owns the necessary attributes on the verifiable credentials to be able to respond to the challenge. After the challenge is sent in the form of a VP (7) and validated (8), the verifier gives as input the result of the validation process to an access control engine (or PDP) (9, 10). The result of the decision may be influenced by extra factors, e.g. the context of the request. If the decision from the access control engine is ALLOW, access to the resource is provided (11, 12)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that verifiable presentation reads on token. Applicant’s specification paragraph 0050 recites, “the content storage entity computing device 8 by providing a verifiable credential and/or a token including an embedded verifiable credential to the content storage entity computing device 8, which verifies the verifiable credential and provides access to the stored information.”; and Belchior discloses verifiable presentation contain metadata and proofs for a subset of claims and VP is used by the verifier to confirm the credentials. One of ordinary skill in the art would use the verifiable presentation (i.e., token) to verify the user. And, therefore one of skill in the art would have understood the reference to teach the limitation.
Li further discloses:
wherein the authorization token is decrypted using a symmetric encryption key. [see at least (43/65-67 and 44/1-2) at step 1631, the DIS 1603b may 65 obtain a public key of the user (e.g., from the blockchain 330) and decrypt the encrypted authorization with the public key of the user to verify that the authorization is endorsed by the user and to obtain the digital signature.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with encryption and decryption as taught by Li. Belchior, Li discloses authenticating user. Li further teaches encrypting and decrypting using cryptographic keys. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the encryption and decryption technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Note: The above combination of Belchior, Li does not expressly disclose authorization token is decrypted using a symmetric encryption key. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
Regarding Claims 6, 16. Belchior, Li discloses the limitations of Claims 1, 11. Li further discloses:
wherein the processor is configured to encrypt the request prior to providing the request transaction. [see at least (3/35-42) before generating the blockchain transaction for obtaining the authentication result of the user by the second entity, the method further comprises: generating a digital signature on the obtained authentication request with a private key of the first entity, and obtaining an authorization encrypted with a private key of the user for permitting the first entity to access the authentication information of the user endorsed by the second entity.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with encryption and decryption as taught by Li. Belchior, Li discloses authenticating user. Li further teaches encrypting and decrypting using cryptographic keys. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the encryption and decryption technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 7, 17. Belchior, Li discloses the limitations of Claims 6, 16. Li further discloses:
wherein encrypting the request includes using a symmetric encryption key. [see at least (3/35-42) before generating the blockchain transaction for obtaining the authentication result of the user by the second entity, the method further comprises: generating a digital signature on the obtained authentication request with a private key of the first entity, and obtaining an authorization encrypted with a private key of the user for permitting the first entity to access the authentication information of the user endorsed by the second entity.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with encryption and decryption as taught by Li. Belchior, Li discloses authenticating user. Li further teaches encrypting and decrypting using cryptographic keys. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the encryption and decryption technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Note: The above combination of Belchior, Li does not expressly disclose encrypting the request includes using a symmetric encryption key. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
Regarding Claims 8, 18. Belchior, Li discloses the limitations of Claims 7, 17. Li further discloses:
wherein generating the request transaction includes: encrypting the symmetric encryption key using a public key associated with the content storage entity; and [see at least (30/63-67 and 31/1) The KMS 323 may create a digital signature for the transaction. In some embodiments, the digital signature may be generated in a TEE associated with the KMS 323. The KMS 323 may identify an encrypted private key associated with the public key and feed the encrypted private key to the TEE.]
including the encrypted symmetric encryption key in the request transaction. [see at least (31/1-6) The encrypted private key may be decrypted within the TEE and used to generate the digital signature for the transaction. The digital signature may then be fed back to the KMS 323. At step 1132, the user agent 411 may receive from the KMS a signed version of the blockchain transaction.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with encryption and decryption as taught by Li. Belchior, Li discloses authenticating user. Li further teaches encrypting and decrypting using cryptographic keys. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the encryption and decryption technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Note: The above combination of Belchior, Li does not expressly disclose symmetric encryption key. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
Regarding Claims 9, 19. Belchior, Li discloses the limitations of Claims 7, 17. Li further discloses:
wherein generating the request transaction includes generating the request transaction including an address, on a blockchain, of the upstream entity. [see at least (11/29-34) The server end 118 may sign the blockchain transaction on behalf of a user (i.e., upstream entity) associated with the client-side computing device 111. For example, the blockchain transaction A may comprise information such as nonce (e.g., transaction serial number), from (e.g., a blockchain address of the user)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that the user is the upstream entity. As the user’s blockchain address is included in the request. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with encryption and decryption as taught by Li. Belchior, Li discloses authenticating user. Li further teaches encrypting and decrypting using cryptographic keys. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the encryption and decryption technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 10. Belchior, Li discloses the limitations of Claim 1. Li further discloses:
wherein the processor is configured to: obtain a first hash value of the authorization token from the authorization notification; [see at least (39/20-22) At step 1510a, the resolver 322 may obtain a status of the VC as well as a hash value associated with the VC from the blockchain 330.]
calculate a second hash value the authorization token; and [see at least (39/24-26) The verifier agent 413 may calculate a hash value by applying a hash function on the VC that was provided by the holder.]
compare the first hash value to the second hash value to verify the authorization token. [see at least (39/26-29) The verifier agent 413 may authenticate the received status of the VC by comparing the hash value received from the blockchain 330 with the calculated hash value.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Belchior, Li to include the additional features of Li. A person a having the ordinary skill in the art would have been motivated to perform user authentication using the authentication steps of Belchior, Li with the hash value of Li. Belchior, Li discloses authenticating user. Li further teaches calculating and comparing the hash value. Because both Belchior, Li as well as Li are implemented through field of authenticating user in a blockchain environment and both references addresses using the hashing technique as taught by Li with technique of authenticating user as taught by Belchior, Li to securely authenticate user prior to allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20200201679 A1 Wentz; Christian T. SYSTEMS, DEVICES, AND METHODS FOR SELECTING A DISTRIBUTED FRAMEWORK - A method of selecting a distributed framework includes identifying, by a selection device coupled to a memory, at least a first remote device of a plurality of remote devices, wherein identifying the at least a first remote device further comprises and evaluating a secure proof generated by the at least a first remote device, and identifying the at least a first remote device as a function of the secure proof, assigning, by the selection device, a confidence level of the at least a first remote device, and selecting, by a selection device, a distributed framework from the plurality of remote devices as a function of the confidence level, and assigning a task to the distributed framework.
US 20220261925 A1 KURCZODYNA; Joe SYSTEM AND METHOD FOR PREPARING FOR A SEC FINANCIAL STATEMENT AUDIT BY RECORDING CORPORATE GOVERNANCE INFORMATION ON AN IMMUTABLE BLOCKCHAIN - The present disclosure describes systems and methods for storing pertinent company information on an immutable blockchain. Preferred embodiments disclose systems and methods of preparing for, and complying with, a SEC financial statement audit by recording corporate governance information on an immutable blockchain. The recorded information, which cannot be subsequently backdated or manipulated, provides SEC auditors compliant and accurate information, which streamlines the audit and reduces costs.
US 20250175459 A1 Guck; Andrew et al. SECURE TRANSFER OF ACCESS CREDENTIALS - In some implementations, a system is provided for securely transferring access credentials from a mobile device that is exclusively operated by a single user, to a terminal device that is shared among multiple different users, via a session server. A session is established between the session server and the terminal device over a secure communication channel. The terminal device generates a key pair, transmits the public key to the session server, and stores the private key. The terminal device outputs a detectable code corresponding to the session. In response to detecting the detectable code, the mobile device transmits an access token payload to the session server. The session server transmits, to the terminal device, an encrypted access token that has been encrypted using the public key. The terminal device decrypts the encrypted access token using the stored private key, and provides operator access to the terminal device.
US 20210089676 A1 FORD; Bryan et al. METHODS AND SYSTEMS FOR SECURE DATA EXCHANGE - The present invention concerns a computer-implemented method for secure data exchange between a sender (A) and a recipient (B), wherein the method is performed by the sender (A) and comprises encrypting data using a symmetric key k, creating a write transaction T.sub.W, wherein the write transaction T.sub.W comprises information usable to derive the symmetric key k and an access policy identifying the recipient (B) as being allowed to decrypt the encrypted data, providing the recipient (B) access to the encrypted data, and sending the write transaction T.sub.W to a first group of servers (AC) for being stored in a blockchain data structure maintained by the first group of servers (AC).
US 11288740 B2 Nolan; Michael et al. Securing distributed electronic wallet shares - Methods and systems are provided for securing distributed shares of an electronic wallet. An example method includes provisioning a plurality of devices each hosting an e-wallet share with enhanced privacy identification (EPID) private keys for the e-wallet share. A signature is posted for the e-wallet share to a blockchain. A determination is made as to whether the e-wallet share is compromised, and, if so, posting a revocation list comprising the signature for the e-wallet share to a blockchain.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698