DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . 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.
This Office Action is in response Applicant communication filed on 4/27/2026.
Claims
Claims 1, 8, and 15 have been amended.
Claims 1-20 are currently pending in the application.
Response to Arguments
103
In Applicant’s arguments with respect to claims 1, 8, and 15 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all
obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20250272688 A1 (“Galiamov”) and US 20240406010 A1 (“Chotrani”) and US 20070094716 A1 (“Farino”).
Per claims 1, 8, and 15, Galiamov discloses:
a memory configured to store: a reference repository comprising a plurality of reference bitstrings (e.g. The IDX computing system 200 then verifies the selfie sent by the digital wallet 220 with previously verified and stored biometric information stored by the IDX computing system 200 (operation 30)) (Section [0027], [0031], and [0082]);
a processor communicatively coupled to the memory (e.g. Processor set 110 includes one, or more, computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed over multiple packages, for example, multiple, coordinated integrated circuit chips) (Section [0057]-[0059]);
receive a request to generate a digital credential for a candidate profile, the candidate profile comprising candidate information and a plurality of entitlements (e.g. As shown in FIG. 4, the operation starts with a user of a user computing device requesting access to protected data, resources, or services of a relying party, also referred to herein as a verifier as they are the ones attempting to verify the identity of the user (step 410). The relying party requests an identity verification of the user from the user's digital wallet (step 420). This may include, for example, sending a QR code or other digital request which may be processed and used by the user's digital wallet 220 to collect biometric data and send it for verification (step 430)) (Section [0111]);
generate a request bitstring representative of the candidate information (e.g. The biometric data sent to the IDX computing system is then used to perform a biometric liveness check (step 440). This may involve the IDX computing system interacting with the identity or attribute provider computing systems 240, 250 to utilize their BVS to perform a facial image comparison and verify that the currently provided facial image matches substantially the stored facial image data. In some cases the IDX computing system 200 itself may have a BVS for this purpose and may store facial image data locally for use in perform BVS based verification) (Section [0111] and [0112]);
determine whether the request bitstring matches a reference bitstring from the plurality of reference bitstrings in the reference repository (e.g. If the biometric liveness check results in the biometric data matching, then a verification transaction ID (VTID) is generated for this transaction and provided to the digital wallet along with a verifiable credential indicating that the user has been verified (step 460). The VTID is also stored locally at the IDX computing system (step 470). The digital wallet may then send the verifiable credential and VTID to the relying party computing system for verifying the user (step 480)) (Section [0112] and [0113]);
in response to determining that the request bitstring matches the reference bitstring from the plurality of reference bitstrings in the reference repository, determine that the candidate information is verified (e.g. If the biometric liveness check results in the biometric data matching, then a verification transaction ID (VTID) is generated for this transaction and provided to the digital wallet along with a verifiable credential indicating that the user has been verified (step 460). The VTID is also stored locally at the IDX computing system (step 470). The digital wallet may then send the verifiable credential and VTID to the relying party computing system for verifying the user (step 480)) (Section [0113]).
Although Galiamov discloses receiving a request to generate a digital credential and generating data representative of the candidate information to compare with stored information to verify the requestor, Galiamov does not specifically disclose:
in response to determining that the candidate information is verified, determine a plurality of claims based on the plurality of entitlements, the plurality of claims being representative of one or more portions of the candidate information;
store the plurality of claims in a secured storage;
generate the digital credential for the candidate profile representative of the candidate information and the plurality of claims;
generate a private key configured to create a signature for the digital credential;
sign the digital credential using the private key;
issue a signed version of the digital credential to a digital wallet associated with the candidate profile;
configure the signed version of the digital credential for access to a specific physical location associated with an organization and network resources associated with the organization from the specific physical location by associating the signed version of the digital credential with the specific physical location.
However Chotrani, in analogous art of generating digital credentials, discloses:
in response to determining that the candidate information is verified, determine a plurality of claims based on the plurality of entitlements, the plurality of claims being representative of one or more portions of the candidate information (e.g. The issuer backend 408 can generate a 1:1 ratio of instances of a digital credential to the number of transaction keys in the validated provisioning request. For example, if the validated provisioning request includes five transaction keys, the issuer backend 408 can generate five instances of a digital credential. As described herein, the digital credential includes data elements (for example, data elements 108 of FIG. 1) and an MSO (for example, MSO 110 of FIG. 1). The instances of a digital credential can have the same data elements but have different MSOs. For example, an issuer backend 408 can generate five instances of an mDL. The five instances can all have the same data elements such as name, age, address, and the like. However, the five instances can have different MSOs, for example, having different hashes (for example, hash 312 of FIG. 3), different transaction keys (for example, transaction key 314 of FIG. 3), and different issuer signatures (for example, issuer signature 316 of FIG. 3)) (Section [0012], [0022], [0045], and [0046]);
store the plurality of claims in a secured storage (e.g. The computing device can store the digital credential which includes a set of data elements and a security object. The data elements can be associated with a user, wherein the data elements can include one or more of: a name, an age, a birthday, a residential address, a picture of the user, a gender, a hair color, an eye color, a height, and a weight) (Section [0050] and [0051]);
generate the digital credential for the candidate profile representative of the candidate information and the plurality of claims (e.g. The issuer backend 408 can generate a 1:1 ratio of instances of a digital credential to the number of transaction keys in the validated provisioning request. For example, if the validated provisioning request includes five transaction keys, the issuer backend 408 can generate five instances of a digital credential. As described herein, the digital credential includes data elements (for example, data elements 108 of FIG. 1) and an MSO (for example, MSO 110 of FIG. 1). The instances of a digital credential can have the same data elements but have different MSOs. For example, an issuer backend 408 can generate five instances of an mDL. The five instances can all have the same data elements such as name, age, address, and the like. However, the five instances can have different MSOs, for example, having different hashes (for example, hash 312 of FIG. 3), different transaction keys (for example, transaction key 314 of FIG. 3), and different issuer signatures (for example, issuer signature 316 of FIG. 3)) (Section [0045] and [0046]);
generate a private key configured to create a signature for the digital credential (e.g. However, the five instances can have different MSOs, for example, having different hashes (for example, hash 312 of FIG. 3), different transaction keys (for example, transaction key 314 of FIG. 3), and different issuer signatures (for example, issuer signature 316 of FIG. 3)) (Section [0023], [0024], and [0045]);
sign the digital credential using the private key (e.g. However, the five instances can have different MSOs, for example, having different hashes (for example, hash 312 of FIG. 3), different transaction keys (for example, transaction key 314 of FIG. 3), and different issuer signatures (for example, issuer signature 316 of FIG. 3)) (Section [0023, [0024], and [0045]);
issue a signed version of the digital credential to a digital wallet associated with the candidate profile (e.g. At block 432, the credential backend 406 sends the set of instances of the digital credential to the application system 402 of the user device 401. Once the user device 401 receives the instances of the digital credential, the user device can decrypt the instances of the digital credential using the private device encryption key. The user device 401 can store the set of instances of the digital credential or parts of the set of instances of the digital credential in the application system 402 and/or the secure element 404 as described herein) (Section [0048] and [0068]).
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 digital credential generation of Galiamov to include generating the digital credential based on a plurality of claims and signing the digital credential before issuing it to the requestor’s digital wallet, as taught by Chotrani, in order to achieve the predictable result of increasing the security of the digital credential creation by ensuring that a certified/authorized issuer backend actually generated the set of instances of the digital credential and not a bad actor (See Chotrani [0048]).
Although Galiamov/Chotrani discloses storing a signed version of the digital credential in a digital wallet for authorizing the user, Galiamov/Chotrani does not specifically disclose:
configure the signed version of the digital credential for access to a specific physical location associated with an organization and network resources associated with the organization from the specific physical location by associating the signed version of the digital credential with the specific physical location.
However Farino, in analogous art of using digital credentials for access control, discloses:
configure the signed version of the digital credential for access to a specific physical location associated with an organization and network resources associated with the organization from the specific physical location by associating the signed version of the digital credential with the specific physical location (e.g. The unified access control server 200 determines the access policy for the particular combination of the credential and physical location as indicated at step 383, and identified by the recorded ACD network address in step 382. The resulting grant or deny response is then transmitted to the networked access control device; assuming the credentials are valid and that a policy approves access via the corresponding resource ACD device, the user may enter or access the facility) and (e.g. The user then arrives at computer 151 or other network-attached communications or computing device. For this example, the PC is in relative close proximity or under the physical access control of the ACDs used in steps 381 through 383. The user then wishes to log-on to the network. This log-on request is received by the network infrastructure device 155 and unified access control server 200 (step 384)) and (e.g. Server 200 executes the associated access control policy for the computer based on verification of the credentials. More specifically, server 200 verifies that the user is authorized to access the network from the present location. If the user is not authorized to be in a facility or is not authorized to access certain computer resources at a specific facility, access may be denied and an alarm or alert may be issued to security personnel. If the policy is to allow access, the user is granted access to the networked computer resources) (Sections [0085], [0086] and [0090]-[0092]);
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 digital credential configuration of Galiamov/Chotrani to authorize a user to access both a physical location and network resources associated with that physical location, as taught by Farino, in order to achieve the predictable result of lowering costs of installing and maintaining physical and network access control systems separately (See Farino [0071]).
Per claims 2, 9, and 16, Galiamov/Chotrani/Farino discloses all the limitations of claims 1, 8, and 15 above. Galiamov further discloses:
receive an additional request to generate an additional digital credential for an additional candidate profile, the additional candidate profile comprising additional candidate information and an additional plurality of entitlements (e.g. the operation starts with a user of a user computing device requesting access to protected data, resources, or services of a relying party, also referred to herein as a verifier as they are the ones attempting to verify the identity of the user (step 410). The relying party requests an identity verification of the user from the user's digital wallet (step 420). This may include, for example, sending a QR code or other digital request which may be processed and used by the user's digital wallet 220 to collect biometric data and send it for verification (step 430)) (Section [0111]);
generate an additional request bitstring representative of the additional candidate information (e.g. The biometric data sent to the IDX computing system is then used to perform a biometric liveness check (step 440). This may involve the IDX computing system interacting with the identity or attribute provider computing systems 240, 250 to utilize their BVS to perform a facial image comparison and verify that the currently provided facial image matches substantially the stored facial image data. In some cases the IDX computing system 200 itself may have a BVS for this purpose and may store facial image data locally for use in perform BVS based verification) (Section [0111] and [0112]);
determine whether the additional request bitstring matches an additional reference bitstring of the plurality of reference bitstrings in the reference repository (e.g. If the biometric liveness check results in the biometric data not matching (step 445), then an identity verification failure response may be sent back to the digital wallet 220 (step 450)) (Section [0112] and [0113]);
in response to determining that the additional request bitstring does not match the additional reference bitstring of the plurality of reference bitstrings in the reference repository, determine that the additional candidate information is not verified (e.g. If the biometric liveness check results in the biometric data not matching (step 445), then an identity verification failure response may be sent back to the digital wallet 220 (step 450)) (Section [0113]);
in response to determining that the candidate information is not verified, deny the additional request to generate the additional digital credential for the additional candidate profile (e.g. If the biometric liveness check results in the biometric data not matching (step 445), then an identity verification failure response may be sent back to the digital wallet 220 (step 450)) (Section [0113]).
Per claims 3, 10, and 17, Galiamov/Chotrani/Farino discloses all the limitations of claims 1, 8, and 15 above. Galiamov further discloses:
wherein: the candidate information is representative of image data captured by a sensor (e.g. The biometric data sent to the IDX computing system is then used to perform a biometric liveness check (step 440). This may involve the IDX computing system interacting with the identity or attribute provider computing systems 240, 250 to utilize their BVS to perform a facial image comparison and verify that the currently provided facial image matches substantially the stored facial image data) (Section [0045], [0092], and [0112]).
Per claims 4, 11, and 18, Galiamov/Chotrani/Farino discloses all the limitations of claims 1, 8, and 15 above. Galiamov further discloses:
wherein: the candidate information is representative of a unique digital biometric associated with a user (e.g. The biometric data sent to the IDX computing system is then used to perform a biometric liveness check (step 440). This may involve the IDX computing system interacting with the identity or attribute provider computing systems 240, 250 to utilize their BVS to perform a facial image comparison and verify that the currently provided facial image matches substantially the stored facial image data) (Section [0045], [0092], and [0112]).
Per claims 5, 12, and 19, Galiamov/Chotrani/Farino discloses all the limitations of claims 1, 8, and 15 above. Chotrani further discloses:
wherein: the secured storage comprises a centralized database where additional claims associated with additional candidate profiles are stored (e.g. The environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of examples, the information may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers, or other network devices may be stored locally and/or remotely, as appropriate) (Section [0021], [0022], [0076], and [0077]).
The motivation to combine Chotrani with Galiamov/Farino is disclosed above with reference to claims 1, 8, and 15.
Per claims 6, 13, and 20, Galiamov/Chotrani/Farino discloses all the limitations of claims 1, 8, and 15 above. Galiamov further discloses:
wherein: the secured storage comprises one or more decentralized databases that together store additional claims associated with additional candidate profiles (e.g. The user of the user device 225 is attempting to access an account of that bank. References to “IDX” in the figure are referring to the IDX computing system and stands for “identity exchange”. References to “Did” or “DID” are referring to a decentralized identifier (Did), which is a unique identifier, which in the case of verifiable credential issues may be operating on a decentralized database, and which for holders of the verifiable credentials (VCs), are stored “off database”, e.g., the holder's digital wallet 220 generates a self-describing DID (did: key) that includes a wallet generated public key) (Section [0077], [0078], and [0099]).
Per claims 7 and 14, Galiamov/Chotrani/Farino discloses all the limitations of claims 1, 8, and 15 above. Galiamov further discloses:
wherein: the signed version of the digital credential is issued to the digital wallet associated with the candidate profile for a predefined time duration (e.g. The IDX computing system 200 returns the signed short lived verifiable credential 270 to the digital wallet 220. The end-user consents to share the biometric liveness check credential, selected identity attributes, e.g., driver's license information, or the like, and the VTID of the credentials with the bank 232. The bank 232 stores the VTID issued by the IDX computing system 200 for the verifiable credential 270 and biometric check) (Section [0083], [0094], and [0095]).
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights