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 .
DETAILED ACTION
This Office Action is in response to the application 18/868,351 filed on 11/22/2024.
Claims 1-8 and 17-28 have been examined and are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 10/31/2025, 07/24/2025, and 11/22/2024, are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-8 and 17-28 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claims 1, 17 and 25, claims 1, 17 and 25 recite “receiving an identity key allocation request and an identity key sharing request of a user.” According to the Specification par. [0008 and 0042] and fig. 2, an identity key is bound to a user identifier and a device identifier of the user and a user identifier and a device identifier of the sharer, to form a contract. Further, Allocate a unique key secretKey to an identity key in response to that the user requests to register the identity key; Form the identity key and a binding relationship into a contract. It is not clear how “an identity key” is formed, generated or created for a user.
Regarding claims 1-8 and 17-28; claims 1-8 and 17-28 are dependent on claims 1, 17 and 25 and are analyzed and rejected accordingly.
Regarding claim 17, claim 17 recites “A non-transitory computer-readable storage medium storing instructions, wherein the non-transitory computer-readable storage medium stores a computer program, which when executed by a processor causes the processor to:” it is unclear whether “which (executed by a processor) is refer to the “stored instructions or stored computer program.” Further “A processor” is coupled with memory or not).
Regarding claims 18-24; claims 18-24 are dependent on claim 17, and are analyzed and rejected accordingly.
Regarding claim 25; claim 25 recites the limitation “A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the computing device is caused to:” There is no present tense to positively recite that the stored executable code are execute by a processor. Thus, the processor is not actually executing the stored code to receive, allocate, send receive, verify and return etc. (See Ex parte Prouse - Appeal No. 2008-2417 for detail).
Regarding claims 26-28; claims 26-28 are dependent on claim 25, and are analyzed and rejected accordingly.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-8 and 17-28 are rejected under 35 U.S.C. 103 as being unpatentable over Hamel (US 2019/0305952) and in view of Ferenczi (US 2021/0067340).
Regarding claim 1, Hamel discloses a multi-device assistive identity verification method (Hamel par. 0104; A system for creating an identity mapping on a distributed ledger comprises an interface configured to receive a request to create an identity mapping on a distributed ledger, and a processor configured to generate an identity key pair), wherein the method comprises:
receiving an identity key allocation request and an identity key sharing request of a user (Hamel par. 0104, 0113 and Fig. 1D; A system for creating an identity mapping on a distributed ledger comprises an interface configured to receive a request to create an identity mapping on a distributed ledger, and a processor configured to generate an identity key pair. a request is received to create an identity mapping on a distributed ledger. In 1D02, an identity key pair is generated);
allocating an identity key (Hamel par. 0105; A system for creating an identity mapping on a distributed ledger comprises an authentication device in communication with a distributed ledger (e.g., a permissioned ledger, a public ledger, a decentralized ledger, a blockchain, etc.). The identity mapping enables being able to securely and verifiably provide credentials from a user's authentication device to a requestor (e.g., a requesting application). The authentication device comprises a computing device (e.g., a computer, a smartphone, a tablet, etc.). For example, the authentication device comprises a mobile computing device. An identity mapping comprises a mapping from a user identifier to an authentication device public key), and
storing the identity key in a server (Hamel par. 0113 and Fig. 1D; In 1D08, the encrypted private key is stored);
receiving a transaction request of the user, and inviting, based on the transaction request, the user and the sharer to send confirmation (Hamel par. 0114 and Fig. 1E ; A proof request challenge is received, wherein the proof request challenge comprises a request for one or more digital credentials, wherein the one or more digital credentials are determined using rules. In 1E02, a set of stored digital credentials is determined. In 1E04, a subset comprising the credentials of the set of stored digital credentials that satisfy the proof request challenge is determined. In 1E06, a user interface is provided for allowing a user to select a digital credential of the subset that satisfies the proof request challenge);
verifying an identity key of the user and an identity key of the sharer in response to the confirmation of the user and the sharer (Hamel par. 0099, 0114 and Fig. 1E; The system for digital credentialing is designed to empower individual users to own their verifiable professional identity and to be able to enable this identity to be useable in scenarios where a verified identity allows access by providing proof of identity. An application might use the system to prove the identity or verify a user's access ability to something. The application queries the system regarding a proof of identity and the user provides the proof using a credential to the system that is ultimately passed to the application to prove identity of the user. See also par. 0120); and
returning an identity verification result based on verification of the identity key of the user and the identity key of the sharer (Hamel par. 0114, 0163 and Fig. 1E ; A proof response is provided comprising the selected digital credential. The authentication device returns the session key decrypted to the user device and the authentication response (e.g., signed with a private key component of the session keypair) is generated using the decrypted private key component of the session key and is passed back to the DCIAMS as the authentication response).
Hamel teaches authentication device public key comprises a public key of an identity key pair (IKP) of the authentication device. The IKP comprises a public key and a private key (e.g., a public identity key and a private identity key). The public key is public (e.g., publicly known and shared widely) and the private key is private (e.g., known only to the authentication device as a carefully guarded secret) (Hamel par. 0105). However, Hamel does not explicitly teach sending the identity key to the user and a sharer.
However, in an analogous field, Ferenczi teaches sending the identity key to the user and a sharer (Ferenczi par. 0040, 0057and 0091; The security service 121 retrieves the identity document 136 associated with the identity key 131 that identifies the hosted application 119 in response to receiving the verification request. For example, the security service 121 can use the identity key 131 to search for the respective identity document 136 stored in the distributed ledger and retrieve it. In instances where multiple distributed ledgers 113 are used, the security service 121 can send the identity key 131 to a relay or resolver service, such as a DID resolver, to determine which distributed ledger 113 contains the identity document).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method of sending the identity key to the user and a sharer of Hamel using sending the identity key to the user and a sharer taught in Ferenczi in order to decentralizing the authentication or verification of data (Ferenczi Abstract).7
Regarding claim 2, Hamel and Ferenczi disclose the method according to claim 1,
Hamal further discloses wherein the allocated identity key is stored on a blockchain in an encrypted manner (Hamel par. 0113; For example, the DCIAMS determines whether the signed mapping document was valid when received at the distributed ledger by receiving an indication that the signed mapping document passed a validation check performed by the distributed ledger prior to being stored in the ledger (e.g., was validated by checking the signature of the mapping document). In some embodiments, a further indication is received from the distributed ledger indicating that the signed mapping document was successfully accepted to be stored and confirmed to be stored in the distributed ledger)7.
Regarding claim 3, Hamel and Ferenczi disclose the method according to claim 1,
Hamel further discloses wherein the allocated identity key is bound to a user identifier and a device identifier of the user and a user identifier and a device identifier of the sharer, to form a contract (Hamel par. 0104; A system for creating an identity mapping on a distributed ledger comprises an interface configured to receive a request to create an identity mapping on a distributed ledger, and a processor configured to generate an identity key pair, generate a mobile encryption key, encrypt a private identity key of the identity key pair using the mobile encryption key to create an encrypted private key, store the encrypted private key, create a mapping document, sign the mapping document with the private identity key of the identity key pair, and provide the signed mapping document to be stored in a distributed ledger).
Regarding claim 4, Hamel and Ferenczi disclose the method according to claim 2,
Hamel further discloses wherein inviting, based on the transaction request, the user and the sharer to send confirmation further comprises: obtaining a corresponding identity key from the blockchain based on the transaction request and the user identifier and the device identifier of the user; and inviting the user and the sharer bound to the obtained identity key to send the confirmation (Hamel par. 0099, 0114 and Fig. 1E; The system for digital credentialing is designed to empower individual users to own their verifiable professional identity and to be able to enable this identity to be useable in scenarios where a verified identity allows access by providing proof of identity. An application might use the system to prove the identity or verify a user's access ability to something. The application queries the system regarding a proof of identity and the user provides the proof using a credential to the system that is ultimately passed to the application to prove identity of the user. See also par. 0120).
Regarding claim 5, Hamel and Ferenczi disclose the method according to claim 1,
Hamel further discloses wherein verifying the identity key of the user and the identity key of the sharer further comprises: separately calculating a token of the user and a token of the sharer, and comparing the token of the user and the token of the sharer; obtaining, based on a comparison result are the same, a token calculated in the server; and further comparing the token of the user and the token obtained from the server (Hamel par. 0111; Login application 1C10 comprises an application for receiving login information (e.g., username and password, a credential, a QR code challenge, etc.) and providing login credentials (e.g., a login token). Login application 310 delegates to token generation application 316 to generate a token based on a successful login interaction. Ledger interface application 1C12 comprises an application for interacting with a distributed ledger (e.g., distributed ledger 104 of FIG. 1). For example, ledger interface application 1C12 comprises an application for verifying a signature in a ledger or checking a credential identifier for revocation in a ledger. Proof request application 1C14 comprises an application for creating a proof request, sending a proof request, evaluating a proof request response (e.g., a proof response), etc. Token generation application 1C16 comprises an application for generating a login token (e.g., in response to a successful login). Credential issuing application 1C18 comprises an application for issuing a digital credential for proving a qualification (e.g., a user qualification) in response to a request from a credential issuing authority to issue the credential. Applications 1C06 additionally comprises any other appropriate applications).
Regarding claim 6, Hamel and Ferenczi disclose the method according to claim 5,
Hamel further discloses wherein the token calculated in the server is calculated in the server based on an identity key obtained from a blockchain (Hamel par. 0111; Login application 1C10 comprises an application for receiving login information (e.g., username and password, a credential, a QR code challenge, etc.) and providing login credentials (e.g., a login token). Login application 310 delegates to token generation application 316 to generate a token based on a successful login interaction).
Regarding claim 7, Hamel and Ferenczi disclose the method according to claim 5,
Hamel further discloses wherein the token is calculated based on a time-based one-time password (TOTP) algorithm and based on the identity key and a current timestamp (Hamel par. 0114; In 1E08, a proof response is provided comprising the selected digital credential. For example, the one or more selected digital credentials are provided in response to the request, where the proof response is signed using the IKP private key to prove that is was generated by the holder of the credential and also includes timestamp to show liveness (e.g., that the proof response has not expired or is stale)).
Regarding claim 8, Hamel and Ferenczi disclose the method according to claim 1,
Hamel further discloses further comprising: in response to that the transaction request of the user is received, performing password verification, SMS message verification, or biometric verification before inviting the user and the sharer to send confirmation (Hamel par. 0110; For example, secure enclave 1B10 is configured to only provide transformed input data and not to provide mobile encryption key 1B12. In some embodiments, functionality of secure enclave 1B10 is access limited using a biometric (e.g., a fingerprint, a retina scan, a DNA scan, etc.) or a personal identification number (PIN) to protect enclave access and Authentication device).
Regarding claims 17-24; claims 17-24 are directed to non-transitory computer readable storage medium associated with the method claimed in claims 1-8 respectively. Claims 17-24 are similar in scope to claims 1-8 respectively, and are therefore rejected under similar rationale respectively.
Regarding claims 25-28; claims 25-28 are directed to device associated with the method claimed in claims 1-4 respectively. Claims 25-28 are similar in scope to claims 1-4 respectively, and are therefore rejected under similar rationale respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 PM.
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, FARID HOMAYOUNMEHR can be reached at 571-272-3739. 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.
/SANCHIT K SARKER/Primary Examiner, Art Unit 2495