DETAILED ACTION
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 .
Status of Claims
Claims 1-2, 5-9, 12-16 and 19-27 are pending in this instant application per claim amendments and remarks filed on 07/08/2026. Claims 1, 8 and 15 are independent claims reciting method, system and non-transitory computer-readable storage medium claims. Claims 2/5-7/22-23, 9-12/24-25 and 16/19-21/26-27 are respective dependent claims. Said amendments of 08 JULY 2026 have amended Claims 1-2, 5, 7-8, 12, 14-15, 19 & 21, while adding new Claims 22-27, and cancelling Claims 3-4, 10-11 & 17-18.
This Office Action is a final rejection in response to the claim amendments and the remarks filed by the Applicant on 08 JULY 2026 for its original application of 15 OCTOBER 2024 that is titled: “Systems and Methods for Automatic Claims Settlement”.
Accordingly, pending claims 1-2, 5-9,12-16 and 19-27 are now being rejected herein.
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.
Claims 1-2, 5-9, 12-16 and 19-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more, wherein Claims 1, 8 and 15 are independent computer-implemented method, system and non-transitory computer-readable storage medium claims respectively.
Exemplary Analysis.
Claim 1: Ineligible.
The claim recites a series of steps. The claim is directed to a computer-implemented method reciting a series of steps, which is a statutory category of invention (Step 1 -- YES).
The claim is analyzed to determine whether it is directed to a judicial exception. The claim recites the limitations of: receiving a reimbursement request, wherein the reimbursement request includes an invoice and account information; processing the invoice to determine a reimbursement amount for the reimbursement request; querying a token vault to determine whether a stored token associated with the payment instrument is maintained in association with the account information; transmitting a balance information application programming interface (API) call corresponding to the reimbursement request, wherein the API call includes the account information, and wherein the balance information API call is transmitted as a result of token vault not maintaining the stored token associated with the payment instrument; receiving a transaction token and balance information associated with the payment, wherein the transaction token corresponds to a tokenized version of the payment; evaluating the reimbursement amount and the balance information to generate a determination, [[indicating whether fulfillment of the reimbursement request results in a negative balance for the payment instrument; [[as a result of the determination indicating that the reimbursement request would not result in the negative balance; wherein when the reimbursement API call is received at a service corresponding to the reimbursement method, the service uses the transaction token to provide the reimbursement amount according to the reimbursement method; and transmitting, in response to an indication that the reimbursement API call was successfully processes, a request to exchange the transaction token for a new stored token corresponding to the payment instrument; and storing the new stored token in the token vault, wherein the new stored token is made available for obtaining one or more subsequent transaction tokens associated with the payment instrument in lieu of transmitting the account information in new balance information API calls. In other words, the claim describes a framework through which automatic reimbursement for adjudicated claims is performed through dynamic evaluation of claims and of available reimbursement methods (per para [0002] in Specification, Field). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, covers performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and/or managing behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), but for the recitation of generic computer/s and/or computer component/s such as the devices/ mobile devices. These limitations fall under the “certain methods of organizing human activity” group (Step 2A1 -- YES).
Next, the claim is analyzed to determine if it is integrated into a practical application. The claim recites additional elements of: a payment instrument (it has been considered as hardware based on Specification, para [0048]). These additional elements are considered extra-solution activities. The devices and servers (service) in the steps are recited at a high level of generality, i.e., as generic processors performing generic computer/s functions of processing data. These generic processors are no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. Accordingly, these additional elements do not integrate the abstract idea into a practical application, because they do not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to the abstract idea (Step 2A2 -- NO).
Next, the claim is analyzed to determine if there are additional elements in this claim that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer and/or computer components over a network cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Because the additional elements described above were considered to be extra-solution activities in Step 2A, they are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine and conventional in the field. The disclosure does not provide any indication that these devices (processors) are anything other than generic processors and the Symantec, TLI, and OIP Techs. court decisions (MPEP 2106.05 (d) (II)) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Also, paras [0045]-[0050] of the Applicant’s own Specification describe (it has already been published as US Pub. No. 2025/ 0124480) ---
{“[0045] In an embodiment, once the claims reimbursement system 104 has determined, from the digitized version of the invoice 112, the payment amount being requested by the user 110, the claims reimbursement system 104 can determine whether the payment amount may be reimbursed to the user 110 through the selected reimbursement method. For example, if the user 110 has selected, as their reimbursement method, a particular payment instrument associated with the payment instrument service 108, the claims reimbursement system 104 may transmit an API call to the payment instrument service 108 to determine the existing balance (if any) associated with the particular payment instrument. This API call may include any available account information associated with the particular payment instrument that may be used by the payment instrument service 108 to identify the target payment instrument account and return the existing balance (if any) associated with this payment instrument. ………
[0046] In some instances, the API call to the payment instrument service 108 may include an access token or other authentication information that may be used by the payment instrument service 108 to authenticate the claims reimbursement system 104. This access token or other authentication information may be provided to the claims reimbursement system 104 through one or more available authentication processes (e.g., shared secrets, symmetric key cryptography, asymmetric key cryptography, etc.). Accordingly, in response to the API call from the claims reimbursement system 104, the payment instrument service 108 may authenticate the API call through evaluation of the provided access token or other authentication information. ……………………………………………………………………………………………………………………………
[0047] In response to the API call from the claims reimbursement system 104, the payment instrument service 108 may return the existing balance (if any) for the particular payment instrument selected by the user 110. Additionally, in some instances, the payment instrument service 108 may further return a transaction token 114 that may be used for any transactions between the claims reimbursement system 104 and the payment instrument service 108 for the particular payment instrument. The transaction token 114 may include a tokenized version of the particular payment instrument associated with the user 110. To generate the transaction token 114 corresponding to the particular payment instrument, the payment instrument service 108 may dynamically generate, in real-time, a unique payment instrument number that may be associated with the particular payment instrument selected for the present reimbursement. The unique payment instrument number may include one or more characteristics that may be used to associate the transaction token 114 with the payment instrument service 108. For instance, a certain number of digits associated with the unique payment instrument number may be fixed and may correspond to the payment instrument service 108. For instance, the unique payment instrument number may include an issuer identification number (IIN) or bank identification number (BIN), which may uniquely identify the payment instrument service 108. The remaining digits corresponding to the unique payment instrument number may be randomized and the complete unique payment instrument number may be automatically associated with the payment instrument selected by the user 110. ………
[0048] In addition to generating a unique payment instrument number for the transaction token 114, the payment instrument service 108 may assign an expiration date and Card Verification Value (CVV) or other security code for the transaction token 114. The combination of the unique payment instrument number, expiration date, and CVV or other security code may provide a unique combination of elements used to define a new transaction token 114 that may be uniquely associated with the pairing of the actual payment instrument selected by the user and the reimbursement for which the unique transaction token 114 is being generated. The transaction token 114, in an embodiment, is configured for a single use, whereby if a reimbursement is completed using the transaction token 114, the transaction token 114 is automatically expired by the payment instrument service 108. In some instances, the expiration date for the transaction token 114 may be short (e.g., one hour, two hours, one day, etc.) such that the transaction token 114 may be automatically expired if not used within a short window of time for the reimbursement. ………………………………………………………………………..
[0049] In an embodiment, prior to submitting an API call to the payment instrument service 108 to determine the existing balance associated with a selected payment instrument, the claims reimbursement system 104 queries a token vault 106 implemented by the claims adjudication service 102 to determine whether an existing stored token 116 corresponding to the selected payment instrument is stored within the token vault 106. The stored token 116 for a particular payment instrument may be similar to the transaction token 114 described above. For instance, the stored token 116 maintained in the token vault 106 may include a tokenized version of the particular payment instrument associated with the user 110. However, the stored token 116 may have a longer expiration date (e.g., one year, etc.), which may allow for continued retrieval of transaction tokens associated with the particular payment instrument without having to repeatedly provide payment instrument account information through the API call to the payment instrument service 108. This may reduce the payload size of any API calls to the payment instrument service 108, thereby reducing the required network bandwidth for obtaining transaction tokens. Further, by using a stored token 116, the amount of processing performed by the systems of the payment instrument service 108 is reduced, as these systems may not need to perform continued authentication of the claims reimbursement system 104 and evaluate payment instrument account information for generation of transaction tokens. ….
[0050] The stored token 116, in an embodiment, is provided by the payment instrument service 108 in exchange for a previously generated transaction token 114 associated with the selected payment instrument. For instance, if the token vault 106 does not maintain a stored token 116 for a particular payment instrument that is associated with a current claim reimbursement, the claims reimbursement system 104 may transmit a request to the payment instrument service 108 to obtain a stored token 116 corresponding to the particular payment instrument. This request may be transmitted to the payment instrument service 108 in response to an indication from the payment instrument service 108 that the reimbursement to the particular payment instrument was completed successfully. Once the claims reimbursement system 104 has obtained the stored token 116 from the payment instrument service 108, the claims reimbursement system 104 may store the stored token 116 in the token vault 106. For instance, the claims reimbursement system 104 may define a new entry corresponding to the payment instrument selected by the user 110 in the token vault 106. This new entry may include the payment instrument account information provided by the user 110. Once the claims reimbursement system 104 defines a new entry for the payment instrument or identifies an existing entry corresponding to the payment instrument, the claims reimbursement system 104 may associate the newly obtained stored token 116 with this entry within the token vault 106. This may allow the claims reimbursement system 104 to query the token vault 106 for the stored token 116 if the user 110 later submits a new reimbursement request that specifies the corresponding payment instrument as the preferred reimbursement method for the underlying claim. ”} ---
and indicate that the concept described by the extra-solution additional elements is conventional. Accordingly, a conclusion that the aforementioned extra-solution additional elements are well-understood, routine and conventional activity is supported under Berkheimer options 2 and 3, respectively.
Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional elements do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B -- NO), and the claim is not patent eligible.
The analysis above applies to all statutory categories of the invention including independent system Claim 8 and independent non-transitory computer-readable storage medium Claim 15, which perform the steps similar to those of the independent computer-implemented method Claim 1. Furthermore, the limitations of dependent method Claims 2-7, further narrow the independent method Claim 1 with additional steps and limitations (e.g., generating a digitized version of the invoice, wherein the digitized version of the invoice is generated according to a machine-readable format, …; … wherein when the transaction token is received at the service, the service applies the reimbursement amount to an account associated with the payment instrument; transmitting a request to exchange the transaction token for a stored token, wherein the stored token corresponds to a second tokenized version of the payment instrument, and wherein the stored token is exchangeable for new transaction tokens associated with the payment instrument, …; the invoice is associated with a policy corresponding to an insured entity, …; wherein the reimbursement method corresponds to a payment method indicated on the invoice; and retrieving a stored token, wherein the stored token corresponds to the account information associated with the payment instrument; etc.), and do not resolve the issues raised in rejection of the independent method Claim 1. Similarly, dependent system Claims 9-14 and dependent non-transitory computer-readable storage medium Claims 16-21 also further narrow their independent Claims 8 and 15 respectively, which are rejected as ineligible for patenting under 35 U.S.C. 101 based upon the same analysis.
Therefore, said Claims 1-21 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Response to Arguments
Applicant's remarks (pages 10--13) and claim amendments dated 08 JULY 2026 with respect to the rejection of amended Claims 1-2, 5-9, 12-16 and 19-27 have been carefully considered, but they are not persuasive and do not put these amended claims in a condition ready for Allowance. Thus, the rejection of amended Claims 1-2, 5-9, 12-16 and 19-27 has been maintained as described above. Additionally, Examiner notes that all of the previous rejections under 35 USC §103 have been withdrawn; because claim amendments of 07/08/2026 would have required at least five/5 or more references for the 103 rejection of independent claims alone, e.g., two new references like: US Patent no. 11,783,343 issued to Howard for its teachings of at least “query/ing a/the token vault”; and Pub. No. US 2023/ 0123576 filed by Gu et al. for its teachings of at least “checkout in a store” and ‘token associated with the payment account/system”. Thus, the rejection of amended Claims 1-2, 5-9, 12-16 and 19-27, as described above, is being maintained herein with some modifications in this Office Action, where needed to provide clarification in response to the Applicant’s claim amendments and remarks.
In response to the Applicant’s arguments of 07/08/2026 against rejection under 35 USC 101, Examiner respectfully disagrees. Also, Examiner clarifies that the instant application is nothing more than an improvement of an abstract idea, wherein using technology/ computers to execute an abstract idea is at most an improvement to the abstract idea.
In further response to Applicant’s arguments of 07/08/2026 against 101 rejection by stating --- {“the claims now recite a specific computer-implemented architecture in which a claims reimbursement system queries a token vault to determine whether a stored token corresponding to a payment instrument is available, …”}; Examiner notes that technology of “token vault” has been around for decades as shown in the following attached three/3 documents as Appendix --- (a) “An Introduction to Token Vaults” dated 25 AUGUST 2025 in 6 pages per google search; (b) “What is a Token Vault? Everything You Need to Know in 2026” dated 23 APRIL 2025 in 17 pages per google search; (c) wayback machine search for “What is a Token Vault?” showing its publication captures from 1996 to 2016 in 5 pages; that the Token Vault technology is not necessarily new and not discovered by this Applicant.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, THIS ACTION IS MADE FINAL. See at least 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.
The prior art made of record and not relied upon, listed in Form 892, that is considered pertinent to the Applicant's disclosure and review for not traversing already issued patents and/or claimed inventions by the claims of the current invention of the Applicant. Examiner notes that Form 892 contains more references than those cited in the rejection above under 35 USC 103, and that all the references cited on said Form 892 are relevant to this application and form a part of the body of prior art.
The Examiner has pointed out particular references contained in the prior art of record in the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. The Applicant should consider the entire prior art as applicable as to the limitations of the claims.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Sanjeev Malhotra whose telephone number is (571) 272-7292. The Examiner can normally be reached during Monday-Friday between 8:30-17:00 hours on a Flexible schedule.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to contact the Examiner directly.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas, can be reached on (571) 270-1836. The facsimile/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 & 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.
Electronic Communications
Prior to initiating the first e-mail correspondence with an Examiner, Applicant is responsible for filing a written statement with the USPTO in accordance with MPEP §502.03(II). All received e-mail messages including e-mail attachments shall be placed into this application’s record. The Examiner’s e-mail address is provided below at the end of this Office Action.
/S.M./
Examiner, Art Unit 3691
sanjeev.malhotra@uspto.gov
/ABHISHEK VYAS/Supervisory Patent Examiner, Art Unit 3691
Prosecution Insights