DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/594,838, was filed on March 4, 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 Jan. 28, 2026 has been entered.
This Non-Final Office Action is in response to Applicant’s communication of Sept. 26, 2025.
Claims 1-4, 6-9, and 11-22 are currently pending, of which claims 1, 2, 6, 11, and 15 are independent.
In the most recent amendment, the independent claims 1, 2, 6, 11, and 15 have been amended, new claims 19-22 have been added, and claims 5 and 10 were previously cancelled.
All pending claims have been examined on the merits.
Claim Interpretation
The following is a quotation of 35 U.S.C. § 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claims 11-18 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. However, the broadest reasonable interpretation of claim elements (also commonly referred to as claim limitations) in claims 11-18 is limited by the description in the specification, because 35 U.S.C. § 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. § 112(f):
(A) the claim limitation uses the term “means”, “step”, or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means”, “step”, or the generic placeholder, is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means”, “step”, or the generic placeholder, is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step for”, or a nonce term) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C. § 112(f). The presumption that 35 U.S.C. § 112(f) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”, or a nonce term) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C. § 112(f). However, the presumption that 35 U.S.C. § 112(f) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in this application that use the word “means” (or “step for”, or a nonce term) are presumed to invoke 35 U.S.C. § 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”, or a nonce term) are presumed not to invoke 35 U.S.C. § 112(f), except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. § 112(f), because the claim limitation(s) uses a generic placeholder (a nonce term) that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitations in independent claims 11 and 15 are: “module” and “engine”. More specifically: “an intelligent routing module” and “a payment staging engine”.
Because these claim limitations are being interpreted under 35 U.S.C. § 112(f), they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
More specifically, the claimed feature “an intelligent routing module” is being interpreted according to paragraph [0024] of the specification:
[0024] The intelligent routing module 108 includes at least one processor coupled to at least one memory, where the memory stores instructions that are executed by the processor to perform the operations of the intelligent routing module 108. In at least one aspect, the intelligent routing module 108 determines payment scheduling data for each of the one or more payments. The payment scheduling data includes a determination whether the payment can be made by the requested payment date, and a preferred payment network for the payment based on data regarding the payee and the requested payment date. For example the intelligent routing module 108 can determine if a payment can be made by a requested payment date and determine a preferred payment network to be used for the payment. The intelligent routing module 108 is communicably coupled to the payment staging engine 110.
More specifically, the claimed feature “a payment staging engine” is being interpreted according to paragraph [0030] of the specification:
[0030] The payment staging engine 110 includes at least one processor coupled to at least one memory, where the memory stores instructions that are executed by the processor to perform the operations of the payment staging engine 110. The payment staging engine 110 receives the actionable payments from the intelligent routing module 108. The payment staging engine 110 transmits each payment through the preferred payment network for that payment. Each payment is transmitted by the payment staging engine 110 at the appropriate time such that the payment is received by the payee on the requested payment date. The payment staging engine 110 can transmit any number of payments to any number of payees on the same or different days.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. § 112(f), applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. § 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. § 112(f).
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-4, 6-9, and 11-18 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”.
Based on the flowchart in MPEP § 2106, Step 1 of the Alice/Mayo analysis is: “Is the claim to a process, machine, manufacture or composition of matter?”
In regards to Step 1 of the Alice/Mayo analysis, independent claims 1 and 6 are method claims, and claims 11 and 15 are apparatus claims.
For the sake of compact prosecution, we continue with the Alice/Mayo “abstract idea” analysis.
Step 2A, prong 1 of the Alice/Mayo analysis is: “Does the claim recite a law of nature, a natural phenomenon (product of nature), or an abstract idea?”
In regards to Step 2A, prongs 1 and 2 of the Alice/Mayo analysis, the abstract idea elements recited in independent claims 11 and 15 are shown in italic font. The “additional elements” and “extra solution steps” are shown in italic and underlined font (independent claims 1 and 6 are rejected on the same grounds):
In regards to independent claim 11:
11. (Currently Amended) A system comprising:
a computer-implemented payment server system of a financial institution, the payment server system comprising:
a payment scheduling system comprising a web-based interface to receive payment data;
an intelligent routing module to schedule a payment based on the payment data, wherein the intelligent routing module is communicably coupled to the payment scheduling system, and
a payment staging engine to perform the scheduled payment, wherein the payment server system is to:
receive, by the web-based interface, from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account, wherein the payment data for the one or more payments comprises, for each of the one or more payments:
a payee,
a payment amount, and
a requested payment date;
determine, by the intelligent routing module, payment scheduling data for each of the one or more payments, wherein the payment scheduling data comprises for each of the one or more payments:
a determination whether the payment can be made by the requested payment date; and
a preferred payment network for the payment based on data regarding the payee, the requested payment date;
transmit, by the intelligent routing module, actionable payments of the one or more payments based on the payment scheduling data to the payment staging engine, wherein the actionable payments comprise payments that can be made by the requested payment date;
initiate an asset transfer, by the payment staging engine, from the account of the customer of the financial institution for each of the actionable payments via the preferred payment network for the actionable payment; and
transmit, by the intelligent routing module to the web-based interface, non-actionable payments of the one or more payments, wherein non-actionable payments comprise payments that cannot be made by the requested payment date.
In regards to independent claim 15:
15. (Currently Amended) A system comprising:
a computer-implemented payment server system of a financial institution, the payment server system comprising:
a payment scheduling system comprising a web-based interface to receive payment data;
an intelligent routing module to schedule a payment based on the payment data, wherein the intelligent routing module is communicably coupled to the payment scheduling system; and
a payment staging engine to perform the scheduled payment, wherein the payment server system is to:
receive, by the web-based interface, from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account, wherein the payment data for the one or more payments comprises, for each of the one or more payments:
a payee,
a payment amount, and
a requested payment date;
determine, by the intelligent routing module, payment scheduling data for each of the one or more payments, wherein the payment scheduling data comprises for each of the one or more payments:
a determination whether the payment can be made by the requested payment date; and
a preferred payment network for the payment based on data regarding the payee, the requested payment date:
transmit, by the intelligent routing module, actionable payments of the one or more payments based on the payment scheduling data to the payment staging engine, wherein the actionable payments comprise payments that can be made by the requested payment date:
initiate an asset transfer, by the payment staging engine, from the account of the customer of the financial institution for each of the actionable payments via the preferred payment network for the actionable payment; and
display, by the web-based interface, in response to receiving the payee and the payment amount, the earliest available payment date to the customer.
More specifically, claims 1-4, 6-9, and 11-18 recite an abstract idea: “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:
“wherein the payment data for the one or more payments comprises, for each of the one or more payments: a payee; a payment amount; and a requested payment date”.
“determine … payment scheduling data for each of the one or more payments, wherein the payment scheduling data comprises for each of the one or more payments: a determination whether the payment can be made by the requested payment date; and a preferred payment network for the payment based on data regarding the payee and the requested payment date”.
“wherein the actionable payments comprise payments that can be made by the requested payment date”.
Moreover, claims 1-20 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 mathematic elements include:
“a determination whether the payment can be made by the requested payment date”.
“a preferred payment network for the payment based on data regarding the payee and the requested payment date”.
The “additional elements” include: “a computer-implemented payment server system”, “a payment scheduling system”, “an intelligent routing module”, and “a payment staging engine”.
Moreover, “additional extra-solution elements” include: “receive payment data”, “receive … from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account”, “transmit … actionable payments of the one or more payments based on the payment scheduling data to the payment staging engine”, “initiate an asset transfer ... from the account of the customer of the financial institution each of the actionable payments via the preferred payment network for the actionable payment”, “transmit … non-actionable payments of the one or more payments”, and “display … the earliest available payment date to the customer”.
Step 2A, prong 2 of the Alice/Mayo analysis is “Does the claim recite additional elements that integrate elements that integrate the judicial exception into a practical application?”
In regards to Step 2A, prong 2 of the Alice/Mayo analysis, 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-implemented payment server system”, “a payment scheduling system”, “an intelligent routing module”, and “a payment staging engine”) 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 (“receive payment data”, “receive … from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account”, “transmit … actionable payments of the one or more payments based on the payment scheduling data to the payment staging engine”, “initiate an asset transfer ... from the account of the customer of the financial institution each of the actionable payments via the preferred payment network for the actionable payment”, “transmit … non-actionable payments of the one or more payments”, and “display … the earliest available payment date to the customer”) 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.
Step 2B of the Alice/Mayo analysis is: “Does the claim recite additional elements that amount to significantly more than the judicial exception?”
In regards to Step 2B of the Alice/Mayo analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea, because:
When considering the additional elements "alone and in combination" (“a computer-implemented payment server system”, “a payment scheduling system”, “an intelligent routing module”, and “a payment staging engine”), 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 (“receive payment data”, “receive … from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account”, “transmit … actionable payments of the one or more payments based on the payment scheduling data to the payment staging engine”, “initiate an asset transfer ... from the account of the customer of the financial institution each of the actionable payments via the preferred payment network for the actionable payment”, “transmit … non-actionable payments of the one or more payments”, and “display … the earliest available payment date to the customer”), these are recognized as such by the court decisions listed in MPEP § 2106.05(d).
More specifically, in regards to the “receive” and “transmit” 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).
Moreover, in regards to “apply it”, according to MPEP § 2106.05(f)(2):
Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
In contrast, a claim that purports to improve computer capabilities or to improve an existing technology may integrate a judicial exception into a practical application or provide significantly more. McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1314-15, 120 USPQ2d 1091, 1101-02 (Fed. Cir. 2016); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36, 118 USPQ2d 1684, 1688-89 (Fed. Cir. 2016). See MPEP §§ 2106.04(d)(1) and 2106.05(a) for a discussion of improvements to the functioning of a computer or to another technology or technical field.
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”.
Independent claims 1 and 2 are rejected on the same grounds as independent claim 11, and independent claim 6 is rejected on the same grounds as independent claim 15.
All dependent claims are also rejected, because they merely further define the abstract idea, except for the following claims, which recite the following features:
In addition, claims 1-4, 6-9, and 11-18 are interpreted as "means plus function" claims. As mandated under 35 USC § 112(f), the Examiner has interpreted these claims according to the Applicant's disclosure. Paragraphs [0020], [0024], and [0030] of the specification describe a general purpose computer, which does not add “significantly more” technologically to 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.
Claims 1-4, 6-9, 11-20 and 22 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-2009/0112747-A1 to Mullen et al. (“Mullen”. Filed on Oct. 30, 2007. Published on Apr. 30, 2009) and further in view of US-9,477,737-B1 to Charyk et al. (“Charyk”. Eff. Filed on Nov. 20, 2013. Published on Oct. 25, 2016).
In regards to claim 1,
1. A method comprising:
…
wherein the payment data for the one or more payments comprise, for each of the one or more payments:
a payee;
a payment amount;
(See Kumar, para. [0004]: “Merchants are associated with point-of-sale (POS) devices for performing payment transactions using customer's payment cards (e.g., debit cards, credit cards) and other payment instruments in exchange of goods or services from the merchants. The payment transaction between the merchant and the customer involves at least an issuing bank associated with a bank account of the customer, an acquiring bank associated with the merchant, and an interchange payment network (e.g., Maestro®, Star®, Interlink®, Pulse®, etc.). In general, the issuing bank charges a static interchange fee for each transaction. The interchange fee, however, may vary from transaction to transaction, and may depend on numerous factors other than the transaction amount. Similarly, the interchange payment network also takes a fixed switching cost for each transaction.”)
determining, by an intelligent routing module, payment scheduling data for each of the one or more payments, wherein the intelligent routing module is communicably coupled to the payment scheduling system, wherein the payment scheduling data comprises for each of the one or more payments:
(See Kumar, para. [0010]: “In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical transaction data associated with an acquirer from an acquirer database and determining a plurality of payment transaction types corresponding to future payment transactions processing via the acquirer for a particular period of time based, at least in part, on the historical transaction data. The computer-implemented method includes predicting a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of a plurality of interbank networks based, at least in part, on an interchange prediction model. The computer-implemented method includes performing a linear optimization utilizing a set of metrics, to make a decision whether to apply a merchant-specific discount to a particular payment transaction type, or not. The set of metrics includes comprising a total transaction cost for each payment transaction type, a discount factor associated with the interbank network, and a number of future payment transactions routing through the interbank network. Further, the computer-implemented method includes 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. [0053]: “In one embodiment, the server system 110 is configured to perform one or more of the operations described herein. The server system 110 is configured to perform dynamic routing of payment transactions initiated from the acquirer server 108 through an interbank network with the lowest interchange rate. In one embodiment, the server system 110 performs a dynamic optimization utilizing a set of relevant features that can effect transaction interchange rates and then determines which interbank network should be selected for the payment transaction based on the set of relevant features. More particularly, the server system 110 is configured to determine payment transaction types of future payment transactions originated from the acquirer server 108 and identify an interbank network with the lowest interchange rate for a certain type of transaction for the acquirer server 108 based on static and dynamic interchange rate rules.”)
a preferred payment network for the payment, wherein the intelligent routing module selects the preferred payment network from a plurality of potential payment networks based on a combined evaluation of the payment data and the different limitations imposed by each of the plurality of potential payment networks;
(See Kumar, para. [0010]: “In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical transaction data associated with an acquirer from an acquirer database and determining a plurality of payment transaction types corresponding to future payment transactions processing via the acquirer for a particular period of time based, at least in part, on the historical transaction data. The computer-implemented method includes predicting a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of a plurality of interbank networks based, at least in part, on an interchange prediction model. The computer-implemented method includes performing a linear optimization utilizing a set of metrics, to make a decision whether to apply a merchant-specific discount to a particular payment transaction type, or not. The set of metrics includes comprising a total transaction cost for each payment transaction type, a discount factor associated with the interbank network, and a number of future payment transactions routing through the interbank network. Further, the computer-implemented method includes 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. [0034]: “In various example embodiments, the present disclosure describes a server system that determines an optimal interbank network with a lowest transaction cost. The server system includes at least a processor and a memory. In one example, the server system is a payment gateway server. The server system is configured to access historical transaction data associated with the acquirer from an acquirer database. 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).”)
transmitting, by the intelligent routing module, actionable payments of the one or more payments based on the payment scheduling data to a payment staging engine … ; and
initiating an asset transfer, by the payment staging engine, from the account of the customer of the financial institution-for each of the actionable payments via the preferred payment network for the actionable payment.
(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.”)
However, under a conservative interpretation of Kumar, it could be argued that Kumar does not explicitly teach the italicized portions below, which are taught by Mullen:
wherein the payment data for the one or more payments comprise, for each of the one or more payments:
… a requested payment date;
a determination whether the payment can be made by the requested payment date;
wherein the actionable payments comprise payments that can be made by the requested payment date;
(See Mullen, para. [0028]: “The MMOP hub includes processing that enable buyers and sellers to set and modify rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments. The MMOP hub also enables OCTs to perform similar functions. The MMOP hub also performs processes that enable payers and payees to create and maintain manual and automated trade terms with their financial institutions (e.g. payables financing, receivables financing/discounting).”)
(See Mullen, para. [0040]: “As part of the fulfillment operations, the MMOP hub 102 can parse payment and data files based on field values, and pre-configured rules including splitting bulk payments. The MMOP hub also can facilitate calculations including accrued interest and discount rates, due dates, pre-payment adjustments, late payment penalties and interest, and loss sharing on behalf of the seller. The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values, including thresholds, limits, and least-cost routing, and also can accommodate rules-based decisioning or manual override capabilities between parties when the rules-based workflow does not meet predefined criteria.”)
(See Mullen, para. [0046]: “In the next operation, indicated as MMOP hub transaction processing 304, the MMOP hub receives incoming payment files and/or payment messages. The incoming data comprising files and/or messages are the result of the processing by the adapter layer. The MMOP operations 304 involve validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required.”)
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 “System and Method For Processing Multiple Methods of Payment”, as further taught by Mullen above, because Mullen teaches that “The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values”, wherein the pre-configured rules are “rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments”, including “validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required”, so it would be obvious to select the payment network based payment date as well as optimizing cost.
However, under a conservative interpretation of Kumar and Mullen, it could be argued that Kumar and Mullen does not explicitly teach the italicized portions below, which are taught by Charyk:
receiving, by a web-based interface of a computer-implemented payment scheduling system of a financial institution, from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account,
(See Charyk, col.1, line 57 to col. 17: “Disclosed herein are systems and methods that automatically identify updated information associated with a user in one or more remote databases (e.g., databases associated with online web services) and determine updates to me made to other remote databases based on user rules for providing such automatic updates. Thus, the systems and methods disclosed herein may allow a user to update profile information of the user at not just a single website or entity, but with multiple entities, without requiring the user to communicate with each of the entities individually. In some embodiments, the methods disclosed herein are performed by a profile update system that has existing relationships and/or communication channels with multiple entities, such as financial institutions, government institutions, retail companies, and websites, for example. Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities. Such updates may be implemented, for example, via an application programming interface (API) that the plurality of remote database (also referred to generally as “partners” or “entities” herein) have access to. For example, a change to a user's information in a first remote database may be determined via access to the first remote database through an API, and changes in the user's information that are identified may be pushed to one or more other remote databases via the API.”)
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 “System and Method For Processing Multiple Methods of Payment”, as further taught by Mullen above, because Mullen teaches that “The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values”, wherein the pre-configured rules are “rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments”, including “validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required”, so it would be obvious to select the payment network based payment date as well as optimizing cost, and
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 teachings of Kumar and Mullen the “Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules” taught by Charyk, because “ Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities”, and the Examiner interprets that this can be done with the user’s financial info as well.
In regards to claim 2,
2. A method, comprising:
…
wherein the payment data for the one or more payments comprise, for each of the one or more payments:
a payee;
a payment amount; and
(See Kumar, para. [0004]: “Merchants are associated with point-of-sale (POS) devices for performing payment transactions using customer's payment cards (e.g., debit cards, credit cards) and other payment instruments in exchange of goods or services from the merchants. The payment transaction between the merchant and the customer involves at least an issuing bank associated with a bank account of the customer, an acquiring bank associated with the merchant, and an interchange payment network (e.g., Maestro®, Star®, Interlink®, Pulse®, etc.). In general, the issuing bank charges a static interchange fee for each transaction. The interchange fee, however, may vary from transaction to transaction, and may depend on numerous factors other than the transaction amount. Similarly, the interchange payment network also takes a fixed switching cost for each transaction.”)
determining, by an intelligent routing module, payment scheduling data for each of the one or more payments, wherein the intelligent routing module is communicably coupled to the payment scheduling system, wherein the payment scheduling data comprises for each of the one or more payments:
(See Kumar, para. [0010]: “In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical transaction data associated with an acquirer from an acquirer database and determining a plurality of payment transaction types corresponding to future payment transactions processing via the acquirer for a particular period of time based, at least in part, on the historical transaction data. The computer-implemented method includes predicting a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of a plurality of interbank networks based, at least in part, on an interchange prediction model. The computer-implemented method includes performing a linear optimization utilizing a set of metrics, to make a decision whether to apply a merchant-specific discount to a particular payment transaction type, or not. The set of metrics includes comprising a total transaction cost for each payment transaction type, a discount factor associated with the interbank network, and a number of future payment transactions routing through the interbank network. Further, the computer-implemented method includes 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. [0053]: “In one embodiment, the server system 110 is configured to perform one or more of the operations described herein. The server system 110 is configured to perform dynamic routing of payment transactions initiated from the acquirer server 108 through an interbank network with the lowest interchange rate. In one embodiment, the server system 110 performs a dynamic optimization utilizing a set of relevant features that can effect transaction interchange rates and then determines which interbank network should be selected for the payment transaction based on the set of relevant features. More particularly, the server system 110 is configured to determine payment transaction types of future payment transactions originated from the acquirer server 108 and identify an interbank network with the lowest interchange rate for a certain type of transaction for the acquirer server 108 based on static and dynamic interchange rate rules.”)
a preferred payment network for the payment based on data regarding the payee and the requested payment date;
(See Kumar, para. [0010]: “In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical transaction data associated with an acquirer from an acquirer database and determining a plurality of payment transaction types corresponding to future payment transactions processing via the acquirer for a particular period of time based, at least in part, on the historical transaction data. The computer-implemented method includes predicting a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of a plurality of interbank networks based, at least in part, on an interchange prediction model. The computer-implemented method includes performing a linear optimization utilizing a set of metrics, to make a decision whether to apply a merchant-specific discount to a particular payment transaction type, or not. The set of metrics includes comprising a total transaction cost for each payment transaction type, a discount factor associated with the interbank network, and a number of future payment transactions routing through the interbank network. Further, the computer-implemented method includes 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. [0034]: “In various example embodiments, the present disclosure describes a server system that determines an optimal interbank network with a lowest transaction cost. The server system includes at least a processor and a memory. In one example, the server system is a payment gateway server. The server system is configured to access historical transaction data associated with the acquirer from an acquirer database. 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).”)
transmitting, by the intelligent routing module, actionable payments of the one or more payments based on the payment scheduling data to a payment staging engine,
initiating an asset transfer, by the payment staging engine, from the account of the customer of the financial institution for each of the actionable payments via the preferred payment network for the actionable payment; and
(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.”)
However, under a conservative interpretation of Kumar, it could be argued that Kumar does not explicitly teach the italicized portions below:
wherein the payment data for the one or more payments comprise, for each of the one or more payments:
… a requested payment date;
a determination whether the payment can be made by the requested payment date; and
wherein the actionable payments comprise payments that can be made by the requested payment date;
(See Mullen, para. [0028]: “The MMOP hub includes processing that enable buyers and sellers to set and modify rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments. The MMOP hub also enables OCTs to perform similar functions. The MMOP hub also performs processes that enable payers and payees to create and maintain manual and automated trade terms with their financial institutions (e.g. payables financing, receivables financing/discounting).”)
(See Mullen, para. [0040]: “As part of the fulfillment operations, the MMOP hub 102 can parse payment and data files based on field values, and pre-configured rules including splitting bulk payments. The MMOP hub also can facilitate calculations including accrued interest and discount rates, due dates, pre-payment adjustments, late payment penalties and interest, and loss sharing on behalf of the seller. The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values, including thresholds, limits, and least-cost routing, and also can accommodate rules-based decisioning or manual override capabilities between parties when the rules-based workflow does not meet predefined criteria.”)
(See Mullen, para. [0046]: “In the next operation, indicated as MMOP hub transaction processing 304, the MMOP hub receives incoming payment files and/or payment messages. The incoming data comprising files and/or messages are the result of the processing by the adapter layer. The MMOP operations 304 involve validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required.”)
transmitting, by the intelligent routing module to the web-based interface, non-actionable payments of the one or more payments, wherein non-actionable payments comprise payments that cannot be made by the requested payment date.
(See Mullen, para. [0040]: “As part of the fulfillment operations, the MMOP hub 102 can parse payment and data files based on field values, and pre-configured rules including splitting bulk payments. The MMOP hub also can facilitate calculations including accrued interest and discount rates, due dates, pre-payment adjustments, late payment penalties and interest, and loss sharing on behalf of the seller. The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values, including thresholds, limits, and least-cost routing, and also can accommodate rules-based decisioning or manual override capabilities between parties when the rules-based workflow does not meet predefined criteria.”)
The Examiner interprets that displaying the late payments is an obvious variation of Mullen’s disclosure of “parse payment and data files based on field values, and pre-configured rules including … late payment penalties and interest”.
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 “System and Method For Processing Multiple Methods of Payment”, as further taught by Mullen above, because Mullen teaches that “The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values”, wherein the pre-configured rules are “rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments”, including “validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required”, so it would be obvious to select the payment network based payment date as well as optimizing cost.
However, under a conservative interpretation of Kumar and Mullen, it could be argued that Kumar and Mullen does not explicitly teach the italicized portions below, which are taught by Charyk:
receiving, by a web-based interface of a computer-implemented payment scheduling system of a financial institution, from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account,
(See Charyk, col.1, line 57 to col. 17: “Disclosed herein are systems and methods that automatically identify updated information associated with a user in one or more remote databases (e.g., databases associated with online web services) and determine updates to me made to other remote databases based on user rules for providing such automatic updates. Thus, the systems and methods disclosed herein may allow a user to update profile information of the user at not just a single website or entity, but with multiple entities, without requiring the user to communicate with each of the entities individually. In some embodiments, the methods disclosed herein are performed by a profile update system that has existing relationships and/or communication channels with multiple entities, such as financial institutions, government institutions, retail companies, and websites, for example. Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities. Such updates may be implemented, for example, via an application programming interface (API) that the plurality of remote database (also referred to generally as “partners” or “entities” herein) have access to. For example, a change to a user's information in a first remote database may be determined via access to the first remote database through an API, and changes in the user's information that are identified may be pushed to one or more other remote databases via the API.”)
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 “System and Method For Processing Multiple Methods of Payment”, as further taught by Mullen above, because Mullen teaches that “The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values”, wherein the pre-configured rules are “rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments”, including “validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required”, so it would be obvious to select the payment network based payment date as well as optimizing cost, and
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 teachings of Kumar and Mullen the “Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules” taught by Charyk, because “ Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities”, and the Examiner interprets that this can be done with the user’s financial info as well.
In regards to claim 3,
3. The method of claim 2, further comprising:
receiving, by the web-based interface, updated payment data for each non-actionable payment of the one or more payments from the customer, wherein the updated payment data comprises updated payments to be made by the customer from the account;
(See Kumar, para. [0063]: “The transaction forecasting engine 218 includes a suitable logic and/or interfaces for determining a plurality of payment transaction types of future or upcoming payment transactions from the acquirer server 108 within a particular period of time (i.e., “6 months), based at least on the historical transaction data. In one example, the future payment transactions will be routed to an issuer (e.g., “Bank A”) from the acquirer (e.g., “Bank B”). In another example, the future payment transactions will be routed to one or more issuers from the acquirer 108 (e.g., “Bank B”).”)
determining, by the intelligent routing module, updated payment scheduling data based on the updated payment 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.”)
transmitting, by the intelligent routing module, actionable payments of the updated payments to the payment staging engine; and
transmitting, by the payment staging engine, payment for each of the actionable payments of the updated payments via the preferred payment network for the actionable payment of the updated payments.
(See Kumar, para. [0034]: “In various example embodiments, the present disclosure describes a server system that determines an optimal interbank network with a lowest transaction cost. The server system includes at least a processor and a memory. In one example, the server system is a payment gateway server. The server system is configured to access historical transaction data associated with the acquirer from an acquirer database. 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).”)
In regards to claim 4,
4. The method of claim 2, further comprising transmitting, by the web-based interface to the intelligent routing module, customer approval of the actionable payments of the one or more payments.
(See Charyk, col.1, line 57 to col. 17: “Disclosed herein are systems and methods that automatically identify updated information associated with a user in one or more remote databases (e.g., databases associated with online web services) and determine updates to me made to other remote databases based on user rules for providing such automatic updates. Thus, the systems and methods disclosed herein may allow a user to update profile information of the user at not just a single website or entity, but with multiple entities, without requiring the user to communicate with each of the entities individually. In some embodiments, the methods disclosed herein are performed by a profile update system that has existing relationships and/or communication channels with multiple entities, such as financial institutions, government institutions, retail companies, and websites, for example. Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities. Such updates may be implemented, for example, via an application programming interface (API) that the plurality of remote database (also referred to generally as “partners” or “entities” herein) have access to. For example, a change to a user's information in a first remote database may be determined via access to the first remote database through an API, and changes in the user's information that are identified may be pushed to one or more other remote databases via the API.”)
In regards to claim 5, it has been cancelled.
In regards to claim 6,
6. A method, comprising:
…
wherein the payment data for the one or more payments comprise, for each of the one or more payments:
a payee;
a payment amount; and
(See Kumar, para. [0004]: “Merchants are associated with point-of-sale (POS) devices for performing payment transactions using customer's payment cards (e.g., debit cards, credit cards) and other payment instruments in exchange of goods or services from the merchants. The payment transaction between the merchant and the customer involves at least an issuing bank associated with a bank account of the customer, an acquiring bank associated with the merchant, and an interchange payment network (e.g., Maestro®, Star®, Interlink®, Pulse®, etc.). In general, the issuing bank charges a static interchange fee for each transaction. The interchange fee, however, may vary from transaction to transaction, and may depend on numerous factors other than the transaction amount. Similarly, the interchange payment network also takes a fixed switching cost for each transaction.”)
determining, by an intelligent routing module, payment scheduling data for each of the one or more payments, wherein the intelligent routing module is communicably coupled to the payment scheduling system, wherein the payment scheduling data comprises for each of the one or more payments:
(See Kumar, para. [0010]: “In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical transaction data associated with an acquirer from an acquirer database and determining a plurality of payment transaction types corresponding to future payment transactions processing via the acquirer for a particular period of time based, at least in part, on the historical transaction data. The computer-implemented method includes predicting a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of a plurality of interbank networks based, at least in part, on an interchange prediction model. The computer-implemented method includes performing a linear optimization utilizing a set of metrics, to make a decision whether to apply a merchant-specific discount to a particular payment transaction type, or not. The set of metrics includes comprising a total transaction cost for each payment transaction type, a discount factor associated with the interbank network, and a number of future payment transactions routing through the interbank network. Further, the computer-implemented method includes 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. [0053]: “In one embodiment, the server system 110 is configured to perform one or more of the operations described herein. The server system 110 is configured to perform dynamic routing of payment transactions initiated from the acquirer server 108 through an interbank network with the lowest interchange rate. In one embodiment, the server system 110 performs a dynamic optimization utilizing a set of relevant features that can effect transaction interchange rates and then determines which interbank network should be selected for the payment transaction based on the set of relevant features. More particularly, the server system 110 is configured to determine payment transaction types of future payment transactions originated from the acquirer server 108 and identify an interbank network with the lowest interchange rate for a certain type of transaction for the acquirer server 108 based on static and dynamic interchange rate rules.”)
a preferred payment network for the payment based on data regarding the payee and the requested payment date;
(See Kumar, para. [0010]: “In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical transaction data associated with an acquirer from an acquirer database and determining a plurality of payment transaction types corresponding to future payment transactions processing via the acquirer for a particular period of time based, at least in part, on the historical transaction data. The computer-implemented method includes predicting a fixed interchange cost for each payment transaction type incurring to the acquirer for routing the future payment transactions through an interbank network of a plurality of interbank networks based, at least in part, on an interchange prediction model. The computer-implemented method includes performing a linear optimization utilizing a set of metrics, to make a decision whether to apply a merchant-specific discount to a particular payment transaction type, or not. The set of metrics includes comprising a total transaction cost for each payment transaction type, a discount factor associated with the interbank network, and a number of future payment transactions routing through the interbank network. Further, the computer-implemented method includes 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. [0034]: “In various example embodiments, the present disclosure describes a server system that determines an optimal interbank network with a lowest transaction cost. The server system includes at least a processor and a memory. In one example, the server system is a payment gateway server. The server system is configured to access historical transaction data associated with the acquirer from an acquirer database. 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).”)
transmitting, by the intelligent routing module, actionable payments of the one or more payments based on the payment scheduling data to a payment staging engine, wherein the actionable payments comprise payments that can be made by the requested payment date;
initiating an asset transfer, by the payment staging engine, from the account of the customer of the financial institution-for each of the actionable payments via the preferred payment network for the actionable payment; and
(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.”)
However, under a conservative interpretation of Kumar, it could be argued that Kumar does not explicitly teach the italicized portions below:
wherein the payment data for the one or more payments comprise, for each of the one or more payments:
a requested payment date;
a determination whether the payment can be made by the requested payment date; and
(See Mullen, para. [0028]: “The MMOP hub includes processing that enable buyers and sellers to set and modify rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments. The MMOP hub also enables OCTs to perform similar functions. The MMOP hub also performs processes that enable payers and payees to create and maintain manual and automated trade terms with their financial institutions (e.g. payables financing, receivables financing/discounting).”)
(See Mullen, para. [0040]: “As part of the fulfillment operations, the MMOP hub 102 can parse payment and data files based on field values, and pre-configured rules including splitting bulk payments. The MMOP hub also can facilitate calculations including accrued interest and discount rates, due dates, pre-payment adjustments, late payment penalties and interest, and loss sharing on behalf of the seller. The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values, including thresholds, limits, and least-cost routing, and also can accommodate rules-based decisioning or manual override capabilities between parties when the rules-based workflow does not meet predefined criteria.”)
(See Mullen, para. [0046]: “In the next operation, indicated as MMOP hub transaction processing 304, the MMOP hub receives incoming payment files and/or payment messages. The incoming data comprising files and/or messages are the result of the processing by the adapter layer. The MMOP operations 304 involve validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required.”)
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 “System and Method For Processing Multiple Methods of Payment”, as further taught by Mullen above, because Mullen teaches that “The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values”, wherein the pre-configured rules are “rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments”, including “validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required”, so it would be obvious to select the payment network based payment date as well as optimizing cost.
However, under a conservative interpretation of Kumar and Mullen, it could be argued that Kumar and Mullen does not explicitly teach the italicized portions below, which are taught by Charyk:
displaying, by the web-based interface, in response to receiving the payee and the payment amount, the earliest available payment date.
(See Charyk, col.10, line 45-57: “The exemplary computing system 100 may include one or more commonly available input/output (I/O) devices and interfaces 110, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces 110 include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The computing system 100 may also include one or more multimedia devices 140, such as speakers, video cards, graphics accelerators, and microphones, for example.”)
receiving, by a web-based interface of a computer-implemented payment scheduling system of a financial institution, from a customer of the financial institution that has an account with the financial institution, payment data for one or more payments to be made by the customer from the account,
(See Charyk, col.1, line 57 to col. 2, line 17: “Disclosed herein are systems and methods that automatically identify updated information associated with a user in one or more remote databases (e.g., databases associated with online web services) and determine updates to me made to other remote databases based on user rules for providing such automatic updates. Thus, the systems and methods disclosed herein may allow a user to update profile information of the user at not just a single website or entity, but with multiple entities, without requiring the user to communicate with each of the entities individually. In some embodiments, the methods disclosed herein are performed by a profile update system that has existing relationships and/or communication channels with multiple entities, such as financial institutions, government institutions, retail companies, and websites, for example. Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities. Such updates may be implemented, for example, via an application programming interface (API) that the plurality of remote database (also referred to generally as “partners” or “entities” herein) have access to. For example, a change to a user's information in a first remote database may be determined via access to the first remote database through an API, and changes in the user's information that are identified may be pushed to one or more other remote databases via the API.”)
(See Charyk, col. 2, lines 18-29: “The term “database,” as used herein, may refer to an database (e.g., RDBMS or SQL database), or may refer to any other data structure, such as, for example a comma separated values (CSV), eXtendible markup language (XML), TeXT (TXT) file, flat file, spreadsheet file, and/or any other widely used or proprietary format. In some embodiments, one or more of the databases or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.”)
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 “System and Method For Processing Multiple Methods of Payment”, as further taught by Mullen above, because Mullen teaches that “The MMOP hub also routes parsed payments and data to the appropriate interfaces based on pre-configured rules or fields values”, wherein the pre-configured rules are “rules on how payments are sent, received, and scheduled, including setting terms and conditions for such payments”, including “validation, application of business rules, scheduling of payments, and transformation and optimization of payments as required”, so it would be obvious to select the payment network based payment date as well as optimizing cost, and
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 teachings of Kumar and Mullen the “Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules” taught by Charyk, because “ Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities”, and the Examiner interprets that this can be done with the user’s financial info as well.
In regards to claim 7,
7. The method of claim 6, wherein receiving payment data for one or more payments to be made by the customer from the account comprises receiving, by the web-based interface, a file from the customer, wherein the file comprises payment data for the one or more payments.
(See Charyk, col.1, line 57 to col. 2, line 17: “Disclosed herein are systems and methods that automatically identify updated information associated with a user in one or more remote databases (e.g., databases associated with online web services) and determine updates to me made to other remote databases based on user rules for providing such automatic updates. Thus, the systems and methods disclosed herein may allow a user to update profile information of the user at not just a single website or entity, but with multiple entities, without requiring the user to communicate with each of the entities individually. In some embodiments, the methods disclosed herein are performed by a profile update system that has existing relationships and/or communication channels with multiple entities, such as financial institutions, government institutions, retail companies, and websites, for example. Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities. Such updates may be implemented, for example, via an application programming interface (API) that the plurality of remote database (also referred to generally as “partners” or “entities” herein) have access to. For example, a change to a user's information in a first remote database may be determined via access to the first remote database through an API, and changes in the user's information that are identified may be pushed to one or more other remote databases via the API.”)
(See Charyk, col. 2, lines 18-29: “The term “database,” as used herein, may refer to an database (e.g., RDBMS or SQL database), or may refer to any other data structure, such as, for example a comma separated values (CSV), eXtendible markup language (XML), TeXT (TXT) file, flat file, spreadsheet file, and/or any other widely used or proprietary format. In some embodiments, one or more of the databases or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.”)
The Examiner interprets that the claimed financial data and Charyk’s profile data are merely differences in intended use.
In regards to claim 8,
8. The method of claim 7, wherein the customer creates a template on the web-based interface, and wherein the file is uploaded with a format that matches the template.
(See Charyk, col.1, line 57 to col. 2, line 17: “Disclosed herein are systems and methods that automatically identify updated information associated with a user in one or more remote databases (e.g., databases associated with online web services) and determine updates to me made to other remote databases based on user rules for providing such automatic updates. Thus, the systems and methods disclosed herein may allow a user to update profile information of the user at not just a single website or entity, but with multiple entities, without requiring the user to communicate with each of the entities individually. In some embodiments, the methods disclosed herein are performed by a profile update system that has existing relationships and/or communication channels with multiple entities, such as financial institutions, government institutions, retail companies, and websites, for example. Accordingly, the profile update system may advantageously push any updates to the user's profile information to multiple entities with which the user has a relationship (e.g., an account) in order to implement such profile updates across the multiple entities. Such updates may be implemented, for example, via an application programming interface (API) that the plurality of remote database (also referred to generally as “partners” or “entities” herein) have access to. For example, a change to a user's information in a first remote database may be determined via access to the first remote database through an API, and changes in the user's information that are identified may be pushed to one or more other remote databases via the API.”)
(See Charyk, col. 2, lines 18-29: “The term “database,” as used herein, may refer to an database (e.g., RDBMS or SQL database), or may refer to any other data structure, such as, for example a comma separated values (CSV), eXtendible markup language (XML), TeXT (TXT) file, flat file, spreadsheet file, and/or any other widely used or proprietary format. In some embodiments, one or more of the databases or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.”)
The Examiner interprets that the claimed financial data and Charyk’s profile data are merely differences in intended use.
In regards to claim 9,
9. The method of claim 6, wherein the preferred payment network is one of a plurality of payment networks comprising real-time payment, same day automated clearing house payment, and automated clearing house payment.
(See Kumar, para. [0043]: “FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, real-time routing of financial transactions between an issuer and an acquirer in a cost-effective manner.”)
In regards to claim 10, it has been cancelled.
In regards to claim 11, it is rejected on the same grounds as claim 2.
In regards to claim 12, it is rejected as reciting duplication of parts recited in claim 2.
In regards to claim 13,
13. The system of claim 11, wherein the payment server system is further to transmit, by the web-based interface to the intelligent routing module, customer approval of the payments of the actionable payments.
(See Mullen, para. [0037]: “The next operation, approval 204, includes authentication of the transmitting entity and of the corresponding profile. In addition, approval involves transaction qualification, fraud detection, and transaction translation to ensure compatibility of data protocols and the like. For the approval and authentication functionality, the MMOP hub 102 authenticates sender based on entity profile and pre-determined criteria stored in a registry. The MMOP hub includes a user interface that supports configurable rules for document/template screening that will detect and reject missing fields or erroneous data and initiate resubmission workflow, thereby assisting the user in proper approval and authentication.”)
In regards to claim 14,
14. The system of claim 11, wherein the customer provides payment data for a payment by entering information into payment data fields in the web-based interface.
(See Charyk, col.10, line 45-57: “The exemplary computing system 100 may include one or more commonly available input/output (I/O) devices and interfaces 110, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces 110 include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The computing system 100 may also include one or more multimedia devices 140, such as speakers, video cards, graphics accelerators, and microphones, for example.”)
In regards to claim 15, it is rejected on the same grounds as claim 6.
In regards to claim 16, it is rejected on the same grounds as claim 7.
In regards to claim 17, it is rejected on the same grounds as claim 8.
In regards to claim 18, it is rejected on the same grounds as claim 9.
In regards to claim 19,
19. The method of Claim 1, further comprising:
receiving, by the payment staging engine, a protocol-level rejection message from a payment network; and
in response, automatically reversing a pending asset transfer and recrediting the payment amount to the customer account.
(See Mullen, para. [0037]: “The next operation, approval 204, includes authentication of the transmitting entity and of the corresponding profile. In addition, approval involves transaction qualification, fraud detection, and transaction translation to ensure compatibility of data protocols and the like. For the approval and authentication functionality, the MMOP hub 102 authenticates sender based on entity profile and pre-determined criteria stored in a registry. The MMOP hub includes a user interface that supports configurable rules for document/template screening that will detect and reject missing fields or erroneous data and initiate resubmission workflow, thereby assisting the user in proper approval and authentication.”)
The Examiner interprets that rejection is the opposite decision of approval.
In regards to claim 20,
20. The method of Claim 1, wherein determining the preferred payment network comprises:
comparing a submission timestamp of the payment to a network-specific cutoff time stored in memory; and
disabling selection of a payment network when the cutoff time has elapsed.
(See Mullen, para. [0037]: “The next operation, approval 204, includes authentication of the transmitting entity and of the corresponding profile. In addition, approval involves transaction qualification, fraud detection, and transaction translation to ensure compatibility of data protocols and the like. For the approval and authentication functionality, the MMOP hub 102 authenticates sender based on entity profile and pre-determined criteria stored in a registry. The MMOP hub includes a user interface that supports configurable rules for document/template screening that will detect and reject missing fields or erroneous data and initiate resubmission workflow, thereby assisting the user in proper approval and authentication.”)
The Examiner interprets that rejection or disabling a transaction is an obvious variation of approval.
In regards to claim 22,
22. The method of Claim 7, further comprising:
parsing the uploaded file using a customer-defined template specifying column ordering and data formats; and
transforming the parsed data into normalized payment records prior to transmission to the intelligent routing module.
(See Mullen, claim 1: “an adapter layer that receives an incoming data message external to the system relating to a financial transaction initiated by a payer and operates on the incoming data message to change the format of the incoming data message and produce adapted data relating to the financial transaction in a message format suitable for processing by a payment processing network”)
Response to Amendments
Re: Claim Interpretations - 35 USC § 112(f)
The 35 U.S.C. 112 interpretations have been maintained, because Applicant’s amendments to the claims have not amended the claims to address this issue, and the arguments are a repeat of those submitted on Sept. 26, 2025.
The arguments submitted on Sept. 26, 2025 refer to para. [0067] of the specification as providing a definition of the term “control circuit” (which is not recited in claims 11-18), but fails to discuss the terms “an intelligent routing module” and “a payment staging engine”, which are recited in independent claim 11. Moreover, paragraphs [0024] and [0030] do define these nonce terms of “module” and “engine”, and were cited in the original 35 USC § 112(f) interpretation.
Re: Claim Rejections - 35 USC § 101
The 35 U.S.C. 101 rejections have been amended, as necessitated by Applicant’s amendments to the claims.
Re: Claim Rejections - 35 USC § 103
New 35 U.S.C. 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
April 18, 2026
Prosecution Insights