DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/429,944, was filed on Feb. 1, 2024, and does not claim foreign priority or domestic benefit to any other application.
The effective filing date is after the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to file” provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of the Application
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on Feb. 2, 2026 has been entered.
This Non-Final Office Action is in response to Applicant’s communication of Feb. 2, 2026.
Claims 1-5, 7-15, and 17-19 are pending, of which claims 1 and 11 are independent.
All pending claims have been examined on the merits.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-5, 7-15, and 17-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The newly added features in independent claim 1 and independent claim 11 lack written description in the originally filed specification, specifically the term “deployed”.
In independent claim 1: “determined using a first interchange program that is deployed to a merchant transaction system” and “automatically replacing, by the eligibility model computer program, the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal interchange cost”.
In independent claim 11: “determined using a first interchange program that is deployed to the merchant transaction system” and “automatically replace the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal interchange cost and optimal transaction ratio”.
All dependent claims are also rejected, by virtue of dependence on a rejected independent claim.
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-5, 7-15, and 17-19 are rejected under 35 U.S.C. 101 because the claimed “software program” recites unembodied software-per-se, and therefore does not fall into any of the four statutory categories. See MPEP § 2106.03(I).
Independent claim 1 recites only software (“computer program executed by a downstream system”). This independent claim does not recite any hardware at all.
Independent claim 11 recites software that is “executed by” hardware, but the language is in the passive voice. Therefore, the system claim does not affirmatively recite that it includes hardware.
Claims 1-5, 7-15, and 17-19 are rejected under 35 U.S.C. §101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea, without “significantly more”.
In regards to Step 1 of the Alice/Mayo analysis, independent claim 1 is a method claim, and claim 11 is an apparatus claim.
For the sake of compact prosecution, we continue with the Alice/Mayo “abstract idea” analysis.
The abstract idea elements recited in independent claims 1 and 11 are shown in italic font. The “additional elements” and “extra solution steps” are shown in italic and underlined font.
In regards to claim 1,
1. A method for creating an eligibility-based interchange model, comprising:
ingesting, by an eligibility model computer program, interchange data from one or more sources of interchange data;
generating, by the eligibility model computer program, an eligibility-based model using the ingested interchange data;
making available, by the eligibility model computer program, the eligibility- based model to a plurality of downstream systems;
monitoring, by the eligibility model computer program, the one or more sources of interchange data for updates to the interchange data;
receiving, by an eligibility engine computer program executed by a downstream system, a plurality of transaction records for a plurality of transactions for a merchant, each of the plurality of transaction records associated with an actual interchange cost determined using a first interchange program that is deployed to a merchant transaction system;
identifying, by the eligibility engine computer program executed by the downstream system, an alternate interchange cost for each of the plurality of transaction records using the eligibility-based model;
determining, by the eligibility engine computer program executed by the downstream system, an optimal interchange cost for each of the plurality of transaction records, wherein the optimal cost is a lower cost of the actual interchange cost and the alternate interchange cost; and
automatically replacing, by the eligibility model computer program, the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal interchange cost.
In regards to claim 11,
11. A system, comprising:
one or more sources of interchange data;
a merchant transaction system;
an eligibility-based interchange model computer program executed by a computer processor that is configured
to ingest the interchange data from the one or more sources of interchange data,
to generate an eligibility-based model using the ingested interchange data, and
to monitor the one or more sources of interchange data for updates to the interchange data; and
an eligibility engine computer program executed by a downstream system that is configured
to receive a plurality of transaction records for a plurality of transactions for a merchant, each of the plurality of transaction records associated with an actual interchange cost,
to identify, for each of the plurality of transaction records, an alternate interchange cost using the eligibility-based model, and
to determine, for each of the plurality of transaction records, an optimal interchange cost as the lower cost of the actual interchange cost and the alternate interchange cost,
wherein the eligibility engine computer program is further configured to
determine, for the plurality of transaction records, an optimal transaction ratio, to compare the optimal transaction ratio to a threshold, and to
automatically replace the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal transaction cost and optimal transaction ratio in response to the optimal transaction ratio being below the threshold.
More specifically, claims 1-5, 7-15, and 17-19 recite an abstract idea: “Certain Methods of Organizing Human Activity", specifically “Commercial or Legal Interactions (Including Agreements in the form of Contracts; Legal Obligations; Advertising, Marketing, or Sales Activities or Behaviors; Business Relations)” as discussed in MPEP §2106(a)(2) Parts (I) and (II), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
The “Commercial or Legal Interactions” elements include:
In claim 1: “generating, by the eligibility model computer program, an eligibility-based model using the ingested interchange data”.
In claim 1: “identifying, by the eligibility engine computer program executed by the downstream system, an alternate interchange cost for each of the plurality of transaction records using the eligibility-based model”.
In claim 1: “determining, by the eligibility engine computer program executed by the downstream system, an optimal interchange cost for each of the plurality of transaction records, wherein the optimal cost is a lower cost of the actual interchange cost and the alternate interchange cost;”.
In claim 11: “generate an eligibility-based model using the ingested interchange data”.
In claim 11: “identify, for each of the plurality of transaction records, an alternate interchange cost using the eligibility-based model”.
In claim 11: “determine, for the plurality of transaction records, an optimal transaction ratio, to compare the optimal transaction ratio to a threshold”.
Moreover, claims 6-10 and 11-5, 7-15, and 17-19 also recite “Mathematical Concepts", specifically “Mathematical Relationships”, “Mathematical Formulas or Equations”, and “Mathematical Calculations”, as discussed in MPEP §2106.04(a)(2) Part (IV), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
The mathematical elements include:
In independent claim 1: “determining, by the eligibility engine computer program executed by the downstream system, an optimal interchange cost for each of the plurality of transaction records, wherein the optimal cost is a lower cost of the actual interchange cost and the alternate interchange cost;”.
In dependent claim 7: “determining, by the eligibility engine computer program and for the plurality of transaction records, an optimal transaction ratio”.
In dependent claim 7: “comparing, by the eligibility engine computer program, the optimal transaction ratio to a threshold”.
In independent claim 11: “determine, for each of the plurality of transaction records, an optimal interchange cost as the lower cost of the actual interchange cost and the alternate interchange cost”.
The “additional elements” include:
In claim 11: “a computer processor”,
In claim 11: “a downstream system” and “a merchant transaction system”, and
The “additional extra-solution elements” include:
In claims 1 and 11: “ingest/ingesting … interchange data from one or more sources of interchange data”,
In claims 1 and 11: “monitor/monitoring … the one or more sources of interchange data for updates to the interchange data”,
In claim 1:
“making available … the eligibility-based model to a plurality of downstream systems”,
“receiving, by an eligibility engine computer program executed by a downstream system, a plurality of transaction records for a plurality of transactions for a merchant, each of the plurality of transaction records associated with an actual interchange cost determined using a first interchange program that is deployed to a merchant transaction system”, and
“automatically replacing, by the eligibility model computer program, the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal interchange cost”. (The Examiner interprets that this is merely updating the installed software with a new version, which is common practice for software).
In claim 11:
“receive a plurality of transaction records for a plurality of transactions for a merchant, each of the plurality of transaction records associated with an actual interchange cost determined using a first interchange program that is deployed to a merchant transaction system”,
“implement a change in interchange program enrollment for the merchant in response to the optimal transaction ratio being below the threshold”¸ and
“automatically replace the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal transaction cost and optimal transaction ratio in response to the optimal transaction ratio being below the threshold”. (The Examiner interprets that this is merely updating the installed software with a new version, which is common practice for software).
This abstract idea is not integrated into a practical application, because:
The claim is directed to an abstract idea with additional generic computer elements. The generically recited computer elements (“a computer processor”, “a downstream system”, and “a merchant transaction system”) do not add a meaningful limitation to the abstract idea, because they amount to simply implementing the abstract idea on a computer. The claim amounts to adding the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.
The extra-solution activities (“ingest/ingesting”, “monitor/monitoring”, “making available”, “changing/ implement a change”, and “receive/receiving”) do not add a meaningful limitation to the method, as they are insignificant extra-solution activity;
The combination of the abstract idea with the additional elements (generically recited computer elements), and/or with the extra-solution activities, does not integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea, because:
When considering the additional computer elements "alone and in combination" (“a computer processor”, “a downstream system”, and “a merchant transaction system”), they do not add significantly more (also known as an "inventive concept") to the exception, because they amount to simply implementing the abstract idea on a computer. Instead, they merely add the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea.
In regards to the extra solution activities (“ingest/ingesting”, “monitor/monitoring”, “making available”, “changing/ implement a change”, and “receive/receiving”), these are recognized as such by the court decisions listed in MPEP § 2106.05(d).
More specifically, in regards to the “ingest/ingesting”, “monitor/monitoring”, “making available”, “changing/ implement a change”, and “receive/receiving” steps, see the court cases OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network) and (presenting offers and gathering statistics), OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
More specifically, in regards to the “making available”, see the court cases Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93 (Storing and retrieving information in memory).
The Examiner holds that the independent claims “use a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data)” or “simply add a general purpose computer or computer components after the fact to an abstract idea”.
All dependent claims are also rejected, because they merely further define the abstract idea.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1-5, 7, 10-15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US-2022/0101310-A1 to Kumar et al. (“Kumar”. Eff. Filed on Sep. 29, 2020. Published on Mar. 31, 2022) in view of US 10,402,807 B1 to Iyer et al. (“Iyer”. Filed on Feb. 28, 2017. Published on Sep. 3, 2019.
In regards to claim 1,
1. A method for creating an eligibility-based interchange model, comprising:
ingesting, by an eligibility model computer program, interchange data from one or more sources of interchange data;
(See Kumar, para. [0058]: “In one embodiment, the database 204 is configured to store machine-learning models, interchange rate rules of a plurality of interbank networks, and interbank routing tables of the acquirer 108 and the issuer 106.”)
(See Kumar, para. [0060]: “The processor 206 is operatively coupled to the communication interface 210 such that the processor 206 is capable of communicating with a remote device 216 such as, the issuer server 106, the acquirer server 108, or with any entity connected to the network 116 (e.g., as shown in FIG. 1). In one embodiment, the processor 206 is configured to access historical transaction data associated with the acquirer server 108 from an acquirer database. The historical transaction data may be related to a number of payment transactions processed by the acquirer server 108 in past time. The number of payment transactions may be associated with one or more different payment transaction types. In one embodiment, the processor 206 is configured to receive interbank network routing tables including all eligible interbank network lists and static priority routing lists from the acquirer server 108 and the issuer server 106.”)
(See Kumar, para. [0062]: “In one embodiment, the processor 206 includes a transaction forecasting engine 218, an interchange prediction engine 220, and an optimization engine 222.”)
(See Kumar, para. [0102]: “At 415, the server system 110 receives historical transaction data associated with the acquirer server 108. The historical transaction data may include types of different payment transactions processed by the acquirer server 108 in past time.”)
generating, by the eligibility model computer program, an eligibility- based model using the ingested interchange data;
(See Kumar, para. [0034]: “The historical transaction data includes, but is not limited to, transaction history between the acquirer and an issuer. The server system is configured to train a machine-learning model based at least on the historical transaction data. In one embodiment, the machine-learning model is also re-trained based on real time transactions between the acquirer and the issuer. The machine-learning model is utilized for determining or predicting the plurality of payment transaction types (e.g., Point-of-Sale (POS), Automatic Teller Machine (ATM), e-commerce based payment transactions, etc.), corresponding to the future payment transactions processing via the acquirer for a particular period of time (e.g., next one year).”)
(See Kumar, para. [0066]: “More particularly, the transaction forecasting engine 218 implements a machine-learning model (e.g., time-series forecasting model) over the historical transaction data for predicting the future payment transactions from the acquirer server 108 for the particular period of time. The machine-learning model is trained based at least on the historical transaction data.”)
(See Kumar, para. [0067]: “In one embodiment, the machine-learning model may employ time series analysis techniques, such as, for example, Exponential Smoothing Models (ESM), Auto-Regressive Integrated Moving Average Models either with or without exogenous variables (ARIMA[X]), Unobserved Component Models (UCM), Intermittent Demand Models (IDM), and the like. In one embodiment, the machine-learning model may also be re-trained with real-time payment transaction data at different time intervals (e.g., daily, weekly, monthly). In one non-limiting example, the machine-learning model may be, but not limited to, reinforcement machine-learning model, which is utilized for algorithms to reduce transit time, and for optimizing space utilization and warehouse operations.”)
(See Kumar, para. [0097]: “In one embodiment, since the transaction forecasting engine 218, and the interchange prediction engine 220 include machine-learning models which use a learning-driven technique, it is possible to incrementally update the machine-learning models (e.g., from feedback provided by a human or computer administrator) so that it can adapt for routing the payment transaction that emerge over time. To do so, the machine-learning models incrementally update their probability distribution weights during a detection phase. In this regard, the machine-learning models can initially be trained using the training data and then later tuned/refined using feedback. Further, this feedback may be incorporated immediately in a dynamic online manner.”)
making available, by the eligibility model computer program, the eligibility-based model to a plurality of downstream systems;
(See Kumar, para. [0034]: “The historical transaction data includes, but is not limited to, transaction history between the acquirer and an issuer. The server system is configured to train a machine-learning model based at least on the historical transaction data. In one embodiment, the machine-learning model is also re-trained based on real time transactions between the acquirer and the issuer. The machine-learning model is utilized for determining or predicting the plurality of payment transaction types (e.g., Point-of-Sale (POS), Automatic Teller Machine (ATM), e-commerce based payment transactions, etc.), corresponding to the future payment transactions processing via the acquirer for a particular period of time (e.g., next one year).”)
(See Kumar, para. [0097]: “In one embodiment, since the transaction forecasting engine 218, and the interchange prediction engine 220 include machine-learning models which use a learning-driven technique, it is possible to incrementally update the machine-learning models (e.g., from feedback provided by a human or computer administrator) so that it can adapt for routing the payment transaction that emerge over time. To do so, the machine-learning models incrementally update their probability distribution weights during a detection phase. In this regard, the machine-learning models can initially be trained using the training data and then later tuned/refined using feedback. Further, this feedback may be incorporated immediately in a dynamic online manner.”)
monitoring, by the eligibility model computer program, the one or more sources of interchange data for updates to the interchange data;
(See Kumar, para. [0097]: “In one embodiment, since the transaction forecasting engine 218, and the interchange prediction engine 220 include machine-learning models which use a learning-driven technique, it is possible to incrementally update the machine-learning models (e.g., from feedback provided by a human or computer administrator) so that it can adapt for routing the payment transaction that emerge over time. To do so, the machine-learning models incrementally update their probability distribution weights during a detection phase. In this regard, the machine-learning models can initially be trained using the training data and then later tuned/refined using feedback. Further, this feedback may be incorporated immediately in a dynamic online manner.”)
identifying, by the eligibility engine computer program executed by the downstream system, an alternate interchange cost for each of the plurality of transaction records using the eligibility-based model;
(See Kumar, para. [0098]: “In this example, the transactions 1 and 2 have routed through an interbank network 310 and the transaction 3 has routed through an interbank network 312. In one example, the server system 200 has information of the best interbank networks for each transaction type, which is determined using linear optimization results.”)
(See Kumar, para. [0099]: “FIG. 4 represents a sequence flow diagram 400 for determining an optimal interbank network with the least transaction cost using linear optimization methods, in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.”)
determining, by the eligibility engine computer program executed by the downstream system, an optimal interchange cost for each of the plurality of transaction records, wherein the optimal cost is a lower cost of the actual interchange cost and the alternate interchange cost; and
(See Kumar, para. [0018]: “FIG. 4 is a sequence flow diagram for determining an optimal interbank network with the least transaction cost using linear optimization methods, in accordance with an embodiment of the present disclosure[.]”)
(See Kumar, para. [0099]: “FIG. 4 represents a sequence flow diagram 400 for determining an optimal interbank network with the least transaction cost using linear optimization methods, in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.”)
However, under a conservative interpretation of Kumar, it could be argued that Kumar does not explicitly teach the following, which are taught by Iyer:
receiving, by an eligibility engine computer program executed by a downstream system, a plurality of transaction records for a plurality of transactions for a merchant, each of the plurality of transaction records associated with an actual interchange cost determined using a first interchange program that is deployed to a merchant transaction system;
(See Iyer, col.13, lines 10-27: “An action 502 comprises receiving transaction information 506 for a proposed purchase transaction from the merchant POS device 104. The transaction information may indicate various information, including the transaction amount and an identifier of the payment instrument being used for payment. Generally, the transaction information may indicate values corresponding to the one or more of the multiple features listed above.”)
Prior to authorization of the proposed purchase transaction, the payment processing system performs an action 508 of determining predicted fees, including interchange fees, that will be charged by each of multiple payment networks and/or payment gateways that are associated with the payment instrument identified by the transaction information. Payment networks and payment gateways are referred to collectively herein as transaction processors or exchange processors.”)
(See Iyer, col.13, lines 34-47: “An action 510 comprises selecting one of the multiple exchange processors associated with the payment instrument, based at least in part on the predicted interchange fee amounts of the multiple exchange processors. Specifically, the action 510 comprises selecting the exchange processor with the lowest predicted transaction processing fees, wherein the predicted transaction processing fees include interchange fees.
An action 512 comprises initiating payment using the selected exchange processor. For example, the action 512 may comprise initiating an authorization for the new purchase transaction and a subsequent capture to initiate a funds transfer for the transaction amount to an acquirer associated with the payment processing system 102.”)
automatically replacing, by the eligibility model computer program, the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal interchange cost.
(See Iyer, col.10, lines 33-48: “In certain embodiments, a method or analytic tool referred to as a Random Forest Regressor may be used to generate a regression tree based on the training data 310. The regression tree may be used at a later time to predict the interchange fee for a given transaction based on the feature values of that transaction. In these embodiments, the predictive model 316 may therefore comprise such a regression tree. When feature values corresponding to a particular transaction are used as inputs, the regression tree produces an output value corresponding to an estimated or predicted amount of a corresponding interchange fee for the particular transaction.
The method 300 may be repeated periodically to update the predictive model 316. For example, the predictive model 316 may be updated every week or every month, based on relatively new training data.”)
The Examiner determines that it is a matter of design choice whether the predictive model is “deployed to the merchant transaction system” or is deployed at a computer at some other server location.
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the “Methods and systems for determining an optimal interbank network for routing real-time payment transactions”, as taught by Kumar above, with “Estimating interchange fees for card payments”, as further taught by Iyer above, because both references are in the same art of determining an optimal interbank network for routing real-time payment transactions, based on interchange fees.
In regards to claim 2,
2. The method of claim 1, wherein the interchange data is for a plurality of payment brands.
(See Kumar, para. [0017]: “FIG. 3 is an example representation of a transaction routing process, in accordance with an example embodiment of the present disclosure”)
(See Kumar, para. [0098]: “Referring now to FIG. 3, an example representation 300 of a transaction routing process is illustrated, in accordance with an example embodiment of the present disclosure. The server system 200 receives payment transaction requests associated with payment transaction 1, transaction 2 and transaction 3 (see 302, 304 and 306) from an acquirer bank (e.g., “World bank”). The server system 200 extracts BIN information from the payment transaction requests and finds eligible interbank networks list for the transactions. Based on the eligible interbank networks lists, the server system 200 routes the transactions 1, 2 and 3 through their best interbank networks with the lowest transaction cost to the respective issuer. In this example, the transactions 1 and 2 have routed through an interbank network 310 and the transaction 3 has routed through an interbank network 312. In one example, the server system 200 has information of the best interbank networks for each transaction type, which is determined using linear optimization results.”)
In regards to claim 3,
3. The method of claim 1, wherein the interchange data identifies a plurality of interchange programs, and for each of the plurality of interchange programs, comprises interchange program qualifications, interchange program rates, and eligible payment types.
(See Kumar, para. [0105]: “At 430, the server system 110 determines static, or fixed interchange costs, incurring to the acquirer 108 for different types of future payment transactions while routing through eligible interbank networks. In one example, for credit card transactions, the static interchange cost is $0.75 as defined by the issuer 106. The determination is performed using the interchange prediction model which is trained using the historical transaction data and interchange rate rules associated with the plurality of interbank networks. The interchange rate rules define what interchange cost that would be applied for each payment transaction type. In one embodiment, the fixed interchange cost is calculated based on the payment transaction type, merchant category, payment card type, and a payment transaction amount.”)
In regards to claim 4,
4. The method of claim 1, wherein the interchange data is extracted from historical transactions.
(See Kumar, para. [0105]: “At 430, the server system 110 determines static, or fixed interchange costs, incurring to the acquirer 108 for different types of future payment transactions while routing through eligible interbank networks. In one example, for credit card transactions, the static interchange cost is $0.75 as defined by the issuer 106. The determination is performed using the interchange prediction model which is trained using the historical transaction data and interchange rate rules associated with the plurality of interbank networks. The interchange rate rules define what interchange cost that would be applied for each payment transaction type. In one embodiment, the fixed interchange cost is calculated based on the payment transaction type, merchant category, payment card type, and a payment transaction amount.”)
In regards to claim 5,
5. The method of claim 1, wherein the eligibility-based model comprises rates for the interchange programs offered by brands in regions.
(See Kumar, para. [0105]: “At 430, the server system 110 determines static, or fixed interchange costs, incurring to the acquirer 108 for different types of future payment transactions while routing through eligible interbank networks. In one example, for credit card transactions, the static interchange cost is $0.75 as defined by the issuer 106. The determination is performed using the interchange prediction model which is trained using the historical transaction data and interchange rate rules associated with the plurality of interbank networks. The interchange rate rules define what interchange cost that would be applied for each payment transaction type. In one embodiment, the fixed interchange cost is calculated based on the payment transaction type, merchant category, payment card type, and a payment transaction amount.”)
The Examiner interprets that Kumar’s “plurality of interbank networks” reads upon the claimed “brands in regions”.
In regards to claim 6, it has been cancelled.
In regards to claim 7,
7. The method of claim 1, further comprising:
determining, by the eligibility engine computer program and for the plurality of transaction records, an optimal transaction ratio;
comparing, by the eligibility engine computer program, the optimal transaction ratio to a threshold; and
implementing, by the eligibility engine computer program, a change in interchange program enrollment for the merchant in response to the optimal transaction ratio being below the threshold.
(See Kumar, para. [0012]: “Further, the computer-implemented method includes determining whether the number of future payment transactions routing through the interbank network exceeds a threshold value, or not, and routing real-time payment transactions through an optimal interbank network with a lowest total transaction cost, wherein the optimal interbank network is determined using the linear optimization.”)
(See Kumar, para. [0039]: “When the number of future payment transactions routing through the interbank network exceeds a threshold value, the server system is configured to apply a merchant-specific discount to the fixed interchange cost for determining a reduced total transaction cost for the particular payment transaction type.”)
(See Kumar, para. [0090]: “More specifically, the optimization engine 222 is configured to apply the merchant-specific discount over the fixed interchange cost for the future payment transactions when the number of all types of the future payment transactions routing through the Network 1 is greater than a predefined threshold value (k). In one embodiment, the optimization engine 222 is also configured to satisfy the following one or more constraints while maximizing the objective function”)
The Examiner interprets that a ratio of price per transaction reads upon the claimed “optimal transaction ratio”.
In regards to claim 10,
10. The method of claim 1, further comprising: identifying, by the eligibility engine computer program, the interchange program associated with the optimal interchange cost.
(See Kumar, para. [0040]: “The server system is configured to determine whether the interbank network is an optimal interbank network, or not, based on the linear optimization. In other words, the server system determines total transaction cost for each interbank network and identifies the interbank network which has the lowest transaction cost, thereby reducing transaction costs for the acquirer. The server system is configured to select that interbank network for transaction routing for the acquirer for the particular payment transaction type. Further, upon determining the optimal interbank network, the server system may route the future payment transaction of the particular transaction type to the acquirer in real-time through the predicted optimal interbank network.”)
In regards to claim 11,
11. (Currently amended) A system, comprising:
one or more sources of interchange data;
a merchant transaction system;
an eligibility-based interchange model computer program executed by a computer processor that is configured to ingest the interchange data from the one or more sources of interchange data, to generate an eligibility-based model using the ingested interchange data, and to monitor the one or more sources of interchange data for updates to the interchange data; and
(See Kumar, para. [0036]: “The server system is configured to train an interchange prediction model based at least on interchange rate rules of the plurality of interbank networks. The interchange rate rules define what interchange cost would be charged by the plurality of interbank networks for the payment transactions. The server system is configured to predict a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of the plurality of interbank networks based, at least in part, on the interchange prediction model.”)
(See Kumar, para. [0076]: “In one embodiment, the processor 206 is configured to store discount factors of the plurality of interbank networks in the database 204, which may updated by the interbank networks in a timely manner.”)
(See Kumar, para. [0105]: “At 430, the server system 110 determines static, or fixed interchange costs, incurring to the acquirer 108 for different types of future payment transactions while routing through eligible interbank networks. In one example, for credit card transactions, the static interchange cost is $0.75 as defined by the issuer 106. The determination is performed using the interchange prediction model which is trained using the historical transaction data and interchange rate rules associated with the plurality of interbank networks. The interchange rate rules define what interchange cost that would be applied for each payment transaction type. In one embodiment, the fixed interchange cost is calculated based on the payment transaction type, merchant category, payment card type, and a payment transaction amount.”)
an eligibility engine computer program executed by a downstream system that is configured to receive a plurality of transaction records for a plurality of transactions for a merchant,
(See Kumar, para. [0102]: “At 415, the server system 110 receives historical transaction data associated with the acquirer server 108. The historical transaction data may include types of different payment transactions processed by the acquirer server 108 in past time.”)
each of the plurality of transaction records associated with an actual interchange cost determined using a first interchange program that is deployed to the merchant transaction system, to identify,
(See Kumar, para. [0060]: “The processor 206 is operatively coupled to the communication interface 210 such that the processor 206 is capable of communicating with a remote device 216 such as, the issuer server 106, the acquirer server 108, or with any entity connected to the network 116 (e.g., as shown in FIG. 1). In one embodiment, the processor 206 is configured to access historical transaction data associated with the acquirer server 108 from an acquirer database. The historical transaction data may be related to a number of payment transactions processed by the acquirer server 108 in past time. The number of payment transactions may be associated with one or more different payment transaction types. In one embodiment, the processor 206 is configured to receive interbank network routing tables including all eligible interbank network lists and static priority routing lists from the acquirer server 108 and the issuer server 106.
(See Kumar, para. [0105]: “At 430, the server system 110 determines static, or fixed interchange costs, incurring to the acquirer 108 for different types of future payment transactions while routing through eligible interbank networks. In one example, for credit card transactions, the static interchange cost is $0.75 as defined by the issuer 106. The determination is performed using the interchange prediction model which is trained using the historical transaction data and interchange rate rules associated with the plurality of interbank networks. The interchange rate rules define what interchange cost that would be applied for each payment transaction type. In one embodiment, the fixed interchange cost is calculated based on the payment transaction type, merchant category, payment card type, and a payment transaction amount.”)
for each of the plurality of transaction records, an alternate interchange cost using the eligibility-based model, to determine, for each of the plurality of transaction records, an optimal interchange cost as a lower cost of the actual interchange cost and the alternate interchange cost,
(See Kumar, para. [0018]: “FIG. 4 is a sequence flow diagram for determining an optimal interbank network with the least transaction cost using linear optimization methods, in accordance with an embodiment of the present disclosure[.]”)
(See Kumar, para. [0099]: “FIG. 4 represents a sequence flow diagram 400 for determining an optimal interbank network with the least transaction cost using linear optimization methods, in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.”)
wherein the eligibility engine computer program is further configured to determine, for the plurality of transaction records, an optimal transaction ratio, to compare the optimal transaction ratio to a threshold, and to
automatically replace the first interchange program deployed to the merchant transaction system with a second interchange program based on … optimal transaction ratio in response to the optimal transaction ratio being below the threshold.
(See Kumar, para. [0039]: “When the number of future payment transactions routing through the interbank network exceeds a threshold value, the server system is configured to apply a merchant-specific discount to the fixed interchange cost for determining a reduced total transaction cost for the particular payment transaction type.”)
(See Kumar, para. [0076]: “In one embodiment, the processor 206 is configured to store discount factors of the plurality of interbank networks in the database 204, which may updated by the interbank networks in a timely manner.”)
(See Kumar, para. [0090]: “More specifically, the optimization engine 222 is configured to apply the merchant-specific discount over the fixed interchange cost for the future payment transactions when the number of all types of the future payment transactions routing through the Network 1 is greater than a predefined threshold value (k). In one embodiment, the optimization engine 222 is also configured to satisfy the following one or more constraints while maximizing the objective function”)
(See Kumar, para. [0097]: “In one embodiment, since the transaction forecasting engine 218, and the interchange prediction engine 220 include machine-learning models which use a learning-driven technique, it is possible to incrementally update the machine-learning models (e.g., from feedback provided by a human or computer administrator) so that it can adapt for routing the payment transaction that emerge over time. To do so, the machine-learning models incrementally update their probability distribution weights during a detection phase. In this regard, the machine-learning models can initially be trained using the training data and then later tuned/refined using feedback. Further, this feedback may be incorporated immediately in a dynamic online manner.”)
However, under a conservative interpretation of Kumar, it could be argued that Kumar does not explicitly teach the following, which are taught by Iyer:
automatically replace the first interchange program deployed to the merchant transaction system with a second interchange program based on the optimal transaction cost … .
(See Iyer, col.10, lines 33-48: “In certain embodiments, a method or analytic tool referred to as a Random Forest Regressor may be used to generate a regression tree based on the training data 310. The regression tree may be used at a later time to predict the interchange fee for a given transaction based on the feature values of that transaction. In these embodiments, the predictive model 316 may therefore comprise such a regression tree. When feature values corresponding to a particular transaction are used as inputs, the regression tree produces an output value corresponding to an estimated or predicted amount of a corresponding interchange fee for the particular transaction.
The method 300 may be repeated periodically to update the predictive model 316. For example, the predictive model 316 may be updated every week or every month, based on relatively new training data.”)
The Examiner determines that it is a matter of design choice whether the predictive model is “deployed to the merchant transaction system” or is deployed at a computer at some other server location.
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the “Methods and systems for determining an optimal interbank network for routing real-time payment transactions”, as taught by Kumar above, with “Estimating interchange fees for card payments”, as further taught by Iyer above, because both references are in the same art of determining an optimal interbank network for routing real-time payment transactions, based on interchange fees.
In regards to claim 12, it is rejected on the same grounds as the rejection of dependent claim 2.
In regards to claim 13, it is rejected on the same grounds as the rejection of dependent claim 3.
In regards to claim 14, it is rejected on the same grounds as the rejection of dependent claim 4.
In regards to claim 15, it is rejected on the same grounds as the rejection of dependent claim 5.
In regards to claim 16, it is cancelled.
In regards to claim 19, it is rejected on the same grounds as the rejection of dependent claim 10.
Response to Amendments
Re: Claim Rejections - 35 USC § 101
The 35 USC 101 rejections have been amended, as necessitated by Applicant’s amendments to the claims.
Re: Claim Rejections - 35 USC § 102/103
The 35 USC 102 rejections have been withdrawn, as necessitated by Applicant’s amendments to the claims.
New 35 USC 103 rejections have been added, as necessitated by Applicant’s amendments to the claims.
Conclusion
Applicants are invited to contact the Office to schedule an in-person interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
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.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
May 15, 2026
Prosecution Insights