DETAILED ACTION
1. The present application, filed on or after March 13, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a regular utility application without a claim of priority.
Response to Amendment
2.. An RCE with accompanying Amendment was filed May 20, 2026 (hereinafter “Amendment”) and has been entered into the record and fully considered. The Amendment was filed in response to a Final Rejection dated February 20, 2026.
Despite the Amendment to the Claims and Applicant’s remarks, the Rejections under §101and §103 as set forth in the Non-Final Rejection are hereby maintained.
An explanation of the maintained Rejection and a response to Applicant’s arguments are set forth below. Please see the “Conclusion” section of this Action below for important information regarding responding to this Action.
NOTE: While the Amendment advanced prosecution in a helpful manner, it is clear that further clarification and specificity of the Claims – under both §§101 and 103 – remains to be accomplished. The Examiner recommends that an interview be scheduled and held in this case. Interviews are welcome at any stage of prosecution. Please use the AIR form, the link for which can be found at the end of this action, to schedule the interview.
Status of the Claims:
Claims 1 – 20 remain pending in this Application.
Independent Claims 1, 8 and 15 were amended to be structurally and functionally similar and virtually identical in scope.
Most of the dependent Claims were either not amended or amended in a trivial manner.
Dependent Claims 4 and 7 were amended in a slightly substantive manner and are addressed below. Dependent Claims 11, 14, and 18 were amended in a manner similar to Claims 4 and 7.
Therefore, the following explanation of the maintained rejections under §101 and §103 with regard to Claims 1 and Claim 4 and Claim 7 is considered explanatory of the Rejection as a whole.
With regard to the Amendment:
Claim 1 was amended as follows:
PNG
media_image1.png
727
692
media_image1.png
Greyscale
PNG
media_image2.png
717
651
media_image2.png
Greyscale
Claim 4 was amended as follows:
PNG
media_image3.png
693
676
media_image3.png
Greyscale
Claim 7 was amended as follows:
PNG
media_image4.png
568
685
media_image4.png
Greyscale
Summary of the Amendment and Broadest Reasonable Interpretation:
Claim terminology is to be given its plain and ordinary meaning to a person of ordinary skill in the art, consistent with the specification. This is true, unless the terms are given a special meaning. See MPEP §2111.01
Here, no special meaning is detected. As noted in the Amendment, the
changes to Claim 1 relate generally to the following:
Retrieving customer and merchant information
Routing the transaction data and other data just mentioned to an evaluation engine having a plurality of evaluation “services”
Selecting one of the evaluation services
Generating service-specific failure-state information
Compare the information against thresholds
Generate a transaction score
Using a threshold comparison, determine if the transaction can be approved
Generate an approval action
Send a notification or message of the approval to a user
These terms are recited at an extremely high level of generality and do not necessarily relate to computerized components.
The evaluation “services” appear to relate to a typical machine learning or computerized comparison of generated data against an organizational rule or policy with respect to the spending in question, i.e., whether transactions itemized on the expense report can be approved. Thus, “services” related to evaluating the transaction(s) clearly relates to a comparison of transaction related data against rules, policies, and/or historical transactions. (See at least [0030] – [0039].)
As noted in the earlier Final Rejection, “failure-state,” clearly relates to the failure of the comparisons mentioned to result in compliance with organization rules and policies.
With regard to §101:
Respectfully, the Office acknowledges Applicant’s good faith attempt to bring the claims within the eligibility guidelines. With respect to Claim 1, greater specificity has been added. Nevertheless, the steps are recited at an extremely high level of generality. Retrieving data, routing a transaction, selecting an “evaluation” engine or service and making a comparison of the data/transaction against established policies or rules, comparing the comparison against a threshold, and determining an approval (or denial) - is what computers do best. Sending an approval message is likewise incredibly common. This is what computers do. These are common and generic functions.
These limitations are recited at a very high level of generality. The Claim provides no specificity in terms of how these steps are accomplished or what algorithms are used or whether they are special or used or applied in any special way. Only the mere outcome or result that evaluations are performed and a score is generated and an approval message is sent is recited in the claim. These are common calculations. No new computerized components are recited. These limitations recite results or “outcome” of computer processing without specifying “how” a technical problem is solved. That is, the solution of a technical problem is not reflected in the Claim.
Taking the claim elements separately, the function performed by the computer elements at each step of the process is purely typical of processing transactions and making comparisons against rules or policies. Without greater specificity as to “how” certain functions solve a technical problem, the currently recited limitations can be achieved by any general purpose computer without special programming. In short, each step does no more than require a generic computer to perform generic computer functions. Considered as an ordered combination, the computer components of the Claim add nothing that is not already present when the steps are considered separately.
Claim 4 steps are recited with similar genericness. It recites steps related to:
Mapping a failure state “indicator” of each evaluation record to a corresponding score component; aggregating the score components, applying weights to produce the transaction score; and generating an approval based on a threshold comparison. These are very high level concepts recited at a generic – not specific – level.
An analysis of Claim 7 yields the same result. It recites an evaluation-service identifier, a threshold identifier, a threshold comparison result, and a failure indicator as noted in Claim 4. Thus, this Claim also lacks the required specificity for eligibility.
Accordingly, the Rejection is maintained.
With regard to §103:
The Rejection set forth in the Final Rejection is maintained.
Claims 1 - 20 are rejected under 35 U.S.C. §103 as being unpatentable over U.S. Patent Publication No. 2022/0012817 to Singh et al. (hereinafter “Singh) in view of U.S. Patent Publication No. 2024/0127240 to Abraham et al. (hereinafter “Abraham”)
It is respectfully submitted that the Singh reference is directly on point with the Amendment. while using different language, a person of ordinary skill in the art would understand that it correlates or “maps” directly onto Claim 1, as amended.
The following is a mapping of the amended portion of Claim 1 to Singh. It should be noted that the non-amended portions of the Claim map to Singh as set forth in previous Actions.
retrieving, by the transaction management system and from a customer metadata database, metadata corresponding to at least one of a transaction card holder associated with the transaction account and a merchant associated with the merchant system; (See at least 0004 – 0005 relating to a repository of approved and rejected prior expense reports; similarly see 0016; see 0030 – 0037 as to historical data including merchant data. Please note that a “merchant category code” is considered to constitute the recited term “merchant identifier” since it identifies a category of merchants and clearly comprises “merchant data.” Singh teaches that those requesting reimbursement are employees - see 0002 and 0020 - who hold credit cards – see 0078 and 0087.)
routing, by the transaction management system, the transaction data and the metadata to a transaction data evaluation engine comprising a plurality of evaluation services and a transaction approval layer; (See at least 0023, which teaches a range of parameters or categories for approving an expense report, and which therefore are considered to constitute the recited term “evaluation services:”
“[0023] Reimbursement entities may define entity specific reimbursement rules. For example, a reimbursement entity may define one or more conditions, such as one or more time periods within which an individual transaction must be included within an expense report, defining one or more time periods within which an individual transaction must originate, defining one or more locations within which an individual transaction must originate (e.g., zip code, city, state, country, and/or the like), defining a preapproval requirement, defining one or more identities of one or more entities associated with an individual transaction (e.g., the transaction originators, such as the reimbursement requestor's identity, store, vendor, and/or airline company identity, an identity of a client and/or recruit associated with an individual transaction, and/or the like), defining currency amount ranges (e.g., United States Dollar (USD) amount ranges, Singapore Dollar (SGD) amount ranges, and/or the like), and/or any other conditions.” (Emphasis Added)
These evaluation services or parameters compare the transaction to the rules or policies established by the entity or organization. (See also 0023 – 0025 and 0038.
See 0024 for further evaluation parameters, each one comprising an evaluation service.
As to an approval layer, see 0021 – 0022.)
including a first evaluation service and a second evaluation service; (See at least above limitation mapping)
processing, by the first evaluation service, the transaction data to generate a first failure state information; (See at least 0022 wherein failing to satisfy the rules or policies – and thereby generating “error data” - is considered to constitute the recited term “failure state.”)
processing, by the second evaluation service, the transaction data to generate a second failure state information; and (A person of ordinary skill in the art would understand that all parameters would have to be compared or evaluated with respect to the rules and polices and that, therefore, there could be two types error data generated.)
generating the transaction score based on the first failure state information and the second failure state information; (See at least Fig. 1, “aggregated risk score”)
selecting, by the transaction data evaluation engine and from the plurality of evaluation services, an evaluation service associated with the transaction; (See 0023 – 0024 wherein a person of ordinary skill in the art would understand that any one of the parameters could be selected for comparison or evaluation.)
generating, by the evaluation service and based on an evaluation of the transaction data against one or more thresholds of the evaluation service, service-specific failure-state information associated with the transaction, wherein the service-specific failure-state information comprises an evaluation record that encodes results of evaluating at least a respective portion of the transaction data against one or more thresholds associated with the given evaluation service, the evaluation record being formatted to support standardized aggregation across the plurality of evaluation services by the transaction approval layer; (See at least 0022 for error data which comprises failure-state information. See 0024 and 0042 for threshold comparisons. See Fig. 1 “aggregated risk score” indicating that the scores are standardized in a format for aggregation.
PNG
media_image5.png
435
656
media_image5.png
Greyscale
Such scores are considered to constitute the recited term “evaluation record.”)
generating, by the transaction approval layer, a transaction score based on the evaluation record; (See at least Fig. 1 aggregated risk score)
generating, by the transaction approval layer, a threshold comparison result indicating whether the transaction score satisfies a predefined approval threshold; (See at least 0090 – 0092)
determining, by the transaction approval layer, that the transaction score indicates the transaction is approved; (See at least 0090 – 0092)
in response to determining the transaction should be approved, the threshold comparison result indicating that the predefined approval threshold is satisfied, performing, by the transaction management system, an approval action for the transaction based on the transaction score; (See at least 0094.)
generating, by the transaction management system, a message indicating the approval action has been performed for the transaction, wherein the message comprises a report compiling the transaction data and the transaction score a machine-readable report that includes the transaction score, and the evaluation record.; and (See at least 0090 – 0091 relating to a “recommendation report.”)
in response to generating the message, transmitting the message to a client decision system. (See at least 0082 – 0085)
With regard to Claim 4, aggregating score components is clearly taught by Singh in Fig. 1 and 0026 – 0029. Applying weights to the risk scoring is taught at least at 0072.)
With regard to Claim 7, a person of ordinary skill in the art would readily understand that, when processing the expense reports for comparison with rules and policies, the “error data” must be generated in accordance with identifiers encoded into the computerized system. This is how computers work. Furthermore, identifiers are clearly taught in Abraham at 0040 – 0043.)
Accordingly, the rejection under §103 is maintained.
Response to Arguments
3. Applicant's arguments set forth in the Remarks section of the Amendment have been fully considered but they are not persuasive.
With regard to section 101 rejection, Applicant argues as follows:
PNG
media_image6.png
300
702
media_image6.png
Greyscale
With due respect, “routing” and “selecting” are not “technical architecture” limitations. They are standard and very common computerized functions. In fact, they are very close to mental steps. Nevertheless, looking at the Claim as a whole, it is progressing toward the specificity required to render the claim eligible. An interview is recommended.
With regard to 103, Applicant argues:
PNG
media_image7.png
217
670
media_image7.png
Greyscale
The Claim recites “selecting . . . . an evaluation service associated with the transaction.” Singh teaches:
“[0022] An expense report is considered a reference expense report when an expense report is stored with an indication of having been approved or rejected, referred to as an approval or rejection history. An expense report is rejected at least because one or more of the individual transactions is determined to include error data. Error data is data that fails to meet reimbursement rules defined by the reimbursing entity. Reimbursement rules define one or more conditions, which when satisfied or violated, cause an individual transaction and/or expense report to be approved or rejected. An individual transaction and/or expense report that fails to satisfy the reimbursement rules of the reimbursing entity comprises error data. An individual transaction and/or expense report comprising error data is rejected based at least on the error data therein.” (Emphasis Added)
Singh 0024 reads as follows:
“[0024] Further examples of reimbursement rules include rules having one or more comparison conditions (e.g., x<y) and/or combined conditions (e.g., a+b+c<y). Examples include defining a radial distance from a defined location within which an individual transaction originates (e.g., airport, convention center, hotel, office, travel route, and/or the like), defining a threshold amount spend as conditioned on a number of people included within a set of preapproved activities, and/or any other conditions (e.g., event conditions, equipment conditions, location conditions, client condition, activity condition, preapproval conditions, and/or the like).” (Emphasis Added)
While Singh may refer to conditions in the plural, it also teaches “one or more” conditions must be evaluated against the reimbursement rules. It lists many conditions which much be met. Clearly a “selection” is being made at some point along the way. A person of ordinary skill in the art would readily understand that each one of the conditions is being selected at some point. How else could the expense report be evaluation completely and accurately?
In the Claim, selecting one condition – or more – for evaluation is considered to be exactly what “generalized processing” is all about. If Applicant desires to recite how the selection is made or more details about the advantages of the selection, the Claim should be clarified.
Thus, the Rejection is maintained as being applicable to the Claims as amended, and in accordance with the positions of the Office in the previous Actions.
Conclusion
4. Applicant should carefully consider the following in connection with this Office Action:
A. Search and Prior Art
The search conducted in connection with this Office Action, as well as any previous Actions, encompassed the inventive concepts as defined in the Applicant’s specification. That is, the search(es) included concepts and features which are defined by the pending claims but also pertinent to significant although unclaimed subject matter. Accordingly, such search(es) were directed to the defined invention as well as the general state of the art, including references which are in the same field of endeavor as the present application as well as related fields (e.g. machine learning to detect fraud in connection with receipt or expense reimbursement). Indeed, there is a plethora of prior art in these fields.
Therefore, in addition to prior art references cited and applied in connection with this and any previous Office Actions, the following prior art is also made of record but not relied upon in the current rejection:
U.S. Patent Publication No. 2022/0114676 to Verma et al. This reference relates to the concept of detecting fraud in expense reports.
U.S. Patent Publication No. 2022/0076139 to Goldberg et al. This reference relates to the concept of machine learning in analyzing expense reports.
B. Responding to this Office Action
In view of the foregoing explanation of the scope of searches conducted in connection with the examination of this application, in preparing any response to this Action, Applicant is encouraged to carefully review the entire disclosures of the above-cited, unapplied references, as well as any previously cited references. It is likely that one or more such references disclose or suggest features which Applicant may seek to claim. Moreover, for the same reasons, Applicant is encouraged to review the entire disclosures of the references applied in the foregoing rejections and not just the sections mentioned.
C. Interviews and Compact Prosecution
The Office strongly encourages interviews as an important aspect of compact prosecution. Statistics and studies have shown that prosecution can be greatly advanced by way of interviews. Indeed, in many instances, during the course of one or more interviews, the Examiner and Applicant may reach an agreement on eligible and allowable subject matter that is supported by the specification.
Interviews are especially welcomed by this examiner at any stage of the prosecution process. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool (e.g. TEAMS).
To facilitate the scheduling of an interview, the Examiner requests the use of the AIR form as follows:
USPTO Automated Interview Request http://www.uspto.gov/interviewpractice.
Other forms of interview requests filed in this application may result in a delay in scheduling the interview because of the time required to appear on the Examiner's docket. Thus, the use of the AIR form is strongly encouraged.
D. Communicating with the Office
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM BUNKER whose telephone number is (571)272-0017. The examiner can normally be reached on M - F 8:30AM - 5:30PM, Pacific.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas, can be reached at 571-270-1836. Information regarding the status of an application, whether published or unpublished, may be obtained from the “Patent Center” system. For more information about the Patent Center system, see https://patentcenter.uspto.gov/
/William (Bill) Bunker/
U.S. Patent Examiner
AU 3691
william.bunker@uspto.gov
(571) 272-0017
June 18, 2026
/ABHISHEK VYAS/Supervisory Patent Examiner, Art Unit 3691
Prosecution Insights