DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the claims
2. Applicant filed the Amendment on 03/13/2026. Claims 1-10 are pending. Claims 1-2, 5, and 8-10 are amended. Claims 1-10 are rejected.
Claim Rejections - 35 USC § 103
3. 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.
4. 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.
5. 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 nonobviousness.
6. Claims 1 and 3-9 are rejected under 35 U.S.C. 103 as being unpatentable over US11201746B2 to Ranganathan in view of US9722790B2 to Ebrahimi.
7. As per claim 1:
Ranganathan discloses the following limitations:
A computing system for performing access control of a secure resource through a chain of immutable records, wherein the computing system comprises: one or more processors (Fig.5, item 816); and a non-transitory computer readable storage medium (Fig.5, item 820) having instructions encoded thereon that, when executed by the one or more processors, cause a gate server and a gate client to perform steps comprising (Col.1, lines 47-54; col.13, lines 32-35 discloses a computing system with an access agent and access control operating together on a participant node)
receiving, by the gate client, a request for accessing the secure resource, the request transmitted from a client device of a user (Col.7, lines 34-36; col.4, lines 17-21; discloses receiving an access request (credential token and access command) and transmitting a request and identifiers the blockchain location)
transmitting, by the gate client, a request for a blockchain address to the client device (Col.8, lines 51-54, 55-57, 59-60; col.7, lines 46-48; discloses that access agent obtains a blockchain/datablock address by extracting it (e.g., transmitting) from the access command it receives), wherein the blockchain address is associated with the user (Col.8, lines 51-52, 60; discloses obtaining blockchain address associated with the resource)
Examiner notes: Microsoft Computer Dictionary (ISBN 978-0-735-61495-6) defines “transmit” to be:
transmit vb.
To send information over a communications line or a circuit. Computer transmissions can take place in the following ways: asynchronous (variable timing) or synchronous (exact timing); serial (essentially, bit by bit) or parallel (byte by byte; a group of bits at once); duplex or full-duplex (simultaneous two-way communication), half-duplex (two-way communication in one direction at a time), or simplex (one-way communication only); and burst (intermittent transmission of blocks of information). Compare transfer2.
(emphasis added by examiner)
performing access control verification to access the secure resource by the client device, wherein performing the access control verification comprises (Col.4, lines 39-41, 42-44; col.8, lines 1-2; discloses the participant node (client device) performing multistep access control verification)
receiving, from an immutable database recorded on a blockchain, a stack of identifier (ID) tokens, one or more verification tokens, and one or more veto tokens based on the blockchain address, wherein the stack of ID tokens comprises a particular ID token including a first set of identity data, wherein the stack of ID tokens links multi-modalities of previous authentication requests to the stack as the chain of immutable records (Col.2, lines 56-58; col.3, lines 31-35; col.6, lines 58-63; discloses a chain of immutable records, datablocks cryptographically linked via hashes of previous blocks and a historical log of prior accesses kept as a traceable record), wherein the particular ID token corresponds to an authentication mode of the multi-modalities (Col.4, lines 58-61, 65-67; col.5, lines 24-26; col.3, lines 32-34; discloses multiple token types retrieved from the blockchain and tokens representing both permissions (authorization tokens) and lack of permissions that analogous to verification tokens and veto tokens, and the access agent authenticates verification and veto tokens)
verifying a linkage between the stack of ID tokens, wherein the linkage corresponds to authentication of the particular ID token according to the authentication mode and the previous authentication requests of the stack of ID tokens (Col.8, lines 30-31; col.8, lines 62-63; col.9, lines 22-24; col.3, lines 32-34; discloses chain-based authorization where datablocks are cryptographically linked and the access agent verifies that the authorization token present in the datablock header matches the token identified in the RBAC model.)
decrypting, by the gate server, the first set of identity data, wherein the first set of identity data is decrypted using a decryption key (Col.10, lines 23-28, 33-35; discloses server-side decryption of encrypted data using a key, triggered after authorization is confirmed)
determining, by the gate server, a number of the one or more verification tokens and a number of the one or more veto tokens (Col.4, lines 58-61; col.5, lines 24-26; discloses tokens representing both permissions (authorization tokens) and lack of permissions that analogous to verification tokens and veto tokens)
determining, by the gate server, whether to grant user permission to access the secure resource based on (i) whether comparison indicates a match, (ii) the number of the one or more verification tokens and (iii) the number of the one or more veto tokens (Col.9, lines 39-41, 45-49; discloses a multi-factor access grant decision: an authorization token mapping, chain-based confirmation, and valid digital signature)
responsive to determining that the user is to be granted permission to access the secure resource; granting the user permission to access the secure resource, and causing the immutable database to generate a verification token and store the verification token in the immutable database (Col.10; lines 60-62; col.11, lines 4-7; discloses that upon granting access, a log entry is generated and stored in the datablock header, which is then committed to the immutable blockchain)
Ranganathan does not explicitly disclose, however, Ebrahimi, as shown, teaches the following limitations:
wherein the first set of identity data is encrypted by an encryption protocol (Col.3, lines 47-48, 62-64; col.7, lines 59-60; discloses the identity/personal (input) data is encrypted with a public key under an encryption protocol)
responsive to verifying the linkage, obtaining a second set of identity data from information associated with the stack of ID tokens (Col.9, lines 28-36; discloses that after decrypting the transmitted data, the certifier independently generates a hash of the received identity data)
comparing, by the gate server, the first set of identity data and the second set of identity data to determine whether there is a match (Col.9, lines 36-43; discloses comparing two hash values of identity data to determine whether they match, the verification logic returns “true” for a match and “false” for no match)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method, wherein logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device of Ebrahimi (‘790, col.1, lines 41-43) with teaching of Ranganathan for integrated role-based access control of blockchains, wherein receiving a credential token and an access command that modify a datablock of a blockchain (‘746, col.1, lines 45-50) for encrypting input data by the encryption logic using encryption algorithm, retrieving the signed hash value and public key of the user from the blockchain and verifying which outputs a “true” value if the two hash values are the same and the public key is associated with the signature (‘790, col.3, lines 47-48; col.7, lines 59-60; col.9, lines 35-36, 40-42).
8. As per claim 3:
Ranganathan discloses the following limitations:
The computing system of claim 1, the steps further comprising: determining whether the first set of identity data is encrypted (Col10, lines 23-25; discloses checking for encrypted data)
requesting a decryption key from the client device of the user in response to determining that the first set of identity data is encrypted (Col.10, lines 25-26; discloses decrypting encrypted data using a key associated with the credential token)
decrypting the first set of identity data with the decryption key in response to receiving the decryption key (Col.10, lines 32-33; col.17, lines 22-23; discloses obtaining the key and decrypting data after authorization)
9. As per claim 4:
Ranganathan discloses the following limitations:
The computing system of claim 1, the steps further comprising receiving a plurality of ID tokens from the immutable database (Col.4, lines 58-61, 65-67; discloses receiving multiple token types from the blockchain-backed RBAC model)
10. As per claim 5:
Ranganathan does not explicitly disclose, however, Ebrahimi, as shown, teaches the following limitations:
The computing system of claim 4, wherein the plurality of ID tokens comprises a first ID token and a second ID token, the first ID token contains a first set of identity data, and the second ID token contains a second set of identity data (Col.11, lines 11-16, 18-20; discloses record types (the signed hash record and the certification record) each containing different identity-related data)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method, wherein logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device of Ebrahimi (‘790, col.1, lines 41-43) with teaching of Ranganathan for integrated role-based access control of blockchains, wherein receiving a credential token and an access command that modify a datablock of a blockchain (‘746, col.1, lines 45-50) for receiving the encrypted certification record and transaction number (identities data) from the public storage facility with the user's public key and decrypting them using user's public key (‘790, col.11, lines 14-16, 18-20).
11. As per claim 6:
Ranganathan does not explicitly disclose, however, Ebrahimi, as shown, teaches the following limitations:
The computing system of claim 4, wherein the plurality of ID tokens comprises a first ID token and a second ID token, the first ID token contains a set of identity data, the second ID token contains a pointer, linking to the first set of identity data contained in the first ID token, and verification data associated with the first ID token (Col.11, lines 19-22, lines 36-39; discloses that the acknowledgement record (second token) contains the transaction number to the certification record (first token) and user’s digital signature (verification data))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method, wherein logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device of Ebrahimi (‘790, col.1, lines 41-43) with teaching of Ranganathan for integrated role-based access control of blockchains, wherein receiving a credential token and an access command that modify a datablock of a blockchain (‘746, col.1, lines 45-50) for creating an acknowledgement record that refers to or includes the certification record in order to link the two records, and including the acknowledgement record that comprises the certification record and the transaction number which are verified with a digital signature (‘790, col.11, lines 19-22, 36-39).
12. As per claim 7:
Ranganathan discloses the following limitations:
The computing system of claim 6, further comprising: determining whether the plurality of ID tokens are linked to each other in response to determining that a plurality of ID tokens are received; and returning an error indicating failed token linkage in response to determining that the plurality of ID tokens are not linked to each other (Col.9, lines 33-38; discloses whether the authorization token is present in the datablock header and generating an error/abort if the token is invalid or absent)
13. As per claim 8:
Ranganathan discloses the following limitations:
The computing system of claim 1, further comprising: requesting a verification token from the immutable database, wherein the verification token was generated during a previous verification process (Col.2, lines 10-12; discloses that authorization tokens generated during previous operations are stored in the blockchain)
causing the client device to prove that the user can access the secure resource, wherein granting permission for the user to access the secure resource further based in part on the verification token or proving that the user can access the secure resource (Col.2, lines 12-15; discloses requesting a previously generated verification token and using it as a basis for the current access grant decision)
14. As per claim 9:
Ranganathan discloses the following limitations:
The computing system of claim 8, wherein causing the client device to prove that the user can access the secure resource comprises: requesting an access token from the immutable database associated with the blockchain address; requesting content from the client device (Col.9, lines 44-45, 47-48; discloses requesting an authorization token from the blockchain)
applying the access token to the content to determine that the access token is valid (Col.9, lines 45-47; discloses applying the access token to determine validity)
determining that an identity of the user matches an identity of an owner associated with the blockchain address (Col.9, lines 47-49; discloses verifying, through valid digital signature, the user matches the blockchain address owner)
15. Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over US11201746B2 to Ranganathan in view of US9722790B2 to Ebrahimi and US7212279B1 to Feng.
16. As per claim 2:
Neither Ranganathan, nor Ebrahimi disclose, however, Feng, as shown, teaches the following limitations:
The computing system of claim 1, wherein the first set of identity data comprises a set of biometric data (Col/line 1/67-2/2; col.2, lines 13-17; discloses that biometric data constitutes the identity data used for verification)
causing the user to scan the set of biometric data at the client device (Col.5, lines 62-66; col.6, lines 1-4; discloses that the biometric identity verifier (the client device) prompts the user to place their finger on the sensor and provides real-time LCD feedback)
comparing the set of biometric data with the set of biometric data contained in the particular ID token to determine whether there is a match in response to receiving the set of biometric data of the user from the client device (Col.5, lines 30-34; col.6, lines 4-6; discloses comparing the live-captured biometric data with the biometric information stored in the user’s ID card)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method, wherein logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device of Ebrahimi (‘790, col.1, lines 41-43) and a biometric identity verifier comprises an optical fingerprint sensor coupled to an identification card reader of Feng (‘279, col/line 1/67-2/2) with teaching of Ranganathan for integrated role-based access control of blockchains, wherein receiving a credential token and an access command that modify a datablock of a blockchain (‘746, col.1, lines 45-50) for reading an ID card that contains biometric information about the user and comparing the biometric information on the card with the fingerprint of the user captured and verifying the user identity (‘279, col.2, lines 13-17, col.5, lines 62-64).
17. As per claim 10:
Ranganathan discloses the following limitations:
The computing system of claim 2, wherein the set of biometric data includes one or more of a fingerprint, a facial recognition data, a retinal scan, and a voice print (Col.2, lines 18-21, 24-28; col.5, lines 25-33, 39-41; discloses that the fingerprint data is captured by the optical fingerpring sensor, the camera component used for facial recognition and iris recognition, and the microphone component used to record the user’s voice for voice recognition)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method, wherein logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device of Ebrahimi (‘790, col.1, lines 41-43) and a biometric identity verifier comprises an optical fingerprint sensor coupled to an identification card reader of Feng (‘279, col/line 1/67-2/2) with teaching of Ranganathan for integrated role-based access control of blockchains, wherein receiving a credential token and an access command that modify a datablock of a blockchain (‘746, col.1, lines 45-50) for providing biometric identity verifier that the optical fingerpring sensor, the camera component used for facial recognition and iris recognition, and the microphone component used to record the user’s voice for voice recognition (‘279, col.5, lines 25-33, 39-41).
Response to Arguments
Rejection under 35 USC § 101
18. Amended independent claim 1 recites additional elements of receiving, from an immutable database recorded on a blockchain, a stack of identifier (ID) tokens, verifying a linkage between the stack of ID tokens, responsive to verifying the linkage, obtaining a second set of identity data from information associated with the stack of ID tokens, comparing, by the gate server, the first set of identity data and the second set of identity data to determine whether there is a match; determining, by the gate server, a number of the one or more verification tokens and a number of the one or more veto tokens, and determining, by the gate server, whether to grant user permission to access the secure resource based on (i) whether comparison indicates a match, (ii) the number of the one or more verification tokens and (iii) the number of the one or more veto tokens. The claim as a whole integrates the commercial process (authorizing a transaction based on the reputation of a user) into a practical application. Specifically, the additional elements recite a specific manner of storing verification and veto tokens into immutable database and retrieving them for matching and counting in order to provide the access to secure resource, that resulting in practical use of a blockchain technology. Thus, the claim 1 is eligible because it is not directed to the recited judicial exception.
Hence, the claim 1 and its dependent claims 2-10 are patent eligible.
Rejection under 35 USC § 112 (a)
19. Rejection of claim 1 due to amendments of claim is withdrawn.
Rejections under 35 U.S.C. § 112 (b)
20. Rejection of claim 1 due to amendments of claim is withdrawn.
Conclusion
21. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US9635000B1 – Muftic. – Discloses an identity management system (IDMS) based on the concept of peer-to-peer protocols and the public identities ledger, wherein the system manages digital identities, which are digital objects that contain attributes used for the identification of persons and other entities in an IT system and for making identity claims.
US20200112557A1 – Mccullough, IV et al. – Discloses Systems, methods, and apparatus for identity access management for web services, that includes: creating on a user device, a session's access token and an identity token to be sent along with a request for accessing web services and retrieving and pushing information from an instance storage which is client specific and protected from unauthorized access by another instance storage.
US20020097142A1 – Janiak et al. – Discloses a biometric authentication device for use with a token such as button having biometric data stored thereon, wherein the biometric device includes a fingerprint module having a fingerprint sensor for capturing a user's fingerprint placed onto the fingerprint sensor.
22. 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.
23. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
July 13, 2026
Prosecution Insights