DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Sept. 24, 2025, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Examiner interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. Each AIR should specifically explain how the interview will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. “Sounding out” the examiner is not permitted. See MPEP § 713.03. The Office is strictly enforcing interview practice.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. Eastern Time. For any GRANTED Interview Request, the applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for denial.
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 .
Election/Restrictions
Applicant’s election without traverse of Invention I, Claims 1–10 in the reply filed on Sept. 24, 2025, is acknowledged.
Preliminary Amendment
Applicant’s preliminary amendment to the claims filed Sept. 24, 2025, is acknowledged and entered. MPEP § 809.02(a) (“a reply to a requirement … should include a proper election along with a listing of all claims readable thereon, including any claims subsequently added.”).
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Status
Upon acknowledgement of the election and entry of the preliminary amendment, the status of claims is as follows:
Claims 1–10 and 21–30 are pending and examined with Claims 1, 21, and 30 in independent form.
No Claims are presently amended.
Claims 11–20 are presently cancelled.
Claims 21–30 are presently added.
This is a first action on the merits.
Claim Objections
Claims 1, 21, and 30 are objected to because of the following informalities. Appropriate correction is required.
Claims 1, 21, and 30: It is believed that “determining, using the ML model, the scenario-based decisions for retrying the processing of the one or more transactions based on the retry feature data and the plurality of features,” is “determining, using the ML model, the scenario-based decisions for retrying the processing of the one or more transactions based on the retry feature data for the plurality of features” as recited in the prior limitation.
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–10 and 21–30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–10 and 21–30 are directed to a statutory category. Claims 1–10 recite a “transaction processor system” and are therefore, directed to the statutory category of a “machine.” Claims 21–29 recite a “method” and are therefore, directed to the statutory category of a “process.” Claim 30 recites a “non-transitory machine-readable medium” and are therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination and recites, in part, emphasis added by Examiner to identify limitations with normal font indicating the abstract idea exception, bold limitations indicating additional elements. Each limitation is identified by a letter for later use as a shorthand notation in referencing/describing each limitation. Portions of the claim use italics to identify intended use limitations1 and underline, as needed, in further describing the abstract idea exception:
[A] 1. A transaction processor system comprising: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the transaction processor system to perform operations comprising:
[B] monitoring transactions being processed by a transaction processing [software] component associated with the transaction processor system;
[C] extracting, from transaction data for the transactions and processing scenario data for processing the transactions by the transaction processing [software] component, retry feature data for a plurality of features used by a machine learning (ML) model that is trained to determine scenario-based decisions on retrying a processing of one or more transactions of the transactions;
[D] determining, using the ML model, the scenario-based decisions for retrying the processing of the one or more transactions based on the retry feature data and the plurality of features, wherein the scenario-based decisions are determined simultaneously with the transaction being processed by the transaction processing [software] component;
[E] storing the scenario-based decisions while the one or more transactions are being processed by the transaction processing [software] component;
[F] detecting that a first transaction of the one or more transactions has failed to process by the transaction processing [software] component; and
[G] determining whether to execute a retry attempt of the first transaction based on one of the scenario-based decisions corresponding to the first transaction.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites “A transaction processor system” in Limitation A that “determin[es] whether to execute a retry attempt of the first transaction based on one of the scenario-based decisions corresponding to the first transaction” in Limitation G, which recites commercial or legal interactions under the organizing human activity exception because “determining whether to execute a retry attempt of the first transaction,” recites “sales activities or behaviors, and business relations.” MPEP § 2106.04(a)(2)(II)(B). Alternatively, “determining whether to execute a retry attempt of the first transaction,” recites a fundamental economic principle/practice under the organizing human activity exception because managing transaction processing failures describe fundamental concepts relating to the economy and ecommerce. MPEP § 2106.04(a)(2)(II)(A).
Step 2A, Prong Two: Rep. Claim 1 does not contain additional elements that integrate the abstract idea exception into a practical application because the additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f). The additional elements are limited to the computer components and indicated in bold, supra. The additional elements are: A transaction processor system comprising: a non-transitory memory with instructions and one or more hardware processors; a transaction processing component [software]; and a machine learning (ML) model that is trained to determine scenario-based decisions on retrying a processing of one or more transactions of the transactions.
Regarding transaction processor system comprising: a non-transitory memory with instructions and one or more hardware processors; a transaction processing component [software]; and a machine learning (ML) model that is trained to determine scenario-based decisions on retrying a processing of one or more transactions of the transactions, Applicant’s Specification does not otherwise describe them or describes them using exemplary language as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. Thus, Applicant takes the position that such hardware/software is so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶ 30 (“payment application 112 may be used to access a website and interfaces (e.g., via a browser application, mobile application, rich Internet application, or resident software application) … payment application 112 may correspond to a general browser application”); ¶ 62 (“Each model in ML model(s) 306 and 308 may correspond to one of available strategies 302, such as a token-based (e.g., NT) retry model, a real-time retry (e.g., using MC-ABU or the like) model, another processor or secondary processor retry model, a generalized address strategy model (or other strategy that relaxes, ignores, or skips address verification and/or an AVS, such as a zip code-based model), or the like.”); ¶ 83 (“software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems”); ¶ 11 (“The acquirer card processing system may process card data with any required transaction, user, and/or entity data (e.g., an amount, payee account, transaction timestamp or data, and the like)”; ¶ 74 (“The ML algorithm may be selected such as a GBM or Light GBM model, an XG Boost model, a random forest model, or a tree based algorithm model. … the model may be used, with any other trained models”); ¶ 79 (“a computer readable medium, which may refer to any medium”); ¶ 80 (any computer readable medium); ¶¶ 78, 79 (generic “processor” mentioned by name only); ¶ 27 (“Client device 110, transaction processor 120, and card processor gateways 140 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein.”); ¶ 25 (“system 100 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary devices and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or another suitable device and/or server-based OS.”); ¶ 28 (“client device 110 may be implemented as a personal computer (PC), a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g., GOOGLE GLASS®), other type of wearable computing device, implantable communication devices, and/or other types of computing devices capable of transmitting and/or receiving data.”); ¶ 35 (“network interface component 118 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including WiFi, microwave, radio frequency, infrared, Bluetooth, and near field communication devices.”); ¶¶ 34, 49 (any known and generic (exemplary) database/storage); ¶¶ 77–80, Fig. 5 (any known and generic (exemplary) computer system architecture.
The generic processor, here, appears to perform calculations (functions) that are programmed by software. Claim 1; Spec. ¶ 27. This is a computer doing what it is designed to do—performing directions it is given to follow.
Regarding the machine learning (ML) model that is trained to determine scenario-based decisions on retrying a processing of one or more transactions of the transactions, Applicant’s Specification explains it can be created in any known way using any known, AI, machine learning, or neural network technique, such that it could be almost anything. Spec. ¶¶ 62, 74 (cited supra). The trained model itself is created outside the scope of the claims and as claimed, receives inputs and provides an output, in this case scenario-based decisions (i.e., rules), like any model. Therefore, the ML Model is merely used and a solution at the level of a “generic black box” for determining scenario-based decisions and reads neatly on “use a computer” to do it in any way. MPEP § 2106.05(f); see also, Recentive Analytics, Inc. v. Fox Corp., 2025 U.S.P.Q.2d 628 (Fed. Cir. 2025) (holding “that patents that do no more than claim the application of generic machine learning to new data environments, without disclosing improvements to the machine learning models to be applied, are patent ineligible under § 101”).
Limitation A describes the “memory” “coupled” in some way with the “processor.” Limitation A further describes the “processor” executing “instructions” stored in the “memory” to perform the steps of the claimed invention. This takes generic hardware and describes the functions of receiving, storing, and sending data (instructions) between the processor and memory, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitations B–G describe the processor, memory, and instructions, performing the steps of the claimed invention, which represents the abstract idea exception itself. Performing the steps of the abstract idea exception itself simply adds a general-purpose computer after the fact to an abstract idea exception, MPEP § 2106.05(f)(2), or generically recites an effect of the judicial exception. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, looking at the additional elements individually and in combination, are no more than mere instructions to apply the exception using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
Rep. Claim 1 is not substantially different than Independent Claims 21 and 30 and includes all the limitations of Rep. Claim 1. Independent Claims 21 and 30 contain no additional elements. Therefore, Independent Claims 21 and 30 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as whole, looking at the additional elements individually and in combination, are not sufficient to amount to significantly more than the recited judicial exception. As discussed with respect to Step 2A, Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer and/or generic computer components. MPEP § 2106.05(f). The same analysis applies here in Step 2B. Mere instructions to apply an exception using a generic computer and/or generic computer components cannot provide an inventive concept. MPEP § 2106.05(I).
The additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception.
The pending claims in their combination of additional elements is not inventive. First, the claims are directed to an abstract idea. Second, each additional element represents a currently available generic computer technology, used in the way in which it is commonly used (individually generic). Last, Applicant’s Specification discloses that the combination of additional elements is not inventive. Spec., ¶¶ 83, 84 (steps/functions may be performed in any order); ¶¶ 11, 25, 27, 28, 30, 35, 39, 62, 74, 77, 78, 79, 80, 83, Fig. 5 (known and generic (exemplary) computer equipment as explained and cited supra.)
Thus, Examiner finds the additional elements of Rep. Claim 1 are elements that have been recognized as well-understood, routine, and conventional (“WURC”) activity in the particular field of this invention based on Applicant’s own disclosure2. Spec. ¶¶ 11, 25, 27, 28, 30, 35, 39, 62, 74, 77, 78, 79, 80, 83, Fig. 5; MPEP § 2106.05(d). Specifically, Applicant’s Specification discloses the recited additional elements (i.e., transaction processor system comprising: a non-transitory memory with instructions and one or more hardware processors; a transaction processing component [software]; and a machine learning (ML) model that is trained to determine scenario-based decisions on retrying a processing of one or more transactions of the transactions) are limited to generic computer components. These elements do no more than “apply” the recited abstract idea(s) on a known computer (e.g., processor) and computer-related components (e.g., memory). Leskovec, Jure, Anand Rajaraman, and Jeffrey David Ullman. "Mining of Massive Datasets." (2019) (“NPL Leskovec”) (cited on PTO-892) is prior art and additional evidence that trained machine learning algorithms were well-known and merely operate on the generic components. The Examiner also finds the functions of monitoring (data recognition, receiving), extracting (processing), storing, detecting, transmitting, determining and processing (e.g., performing mathematical operations on) data, described in Limitations A–G are all normal functions of a generic computer.
There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements in combination adds nothing that is not already present when looking at the elements individually. Their collective functions merely provide conventional computer implementation of the abstract idea at a high level of generality. Thus, Rep. Claim 1 does not provide an inventive concept.
Rep. Claim 1 is not substantially different than Independent Claims 21 and 30 and includes all the limitations of Rep. Claim 1. Independent Claims 21 and 30 contain no additional elements. Therefore, Independent Claims 21 and 30 are also directed to the same abstract idea.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. § 101. Dependent claims are dependent on Independent Claims and include all the limitations of the Independent Claims. Therefore, all dependent claims recite the same Abstract Idea. Dependent claims do not contain additional elements that integrate the abstract idea exception into a practical application or recite an inventive concept because the additional elements: (1) are mere instructions to apply the abstract idea exception; and/or (2) further limit the abstract idea exception of the Independent Claims. The abstract idea itself cannot provide the inventive concept or practical application. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 2, 3, 4, 5, 6, 7, 8, 9, 10, 22, 23, 24, 25, 26, 27, 28, and 29 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. Regarding “training the ML model using training data extracted from training data associated with past transactions and the plurality of features” (Claims 3, 23), NPL Leskovec is prior art and additional evidence of a human’s ability to train the ML model using data features extracted from training data by hand. NPL Leskovec, p.523; p. 524 (Example 13.1). “The use of a physical aid (e.g., pencil and paper or a slide rule) to help perform a mental step (e.g., a mathematical calculation) does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another” or a multi-step mental process. MPEP § 2106.04(a)(2)(III)(B). Thus, Claims 3 and 23 recite a mental process. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Conclusion
Claims 1–10 and 21–30 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
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.
Claims 1–6, 8–10, 21–26, and 28–30 are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al. (U.S. Pat. Pub. No. 2023/0012458) [“Jain”] in view of Jamkhedkar et al. (U.S. Pat. Pub. No. 2020/0410503) [“Jamkhedkar”].
Regarding Claim 1, Jain discloses:
A transaction processor system [Fig. 1] comprising: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the transaction processor system to perform operations comprising:
(See at least Figs. 1 & 5, and Claim 1, “A transaction processor system comprising: a non-transitory memory; and one or more hardware processors coupled to the nontransitory memory and configured to read instructions from the non-transitory memory to cause the transaction processor system to perform operations comprising:”)
monitoring transactions being processed by a transaction processing component [online transaction processor] associated with the transaction processor system;
(See at least Claim 1, “monitoring a processing of a plurality of transactions corresponding to the transaction processor system.” The monitoring is performed by the “online transaction processor”. ¶ 20 (“the online transaction processor may monitor success and/or failure of the retry attempts for failed transactions with the card processing system”)
extracting, from transaction data for the transactions and processing scenario data [financial instrument data] for processing the transactions by the transaction processing component [¶ 22], retry feature data for a plurality of features [one or more retry success features] used by a machine learning (ML) model that is trained to determine scenario-based decisions on retrying a processing of one or more transactions of the transactions [predictive score for retry success likelihood];
(See at least Claim 1, “extracting, from the transaction data and the financial instrument data, one or more retry success features; utilizing a machine learning (ML) model to determine, based on the one or more retry success features, a predictive score for a success of a retry attempt of the first transaction.” See also, ¶¶ 16, 18 (“The retry success
engine may then provide the extracted features and/or attributes as input to the trained ML model.”); see also ¶ 55 (identifying types of “retry success features”). “The ML model may then provide an output prediction or decision, such as a predictive score for retry success likelihood. In this regard, the predictive score may further correspond to a probability or likelihood (e.g., in percentage form or quantitative form usable with a cost function), which may allow comparison to other predictive scores, a threshold, and/or costs for executing or preventing the retry attempt.” ¶ 18. “After determining the predictive score, the predictive score may be used to determine whether to execute a retry of the failed transaction with the card processing system.” ¶ 19. The online transaction processor processes transaction data. ¶ 22.)
determining, using the ML model, the scenario-based decisions for retrying the processing of the one or more transactions based on the retry feature data and the plurality of features [one or more retry success features],
(See at least Claim 1, “utilizing a machine learning (ML) model to determine, based on the one or more retry success features, a predictive score for a success of a retry attempt of the first transaction.” See also ¶¶ 18, 38.)
[…, See Jamkhedkar, infra]
storing the scenario-based decisions […, See Jamkhedkar, infra];
(See at least ¶ 35, “For example, retry ML models 136 may include ML or neural network (NN) models trained using training data for past failed transactions and whether retry attempts of those failed transactions were successful, which may correspond to analytics data 126 stored by database 124.”)
detecting that a first transaction of the one or more transactions has failed to process by the transaction processing component; and
(See at least Claim 1, “detecting that a first transaction of the plurality of transactions has resulted in a transaction processing failure.” ¶ 20 (“the online transaction processor may monitor success and/or failure of the retry attempts for failed transactions with the card processing system”); see also ¶¶ 17, 34, 67 (“At step 408, a transaction that has resulted in a transaction processing failure with a card processor is detected.”)).
determining whether to execute a retry attempt of the first transaction based on one of the scenario-based decisions corresponding to the first transaction.
(See at least Claim 1, “determining whether to execute the retry attempt of the first transaction based on the predictive score and a retry success threshold.” See also, ¶¶ 19, 68.)
Jain discloses determining, using the ML model, the scenario-based decisions for retrying the processing of the one or more transactions based on the retry feature data and the plurality of features. Jain does not disclose wherein the scenario-based decisions are determined simultaneously with the transaction being processed by the transaction processing component. Jain’s ML model operates failure. Jain, ¶¶ 17, 18. Jain discloses storing the scenario-based decisions. Jain does not disclose storing the scenario-based decisions while the one or more transactions are being processed by the transaction processing component. Therefore, Jain does not disclose but Jamkhedkar discloses:
wherein the scenario-based decisions are determined simultaneously with the transaction being processed by the transaction processing component;
(See at least Abstract, “The computer system may initiate, prior to completion of the verification process for a transaction, a prediction process using a model, to predict whether the transaction will pass the verification process.” “prediction process 11 is used to predict whether or not the transaction will pass verification process 12. Prediction process 11, when utilized, makes predictions for particular transactions, such as by using machine-learning models 102.” ¶ 39. The “scenario-based decisions” are the preapproval predictions made by the prediction process 11 using ML models 102. The prediction process 11 and verification process 12 run in “parallel” or “concurrently.” ¶¶ 46, 63. Decisions are made while verification process 12 is still running. ¶¶ 32, 39, 69, 70.)
storing the scenario-based decisions while the one or more transactions are being processed by the transaction processing component;
(See at least ¶ 50, “If the prediction module 300 predicts that verification module 305 will approve the transaction and it is determined that the verification result has not been provided by the prediction timeout threshold, the prediction process can be initiated or completed to determine if preapproval is indicated. In such a case, the pre-approval may
be provided as the transaction response.” “As illustrated, this decision result is either Decision=Ok or Decision=Not Ok. When the decision module determines that Decision=Ok, this is an indication that the transaction is pre-approved. Accordingly, when the verification result is still not returned at the time of the merchant timeout, the pre-approval is transmitted to the merchant.” ¶ 73. “When both an indication of pre-approval eligibility and an indication that the prediction threshold has been reached are received by pre-approval decision submodule 320A, a prediction process begun by pre-approval eligibility sub-module 321 is completed by pre-approval decision sub-module 320A. If sub-module 320A predicts that requested transaction will be approved by verification process 12, pre-approval decision sub-module 320A may issue a pre-approval indication.” ¶ 58. “the decision module will have triggered at the prediction threshold (e.g., 2.3 seconds) if the verification response has not been returned. This means that the result of the decision module will be available as of the point the merchant timeout is reached.” ¶ 72. Thus, the pre-approval decision (yes/no) is generated and held by the prediction module 300 / decision submodule 320A before verification completes (e.g., 2.5 second timeout); decision is held and transmitted if verification does not return. ¶¶ 40, 50, 58, 59, 70, 72, 73, 74.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined scenario-based decisions are determined simultaneously with the transaction being processed by the transaction processing component and storing the scenario-based decisions while the one or more transactions are being processed by the transaction processing component as explained in Jamkhedkar, to the known invention of Jain, in the same field of invention, with the motivation to improve transaction processing efficiency by having retry decision immediately available upon failure without additional processing delay. Jamkhedkar, ¶ 27 (“financial penalties”); ¶ 38 (“latency”, “quality of service,” SLA); ¶ 41 (“quality of service agreements”); ¶ 2 (reducing latency).
Regarding Claim 2, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1 and scenario-based decisions
Jain further discloses
wherein the scenario-based decisions are associated with failure scenarios for retrying processing of the transactions, and
(See at least ¶ 14, “In order to minimize processing costs and wasted processing and network resources, the transaction processing may use one or more intelligent ML or other artificial intelligence (AI) models and engines to predict retry success and cost.” “Once a failure of a transaction processing attempt for a transaction occurs, the retry attempt engine may obtain … The retry attempt engine may then extract features and/or attributes used as input to the ML model, such as the retry success features and attributes used as input to an input layer and/or nodes of the ML model.” ¶ 18. “After determining the predictive score, the predictive score may be used to determine whether to execute a retry of the failed transaction with the card processing system.” ¶ 19. Thus, ML models that [predict retry success and determine retry decisions based on failure.)
wherein each of the failure scenarios are associated with a cause of a corresponding one of the transaction processing failures and
(See at least ¶ 2, “data processing requests between the two systems may fail at time, such as due to network communication issues, timeouts during decision service use, and other errors that may occur with data processors.” The training data for these transaction processing failures may include data regarding the underlying transaction, such as transaction, user, merchant, and other data for the requested transaction. The training data may also include financial source or instrument data, such as data associated with the payment card used to process the transaction, the payment network and network communications to transmit the payment card data to the card processing system, and/or data regarding a card processor and/or server system used with the card processing system to attempt processing of the transaction … As such, the training data may include a designation of the card processor that was used during the failure and/or retry attempt.” ¶ 15.)
a retry process for the corresponding one of the transaction processing failures
(See at least ¶ 12, “The transaction processor may execute a retry operation with the same transaction and card data to attempt to process the data with the card processing system” “After determining the predictive score, the predictive score may be used to determine whether to execute a retry of the failed transaction with the card processing system.” ¶ 19. “the training data may include retry attempts and whether those retry attempts were successful or results in a further failure and retry of the processing was unsuccessful.” ¶ 14.)
likelihood of success based on why the first transaction failed and how processing of the first transaction can be retried.
(See at least ¶ 12, “For example, the ML model may provide a predictive score on a likelihood of success to retry processing of the transaction with the card processing system (e.g., using the transaction and card data). The predictive output, such as the score, decision, or other value, may further be used with a cost function to determine whether to retry processing the transaction based on an underlying cost (e.g., due to the additionally consumed and used data processing operations and network communication resources).” “Thereafter, the transaction processors ML model trainer may perform feature extraction to extract features and/or attributes used to train the ML model. For example, training data features may correspond to those data features which allow for decision making by nodes of a ML model. In this regard, a feature may correspond to data that may be used to output a decision by a particular node, which may lead to further nodes and/or output decisions by the ML model.” ¶ 16. “Thus, the online transaction processor may determine whether to conserve processing resources and network communication bandwidth, usage, and resources using a predictive model.” ¶ 20.)
Regarding Claim 3, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1
Jain further discloses
wherein prior to the monitoring, the operations further comprise: determining the plurality of features include contextual features associated with transaction table data for transactions and
(See at least ¶ 15, “The training data for these transaction processing failures may include data regarding the underlying transaction, such as transaction, user, merchant, and other data for the requested transaction. The training data may also include financial source or instrument data, such as data associated with the payment card used to process the transaction, the payment network and network communications to transmit the payment card data to the card processing system, and/or data regarding a card processor and/or server system used with the card processing system to attempt processing of the transaction.” “Thereafter, the transaction processors ML model trainer may perform feature extraction to extract features and/or attributes used to train the ML model. For example, training data features may correspond to those data features which allow for decision making by nodes of a ML model. In this regard, a feature may correspond to data that may be used to output a decision by a particular node, which may lead to further nodes and/or output decisions by the ML model. The features may be used to determine mathematical relationships based on the ML algorithm to generate predictions and other decision-making, such as a predictive score of whether a retry attempt may be successful or may further fail when retried with the card processing system. For example, the features may be associated with the transaction data, card or financial instrument data, card processing system and network communications, or the like.” ¶ 16. “For example, retry success features may include data parameters in data tables and/or logs for 1) Card attributes 2) Processor related attributes 3) Merchant related attributes 4) Customer related attributes, including segments 5) Tokenization related attributes 6) Network routing attributes 7) Responses from processors. In this regard, the retry success features and/or attributes that are extracted may be associated with network data transmissions and/or network tokens for data, acquiring and/or issuing bank information, card or financial instrument processors and identification, merchant information including merchant codes and/or identification, financial instrument or card information, routing information for bank and/or credit accounts, and/or transaction information for items, costs, taxes or fees, and the like that may be included with the transaction.”)
roll-up features associated with at least one of a bank identification number (BIN), historical successes and historical failures for different retry strategies, or primary failure response codes; and
(See at least ¶ 55, “acquiring and/or issuing bank information”. “For example, the transaction data may include features and/or attributes that are extracted similar to a data features processed when determining when to execute a retry of a failed transaction. The training data may therefore include information about the underlying transactions that failed, such as items in the transactions, costs or fees for the transaction, transaction description, merchant information for merchants in the transaction, and/or user information for users purchasing items in the transactions. Further, the training data may include features associated with the credit card or other financial instrument processed in the transaction, and how the financial instrument was conveyed to the backend processing gateways and networks for the financial instrument. For example, the training data may include financial instrument and/or account numbers, authentication data (e.g., a PIN, card verification code, etc.), billing information and address, selected card or instrument processor, network tokens and/or data communications, encryption parameters and/or keys, and the like.” ¶ 64.)
training the ML model using training data features
(See at least ¶¶ 16, “Thereafter, the transaction processors ML model trainer may perform feature extraction to extract features and/or attributes used to train the ML model … The training feature may then be used for training the ML model using a ML algorithm and a ML training process.” See also ¶ 55.)
extracted from training data associated with past transactions and the plurality of features.
(See at least ¶ 14, “In order to train the ML models, training data for the ML models may be collected and/or accessed. The training data may correspond to past failed transactions, such as transaction processing failures for past transactions when processing was attempted with a card processing system.” “The training data for these transaction processing failures may include data regarding the underlying transaction, such as transaction, user, merchant, and other data for the requested transaction.” ¶ 15.
“training data features may correspond to those data features which allow for decision making by nodes of a ML model. In this regard, a feature may correspond to data that may be used to output a decision by a particular node, which may lead to further nodes and/or output decisions by the ML model. The features may be used to determine mathematical relationships based on the ML algorithm to generate predictions and other decision-making, such as a predictive score of whether a retry attempt may be successful or may further fail when retried with the card processing system. For example, the features may be associated with the transaction data, card or financial instrument data, card processing system and network communications, or the like.” ¶ 16; see also ¶ 55.)
Regarding Claim 4, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1 and determining whether to execute the retry attempt
Jain further discloses
wherein the determining whether to execute the retry attempt is further based on decision rules associated with at least one of a merchant to the first transaction, a cost of the first transaction, a lost revenue from the first transaction failing to be processed, a value of a customer to the first transaction, or a retry execution strategy associated with the first transaction.
(See at least ¶¶ 55, 64, cited supra.)
Regarding Claim 5, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1 and determining to execute the retry attempt, executing the retry attempt of the first transaction
Jain further discloses
wherein the operations further comprise: in response to determining to execute the retry attempt, executing the retry attempt of the first transaction using a retry strategy associated with the one of the scenario-based decisions.
(See at least ¶ 12, “The transaction processor may execute a retry operation with the same transaction and card data to attempt to process the data with the card processing system … If a cost for attempting the retry is less than the cost for abandoning or preventing the retry, then the transaction processor may execute the retry of the failed transaction processing request and may resubmit or retry processing the transaction with the card processing system.” Thus, Jain teaches executing a retry attempt in response to determining that the cost/ decision meets the threshold retry. “In various embodiments, the retry attempt of transaction processing may utilize a different processor and/or computing system of card processors 140. For example, a primary processor 142 may have attempted processing of the transaction, which failed, and thus a secondary processor 144 may be designated for the retry attempt for processing of the transaction. Thus, additional features with primary processor 142 and/or secondary processor 144 may also be used for the input features and attributes.” ¶ 38. Thus, Jain teaches using different processors as a retry strategy.
Regarding Claim 6, Jain and Jamkhedkar disclose:
The transaction processor system of claim 5 and the executing the retry attempt
Jain further discloses
wherein the executing the retry attempt is performed in response to the one of the scenario-based decisions meeting or exceeding a threshold likelihood for a retry success of the retry attempt, and
(See at least ¶ 16, “The predictive score may be compared to a threshold to determine whether to execute a retry, or may use a cost function, as discussed herein.” “After determining the predictive score, the predictive score may be used to determine whether to execute a retry of the failed transaction with the card processing system. In this regard, the predictive score may be compared to a threshold score or likelihood of success, which may be required to be met or exceed to execute the retry.” ¶ 19; see also ¶¶ 35, 62, 68, 69.)
Jain does not disclose but Jamkhedkar discloses:
wherein the executing the retry attempt is performed in real-time at a time of processing of the first transaction without causing a delay from determining the one of the scenario-based decisions at the time of the processing of the first transaction.
(See at least ¶ 32, “When a transaction request is received, the verification process may begin determining whether the transaction is to be approved or denied. If the verification process completes prior to the timeout, the results thereof (e.g., transaction approved or denied) may be provided, meaning that the prediction process is either not initiated or its results are discarded.” See also, ¶¶ 46, 63, 70, 72, 73. Jamkhedkar teaches decisions are pre-computer during processing and are ready before timeout (no additional delay). Execution happens “at the time of the merchant timeout.” ¶ 73, which is the processing time limit (without causing delay).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the executing the retry attempt is performed in real-time at a time of processing of the first transaction without causing a delay from determining the one of the scenario-based decisions at the time of the processing of the first transaction as explained in Jamkhedkar, to the known invention of Jain, in the same field of invention, with the motivation to improve transaction processing efficiency by having retry decision immediately available upon failure without additional processing delay. Jamkhedkar, ¶ 27 (“financial penalties”); ¶ 38 (“latency”, “quality of service,” SLA); ¶ 41 (“quality of service agreements”); ¶ 2 (reducing latency).
Regarding Claim 8, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1 and the detecting
Jain further discloses
wherein the detecting is based on one of a decline to process the first transaction by a card processor in communication with the transaction processing component or a failure to respond or process data by the card processor or the transaction processing component when processing the first transaction.
(See at least ¶ 51, “However, with charge 208, an error in data processing, a system or component of primary processor 210, a network communication of card data for charge operation 208, or the like may occur. Thus, primary processor 210 may fail to process the card data and corresponding transactions, for example, to issue the payment from the account and/or financial instrument for buyer 202 to issuer 222. As such, a decline notification 212 may be issued back to core payments engine 206.” See also, ¶¶ 2, 11, 14, 34.)
Regarding Claim 9, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1 and the ML model
Jain further discloses
wherein the ML model comprises one of a token-based ML model, a real-time billing service-based model, a retry with optional address fields and/or zip code-based model, or a retry with a different processor-based model.
(See at least ¶ 15, “In this regard, the card processing system may include a plurality of different card processors, such as a primary card processor and/or a secondary card processor. The primary card processor may be used for an initial transaction processing request, while the secondary card processor may be invoked during retry attempts. However, other card processors may also be used. As such, the training data may include a designation of the card processor that was used during the failure and/or retry attempt.” See also, ¶¶ 38, 44, 45, 46, 51, 55.)
Regarding Claim 10, Jain and Jamkhedkar disclose:
The transaction processor system of claim 1 and the scenario-based decisions
Jain further discloses
wherein the scenario-based decisions are associated with a plurality of transaction decline codes by a third-party processing system and
(See at least ¶ 51, “However, with charge 208, an error in data processing, a system or component of primary processor 210, a network communication of card data for charge operation 208, or the like may occur. Thus, primary processor 210 may fail to process the card data and corresponding transactions, for example, to issue the payment from the account and/or financial instrument for buyer 202 to issuer 222. As such, a decline notification 212 may be issued back to core payments engine 206.” “However, during certain transaction processing, a failure may occur. For example, network communications may encounter an error where all or a part of the data is not properly transmitted to the card processing system. At other times, a data processing failure, such as a timeout of a decision service or failure to process certain data, may occur at the card processing system. Each of these may therefore cause processing of the transaction and card data to fail.” ¶ 11; see also ¶ 55 (“Responses from processors.”). ¶ 43 (third-party processors, such as “Mastercard®”).
a plurality of retry strategies with the third-party processing system.
(See at least ¶ 15, “In this regard, the card processing system may include a plurality of different card processors, such as a primary card processor and/or a secondary card processor. The primary card processor may be used for an initial transaction processing request, while the secondary card processor may be invoked during retry attempts. However, other card processors may also be used. As such, the training data may include a designation of the card processor that was used during the failure and/or retry attempt.” “In various embodiments, the retry attempt of transaction processing may utilize a different processor and/or computing system of card processors 140. For example, a primary processor 142 may have attempted processing of the transaction, which failed, and thus a secondary processor 144 may be designated for the retry attempt for processing of the transaction.” ¶ 38; see also ¶¶ 19, 39.
Regarding Claim 21, Jain discloses:
A method comprising:
(See at least ¶ 10, “method”. See also, Fig. 4.)
The remaining limitations of Claim 21 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Jain and Jamkhedkar for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 21.
Regarding Claims 22, 23, 24, 25, 28, and 29, Jain and Jamkhedkar disclose:
The method of claim 21.
The remaining limitations of Claims 22, 23, 24, 25, 28, and 29, are not substantively different than those presented in Claims 2, 3, 4, 5, 8, and 9, respectively, and are therefore, rejected, mutatis mutandis, based on Jain and Jamkhedkar for the same rationale presented in Claims 2, 3, 4, 5, 8, and 9, respectively, supra.
Regarding Claim 26, Jain and Jamkhedkar disclose:
The method of claim 25.
The remaining limitations of Claims 26 are not substantively different than those presented in Claim 6 and is therefore, rejected, mutatis mutandis, based on Jain and Jamkhedkar for the same rationale presented in Claim 6, supra.
Regarding Claim 30, Jain discloses:
A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations comprising:
(See at least Claim 30)
The remaining limitations of Claim 30 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Jain and Jamkhedkar for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 30.
Claims 7 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Jain and Jamkhedkar and further in view of Cohn et al. (U.S. Pat. Pub. No. 2023/0196358) [“Cohn”].
Regarding Claim 7, Jain and Jamkhedkar disclose:
The transaction processor system of claim 5 and executing the retry attempt
Jain further discloses
wherein, prior to the executing the retry attempt, the operations further comprise: determining the retry strategy from a plurality of retry strategies
(See at least ¶ 15, “In this regard, the card processing system may include a plurality of different card processors, such as a primary card processor and/or a secondary card processor. The primary card processor may be used for an initial transaction processing request, while the secondary card processor may be invoked during retry attempts. However, other card processors may also be used. As such, the training data may include a designation of the card processor that was used during the failure and/or retry attempt.” See also, ¶¶ 38, 62, 63. The multiple strategies are retry with the same processor or with a different (secondary) processor.
[…, See Cohn, infra] after failing to be processed by the transaction processing component and […, See Cohn, infra]
(See at least ¶ 14, “In order to minimize processing costs and wasted processing and network resources, the transaction processing may use one or more intelligent ML or other artificial intelligence (AI) models and engines to predict retry success and cost. In order to train the ML models, training data for the ML models may be collected and/or accessed. The training data may correspond to past failed transactions, such as transaction processing failures for past transactions when processing was attempted with a card processing system … the training data may include retry attempts and whether those retry attempts were successful or results in a further failure and retry of the processing was unsuccessful.” ML models are optimized based on training data. ¶ 37. See Fig.4.)
Jain discloses determining the retry strategy from a plurality of retry strategies after failing to be processed by the transaction processing component. Jain does not disclose determining the retry strategy from a plurality of retry strategies based on a highest success rate of the retry strategy for the first transaction after failing to be processed by the transaction processing component. Jain does not disclose retry strategies supported by a merchant corresponding to each of the transaction. Thus, Jain does not disclose but Cohn discloses:
determining the [available payment networks 532] from a plurality of [available payment networks 532] based on a highest success rate of the [available payment networks 532] for the first transaction … and
(See at least ¶ 41, “Rules engine 345 may, accordingly, present payment transaction 506 with the MCC with the greatest likelihood of obtaining authorization. Likewise, transaction request 506 may have multiple payment networks 532 available for submission to issuer financial institution 518 for processing. Transaction data received from dataset of processing results 134 and the factor success metrics from factor success data 360 may indicate that one of the available payment networks 532 may yield a greater likelihood of obtaining authorization. Rules engine 345 may, accordingly, select the payment network with the greatest likelihood of obtaining authorization.” )
[available payment networks 532] supported by a merchant corresponding to each of the transaction [by MCC].
(See at least 40, “Generally, all authorization requests include an MCC, however some issuing banks view certain MCCs as riskier than others and therefore the selection of which MCC to include in the authorization requests-assuming the merchant qualifies for more than one-can influence the approval.” “In addition, a merchant may qualify for multiple different MCCs based on the nature of the businesses conducted by the merchant. Transaction data received from dataset of processing results 134 and the factor success metrics from factor success data 360 may indicate that one of the available MCCs may have a greater likelihood of obtaining authorization.” ¶ 41. “Merchant POS device 118 may be any device that facilitates receipt of a payment vehicle for payment of a purchase, such as for example, a POS terminal or a web interface. Further, merchant 116.” ¶ 24. “A plurality of transaction parameters associated with the purchase transaction may be stored in each transaction record, which may generally be used for settlement and financial recordkeeping. While the transaction parameters stored in each transaction record may vary, example transaction parameters may include, without limitation, account number, card number, payment vehicle information, product information (such as product type, product serial number, and so forth), loyalty account information, merchant information, transaction amount, response code, transaction date, transaction time, whether the transaction was a "card present" transaction, and so on.” ¶ 34.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined determining the [available payment networks 532] from a plurality of [available payment networks 532] based on a highest success rate of the [available payment networks 532] for the first transaction … and [available payment networks 532] supported by a merchant corresponding to each of the transaction as explained in Cohn, to the known invention of Jain, in the same field of invention, with the motivation to improve transaction authorization success rates and reduce lost revenue from declined transactions by selecting the retry strategy with the highest probability of approval based on historical success rates. Cohn, ¶¶ 2, 22; Jain, ¶¶ 2, 12.
Regarding Claim 27, Jain and Jamkhedkar disclose:
The method of claim 25.
The remaining limitations of Claims 27 are not substantively different than those presented in Claim 7 and is therefore, rejected, mutatis mutandis, based on Jain, Jamkhedkar, and Cohn for the same rationale presented in Claim 7, supra.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").