Prosecution Insights
Last updated: October 25, 2026
Application No. 18/997,337

SYSTEMS AND METHODS FOR VERIFIABLE APPROVAL

Non-Final OA §101§102§103
Filed
Jan 21, 2025
Priority
Jul 22, 2022 — provisional 63/391,479 +1 more
Examiner
TOLENTINO, RODERICK
Art Unit
2439
Tech Center
2400 — Computer Networks
Assignee
BLOCKCHAINS, INC.
OA Round
1 (Non-Final)
78%
Grant Probability
Favorable
1-2
OA Rounds
1y 8m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allowance Rate
561 granted / 723 resolved
+19.6% vs TC avg
Strong +35% interview lift
Without
With
+35.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
18 currently pending
Career history
749
Total Applications
across all art units

Statute-Specific Performance

§101
14.3%
-25.7% vs TC avg
§103
60.8%
+20.8% vs TC avg
§102
11.4%
-28.6% vs TC avg
§112
6.8%
-33.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 723 resolved cases

Office Action

§101 §102 §103
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 Office Action is in response to the instant Application 18/997,337 filed on 1/21/2025 and Preliminary Amendments filed on 1/21/2025. Preliminary amendments cancelled claims 9-14 and 16 and added claims 17-24. Claims 1-8, 15 and 17-24 are pending. This Office Action is Non-Final. Information Disclosure Statement The information disclosure statement (IDS), submitted on 1/21/2025, is 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 § 101 35 U.S.C. 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. Claim 24 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. Regarding claim 24; claim 24 is rejected under 35 U.S.C. 101 because the claims is directed to non-statutory subject matter. Claim 24 recites “[a] computer-readable storage medium”. Under a recent precedential opinion, the scope of the recited “computer readable storage medium” encompasses transitory media such as signals or carrier waves, where, as here the Specification does not limit the computer readable storage medium to non-transitory forms. See Ex parte Mewherter, 107 USPQ2d 1857, 1862 (PTAB 2013) (precedential) (holding recited machine-readable storage medium ineligible under § 35 U.S.C. 101 since it encompassed transitory media). The Examiner respectfully suggests that the claim be amended to either “A non-transitory computer-readable storage medium” or “a computer-readable storage device” to make the claim statutory under 35 USC 101; (emphasis added). Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim(s) 1-5, 15, 17-20 and 24 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hamel et al. (US 2019/0303587). As per claim 1, Hamel discloses a computer-implemented method for obtaining approval, the method comprising acts of: receiving a presentation associated with a user requesting access to a selected service, the presentation comprising a user information credential and an approval credential (Hamel, Paragraph 0208 recites “FIG. 7F is a flow diagram illustrating an embodiment of a process for providing access. In some embodiments, the process of FIG. 7F is executed by DCIAMS 7A06 of FIG. 7A. In the example shown, in 7F00, an application request is received from an application for authorization to access, wherein access to the application is requested by a user. In 7F02, it is determined whether to authorize access. For example, a determination of whether to authorize access is made based at least in part on a user credential, user login information, a user biometric, a PIN, etc. In the event it is determined not to authorize access, the process ends. In the event it is determined to authorize access, control passes to 7F04. In 7F04, the process authorizes access to the application in response to the application access request, wherein the authorizing access includes linking a user authentication device with the user. In 7F06, a sensitive data access request is received from the application for authorization to access a document that includes sensitive data, wherein access to the document is requested by the user. In 7F08, the user authentication device is determined in response to the sensitive data access request. For example, determining the user authentication device comprises determining the user authentication device linked with the user (e.g., the user authentication device linked with the user in 7F04). In some embodiments, determining the user authentication device linked with the user comprises looking up the link as stored in a user authentication device database as associated with the user identifier. In some embodiments, validity of the user authentication device is determined. For example, the process is further configured to validate a public key associated with the user authentication device in a distributed ledger.”); using a user public key associated with the user to verify the presentation and the user information credential; using an approval public key associated with the user to verify the approval credential (Hamel, Paragraph 0208 recites “For example, the process is further configured to validate a public key associated with the user authentication device in a distributed ledger. In some embodiments, this check is meant to secure the response from the user authentication device to the DCIAMS and, for example, that the signed response matches the registered DID for the user that was challenged.”) and in response to successfully verifying the user information credential and the approval credential, causing the selected service to be provided to the user (Hamel, Paragraph 0211 recites “In 7H10, it is determined whether the DCIAMS responds. In the event it is determined that the DCIAMS does not respond, the process ends. In the event it is determined that the DCIAMS responds, control passes to 7H12. In 7H12, a blinded document encryption key is received. In 7H14, the encrypted sensitive data and the blinded document encryption key are provided to the user application.”) As per claim 2, Hamel discloses the method of claim 1, Hamel further discloses further comprising an act of: using a decentralized identifier associated with the user to obtain the user public key and the approval public key (Hamel, Paragraph 0116 recites “In some embodiments, the mapping document comprises a decentralized identifier. In some embodiments, the mapping document conforms to a World Wide Web Consortium decentralized identifier document specification. In some embodiments, the mapping document maps a user identifier to a public key value or the user identifier comprises a public key. In some embodiments, the processor is further configured to receive an indication that the signed mapping document was validated. In some embodiments, the distributed ledger comprises a blockchain. In some embodiments, the signed mapping document is provided to a permissioned writer for the distributed ledger. In some embodiments, the system comprises a storage for storing a digital credential for proving a user qualification. In some embodiments, the processor is configured to provide a proof response comprising a signed verifiable form of the digital credential in response to a proof request challenge. In some embodiments, the proof request challenge comprises a request for one or more digital credentials wherein the one or more digital credentials are determined according to rules. In various embodiments, the rules are associated with a credential schema, a credential organization, a credential issuer, a credential location, a credential class identifier, a credential class name, a credential issuer, an identification number associated with the credential, a license associated with the credential, or any other associated credential data. In some embodiments, the rules are applied selectively. In some embodiments, the rules are applied based at least in part on a user identifier.”). As per claim 3, Hamel discloses the method of claim 2, Hamel further discloses further comprising acts of: receiving, from the user, a request for the selected service; and obtaining, based on the request, the decentralized identifier associated with the user (Hamel, Paragraph 0116 recites “In some embodiments, the mapping document comprises a decentralized identifier. In some embodiments, the mapping document conforms to a World Wide Web Consortium decentralized identifier document specification. In some embodiments, the mapping document maps a user identifier to a public key value or the user identifier comprises a public key. In some embodiments, the processor is further configured to receive an indication that the signed mapping document was validated. In some embodiments, the distributed ledger comprises a blockchain. In some embodiments, the signed mapping document is provided to a permissioned writer for the distributed ledger. In some embodiments, the system comprises a storage for storing a digital credential for proving a user qualification. In some embodiments, the processor is configured to provide a proof response comprising a signed verifiable form of the digital credential in response to a proof request challenge. In some embodiments, the proof request challenge comprises a request for one or more digital credentials wherein the one or more digital credentials are determined according to rules. In various embodiments, the rules are associated with a credential schema, a credential organization, a credential issuer, a credential location, a credential class identifier, a credential class name, a credential issuer, an identification number associated with the credential, a license associated with the credential, or any other associated credential data. In some embodiments, the rules are applied selectively. In some embodiments, the rules are applied based at least in part on a user identifier.”). As per claim 4, Hamel discloses the method of claim 2, Hamel further discloses wherein: the decentralized identifier is used to access information from an identity registry; and the accessed information is used to obtain the user public key and the approval public key (Hamel, Paragraph 0116 recites “In some embodiments, the mapping document comprises a decentralized identifier. In some embodiments, the mapping document conforms to a World Wide Web Consortium decentralized identifier document specification. In some embodiments, the mapping document maps a user identifier to a public key value or the user identifier comprises a public key. In some embodiments, the processor is further configured to receive an indication that the signed mapping document was validated. In some embodiments, the distributed ledger comprises a blockchain. In some embodiments, the signed mapping document is provided to a permissioned writer for the distributed ledger. In some embodiments, the system comprises a storage for storing a digital credential for proving a user qualification. In some embodiments, the processor is configured to provide a proof response comprising a signed verifiable form of the digital credential in response to a proof request challenge. In some embodiments, the proof request challenge comprises a request for one or more digital credentials wherein the one or more digital credentials are determined according to rules. In various embodiments, the rules are associated with a credential schema, a credential organization, a credential issuer, a credential location, a credential class identifier, a credential class name, a credential issuer, an identification number associated with the credential, a license associated with the credential, or any other associated credential data. In some embodiments, the rules are applied selectively. In some embodiments, the rules are applied based at least in part on a user identifier.”). As per claim 5, Hamel discloses the method of claim 4, Hamel further discloses wherein: the information accessed from the identity registry comprises a sequence of operations; the sequence of operations are applied to generate a document associated with the decentralized identifier; and the user public key and the approval public key are obtained from the document associated with the decentralized identifier (Hamel, Paragraph 0118 recites “The system for credential storing and verifying using a distributed ledger is used by the system to check a credential that is being used to establish identity or legitimacy. A server system acts to intermediate between a requestor requesting a credential and a user holding a credential. The server system is able to verify the legitimacy of the credential as the credential, a pointer to the credential (e.g., an identifier), other related information (e.g., a decentralized identifier document), and/or information about the credential are stored in a distributed ledger by the issuer (e.g., an encryption/decryption key for a stored credential) and can be used as a check for the credential. This distributed ledger is accessible by the server system. The distributed ledger enables secure storage using a smart contract module that is run by each of the distributed ledger nodes. The smart contract ensures that the request to store an item on the distributed ledger is performed by an authorized user and by an authorized writer (e.g., by having the request and/or requested item be signed by the authorized user and by the authorized writer). In addition, smart contract module is designed to check a schema associated with the issuer of the credential, a credential definition associated with the schema, a decentralized identifier (DID) document associate with a holder identifier associated with a holder of a credential, and/or a DID document associated with an issuer of the credential.”). Regarding claims 15 and 24, claims 15 and 24 are directed to a system and a computer-readable storage medium associated with the method of claim 1. Claims 15 and 24 are of similar scope to claim 1, and are therefore rejected under similar rationale. Regarding claim 17, claim 17 is directed to a similar system associated with the method of claim 2 respectively. Claim 17 is similar in scope to claim 2, respectively, and are therefore rejected under similar rationale. Regarding claim 18, claim 18 is directed to a similar system associated with the method of claim 3 respectively. Claim 18 is similar in scope to claim 3, respectively, and are therefore rejected under similar rationale. Regarding claim 19, claim 19 is directed to a similar system associated with the method of claim 4 respectively. Claim 19 is similar in scope to claim 4, respectively, and are therefore rejected under similar rationale. Regarding claim 20, claim 20 is directed to a similar system associated with the method of claim 5 respectively. Claim 20 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale. 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. 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. Claim(s) 6, 7, 21 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hamel et al. (US 2019/0303587) in view of Switchyarn et al. (US 2024/0195634). As per claim 6, Hamel discloses the method of claim 4, but fails to teach further comprising acts of: using the information accessed from the identity registry to identify a service endpoint associated with the user requesting access to the selected service; and sending a presentation request to the service endpoint. However, in an analogous art Switchyarn teaches further comprising acts of: using the information accessed from the identity registry to identify a service endpoint associated with the user requesting access to the selected service; and sending a presentation request to the service endpoint (Switchyarn, Paragraph 0022 recites “FIG. 1 is a flow diagram of an embodiment of the process for signing and submitting an electronic document in the present invention. In step 101, the process is initiated by a signer on an auxiliary client system, where the signer may input information related to the electronic document. In step 102, the auxiliary client system submits a request for the electric document along with sending information that is input by the signer, if any, to a server system. After the request is received at step 103, the server system generates a copy of the electronic document at step 104 by using the schema that is stored in an electronic document repository at step 105. In step 106, the copy of the electronic document-along with, if any, document metadata, such as the timestamp at which the server system received the request; information of a recipient system, such as its service endpoint; and information from the auxiliary client system-to the auxiliary client system at step 107. Subsequently, the auxiliary client system generates a visual indicium at step 108 and displays the indicium along with the electronic document to a client system at step 109. At step 110, the client system extracts the indicium and the electronic document from the display of the auxiliary client system”). It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Switchyarn’s Method For Signing And Submitting Electronic Documents Through Visual Indicia with Hamel’s Digital credentials for access to sensitive data because it offers the advantage of having a more secure access to a service endpoint. As per claim 7, Hamel in combination with Switchyarn teaches the method of claim 6, Hamel further teaches wherein: the presentation request is routed by the service endpoint to a device associated with the user and a device associated with an approver; the user information credential and the presentation are generated by the device associated with the user (Hamel, Paragraph 0208 recites “For example, the process is further configured to validate a public key associated with the user authentication device in a distributed ledger. In some embodiments, this check is meant to secure the response from the user authentication device to the DCIAMS and, for example, that the signed response matches the registered DID for the user that was challenged.”) and the approval credential is generated by the device associated with the approver and sent to the device associated with the user (Hamel, Paragraph 0184 recites “FIG. 6D is a flow diagram illustrating an embodiment of a process for credential authentication. In some embodiments, the process of FIG. 6D is executed by DCIAMS 6A06 of FIG. 6A. In the example shown, in 6D00, a request is received from an application for authorization to access, wherein access to the application is requested by a user. In 6D02, the request from the application for authorization to access is authenticated. For example, the request for authorization to access is authenticated using a username and password, a biometric, a credential, a two-factor authentication system, a personal identification number (PIN), etc. In some embodiments, authenticating the request from the application for authorization to access comprises providing an indication to the application of authorization to access. For example, authenticating the request from the application for authorization to access comprises providing an access token to the application.”). Regarding claim 21, claim 21 is directed to a similar system associated with the method of claim 6 respectively. Claim 21 is similar in scope to claim 6, respectively, and are therefore rejected under similar rationale. Regarding claim 22, claim 22 is directed to a similar system associated with the method of claim 7 respectively. Claim 22 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale. Claim(s) 8 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hamel et al. (US 2019/0303587) in view of Patel et al. (US 2019/0230073). As per claim 8, Hamel discloses the method of claim 1, but fails to teach wherein: the approval credential comprises at least one approval selected from a group consisting of: an approved service; an approved category of services; a time limit; and a spending limit. However, in an analogous art Patel teaches wherein: the approval credential comprises at least one approval selected from a group consisting of: an approved service; an approved category of services; a time limit; and a spending limit (Patel, Paragraph 0046 recites “The DID document 210 may also include authorization information 212. The authorization information 212 may allow the DID owner 201 to authorize third party entities the rights to modify the DID document 210 or some part of the document without giving the third party the right to prove ownership of the DID 205. For example, the authorization information 212 may allow the third party to update any designated set of one or more fields in the DID document 210 using any designated update mechanism. Alternatively, the authorization information may allow the third party to limit the usages of DID 205 by the DID owner 201 for a specified time period. This may be useful when the DID owner 201 is a minor child and the third party is a parent or guardian of the child. The authorization information 212 may allow the parent or guardian to limit use of the DID 201 until such time as the child in no longer a minor.”). It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Patel’s Attestation management with Hamel’s Digital credentials for access to sensitive data because it offers the advantage of being able to control limits of users. Regarding claim 23, claim 23 is directed to a similar system associated with the method of claim 8 respectively. Claim 23 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm. 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, Luu Pham can be reached at 571-270-5002. 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. RODERICK . TOLENTINO Examiner Art Unit 2439 /RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
Read full office action

Prosecution Timeline

Jan 21, 2025
Application Filed
Aug 20, 2026
Non-Final Rejection mailed — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12764143
ONE-CLASS THREAT DETECTION USING FEDERATED LEARNING
3y 0m to grant Granted Oct 13, 2026
Patent 12756728
DETECTION OF CRYPTOCURRENCY MINING TRAFFIC
3y 0m to grant Granted Oct 06, 2026
Patent 12750405
FRAMEWORK FOR AUTOMATED DATA-DRIVEN DETECTION ENGINEERING
3y 5m to grant Granted Sep 29, 2026
Patent 12737235
REMOTELY MANAGING EXECUTION OF JOBS IN A CLUSTER COMPUTING FRAMEWORK
2y 11m to grant Granted Sep 15, 2026
Patent 12719899
SYSTEMS AND METHODS FOR USE IN ASSESSMENTS IN CONNECTION WITH CYBER ATTACKS
2y 6m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
78%
Grant Probability
99%
With Interview (+35.3%)
3y 5m (~1y 8m remaining)
Median Time to Grant
Low
PTA Risk
Based on 723 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month