DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application is a CON of 18/829,592 09/10/2024
18/829,592 has PRO 63/639,760 04/29/2024
18/829,592 has PRO 63/581,872 09/11/2023
Status of Claims
Claims 1-72 and 79-83 are canceled.
Claims 73-78 and 84-97 are currently pending and rejected.
Claim Rejection – 35 U.S.C. 103
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.
Claim(s) 73-78 and 84-87, 89-92, and 94-96 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zanzot et al. (Pub. No.: US 2010/0211499), in view of Reutov (Pub. No.: US 2015/0178708).
As per claim 73, Zanzot teaches a method for processing a payment transaction in a real-time payments system, comprising:
receiving the payment transaction in a first format (see paragraph 0070, “the payment request may be transformed, otherwise referred to as normalized, to a standard format to allow for processing of all different payments regardless of input channels”);
reformatting the payment transaction into a second format; processing the payment transaction by the real-time payments system in the second format (see paragraph 0015 and 0020, “transform the financial payment transaction to a normalized format prior to determining the payment routing”, normalizing payment request to a standard format is the same as the reformatting into a second format; see paragraph 0088, “the financial transaction request may be transformed to a normalized or standard format, such as International Organization for Standardization (ISO) 20022 Universal Financial Industry Message Scheme or the like”);
reformatting the payment transaction into a third format, wherein the third format is used by a payment rail for additional processing; and sending the payment transaction in the third format to a payment rail for additional processing (see paragraph 0015 and 0020, “transform the financial payment transaction to a format associated with the determined payment routing prior to providing payment to payee via the determined type” which is the same as reformatting the payment transaction into a third format; see paragraph 0051, “normalize the payment requests and subsequently transform the process payment requests to the format of the determined payment route/type”; see paragraph 0085, “the normalized and processed payment is transformed to the remittance/settlement target clearing format”; also see paragraph 0095, “If the payment transaction input request has been previously normalized to a standard format, at optional Event 1140, the payment transaction is re-formatted or otherwise transformed to a format associated with the determined payment route”).
Examiner notes however, Zanzot does not teach selecting an alternative payment rail in response to determining that the payment rail is unavailable; reformatting the payment transaction into a fourth format, wherein the fourth format is used by the alternative payment rail for additional processing; and sending payment transaction in the fourth format to the alternative payment rail for additional processing.
Reutov teaches selecting an alternative payment rail in response to determining that the payment rail is unavailable; reformatting the payment transaction into a fourth format, wherein the fourth format is used by the alternative payment rail for additional processing; and sending payment transaction in the fourth format to the alternative payment rail for additional processing (see paragraph 0062, “If the system does not receive a successful confirmation response message 709 from the third party payment processor within a threshold period of time, the payment gateway rules engine may next determine if any additional third party payment processors have been configured. If additional third party payment processors are configured 713, active rule 1100 may instruct rules engine 600 which third party payment processor 102 should be used next to process payment transaction 1900; the system 100 may use a second translation engine to translate and transform the payment transaction into a canonical format accepted by the second third party payment processor 102”; the canonical format accepted by the second third party payment processor is the same as the fourth format in the present claims).
It would have been obvious to one of ordinary skill in the art at the effective filing date to modify Zanzot with teaching from Reutov to include selecting an alternative payment rail in response to determining that the payment rail is unavailable; reformatting the payment transaction into a fourth format, wherein the fourth format is used by the alternative payment rail for additional processing; and sending payment transaction in the fourth format to the alternative payment rail for additional processing. The modification would have been obvious, because it is merely applying a known technique (i.e., reformatting transaction to an alternative format used by an alternative payment rail when the first payment rail is unavailable) to a known method (i.e., reformatting and routing payment transaction) ready to provide predictable result (i.e., allow system to function even when the first payment rail is unavailable).
As per claim 74, Zanzot teaches the second format is a different format than the first format; and the third format is a different format than the second format (see paragraph 0070, “the payment request may be transformed, otherwise referred to as normalized, to a standard format to allow for processing of all different payments regardless of input channels”; see paragraph 0085, “the normalized and processed payment is transformed to the remittance/settlement target clearing format”; here the standard format or the second format is different from the first and the third format).
Examiner notes Zanzot does not teach the fourth format is a different format than the third format.
Reutov teaches the fourth format is a different format than the third format (see paragraph 0062, “the system 100 may use a second translation engine to translate and transform the payment transaction into a canonical format accepted by the second third party payment processor 102”).
It would have been obvious to one of ordinary skill in the art at the effective filing date to modify Zanzot with teaching from Reutov to include the fourth format is a different format than the third format. The modification would have been obvious, because it is merely applying a known technique (i.e., reformatting transaction to an alternative format used by an alternative payment rail when the first payment rail is unavailable) to a known method (i.e., reformatting and routing payment transaction) ready to provide predictable result (i.e., allow system to function even when the first payment rail is unavailable).
As per claim 84, Zanzot teaches wherein the third format is a same format as the first format (see paragraph 0070, “the payment request may be transformed, otherwise referred to as normalized, to a standard format to allow for processing of all different payments regardless of input channels”; see paragraph 0085, “the normalized and processed payment is transformed to the remittance/settlement target clearing format”; the first format and the third format can be any format, as such the prior art also address the situation where the first and third formats are the same).
As per claim 85, Zanzot teaches wherein reformatting the payment transaction into the third format includes:
examining contents of the payment transaction, wherein the contents of the
payment transaction includes a transaction type; examining metadata associated with the payment transaction, wherein the metadata includes a payment rail preference (see paragraph 0009, “receiving a financial payment transaction from a payor, determining payment routing for the transaction from among more than one alternative payment type”; see paragraph 0052, “determine payment routing…based on characteristics related to the payment and/or payor, and/or payee and/or the financial institution handling the payment”; see paragraph 0059, “Other routing rules 169 may additionally define other criteria for choosing the remittance/settlement type 180. Other routing rules may be dictated by the needs of the financial institution handling the payment process, the payor and/or the payee”; also see paragraph 0012-0013, 0018-0019, 0068-0071 and 0083); and
reformatting the payment transaction to match the format of the payment rail
preference on a condition that the payment transaction is not in the format of the
payment rail preference (see paragraph 0015 and 0020, “transform the financial payment transaction to a format associated with the determined payment routing prior to providing payment to payee via the determined type” which is the same as reformatting the payment transaction into a third format; see paragraph 0051, “normalize the payment requests and subsequently transform the process payment requests to the format of the determined payment route/type”; see paragraph 0085, “the normalized and processed payment is transformed to the remittance/settlement target clearing format”; also see paragraph 0095, “If the payment transaction input request has been previously normalized to a standard format, at optional Event 1140, the payment transaction is re-formatted or otherwise transformed to a format associated with the determined payment route”).
As per claim 86, Zanzot teaches determining whether the payment rail preference matches a payment rail associated with the transaction type; and reformatting the payment transaction to match the format of the payment rail
preference on a condition that the payment rail associated with the transaction type
does not match the payment rail preference (see paragraph 0015 and 0020, “transform the financial payment transaction to a format associated with the determined payment routing prior to providing payment to payee via the determined type” which is the same as reformatting the payment transaction into a third format; see paragraph 0051, “normalize the payment requests and subsequently transform the process payment requests to the format of the determined payment route/type”; see paragraph 0085, “the normalized and processed payment is transformed to the remittance/settlement target clearing format”; also see paragraph 0095, “If the payment transaction input request has been previously normalized to a standard format, at optional Event 1140, the payment transaction is re-formatted or otherwise transformed to a format associated with the determined payment route”; also see paragraph 0013, 0019, and 0059-0060).
As per claim 87, Zanzot teaches wherein the payment rail preference includes any one of: a payment rail having a lowest cost based on the transaction type; a payment rail having a shortest completion time based on the transaction type; or a caller-preferred route (see paragraph 0007-0008 and 0017, “at least one of the routing may be associated with payment processing time requirements/limitations, payment processing cost requirements/limitations, payment processing risk/quality requirements/limitations and/or payment destination” also see paragraph 0043, 0046-0047, 0052, 0054-0061, and 0080-0082).
Claim 75 is rejected for the same reason as claim 73.
Claim 76 is rejected for the same reason as claim 74.
Claim 77 is rejected for the same reason as claim 73.
Claim 78 is rejected for the same reason as claim 74.
Claim 89 is rejected for the same reason as claim 84.
Claim 90 is rejected for the same reason as claim 85.
Claim 91 is rejected for the same reason as claim 86.
Claim 92 is rejected for the same reason as claim 87.
Claim 94 is rejected for the same reason as claim 84.
Claim 95 is rejected for the same reason as claim 85.
Claim 96 is rejected for the same reason as claim 86 and 87.
Claim(s) 88, 93, and 97 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zanzot et al. (Pub. No.: US 2010/0211499), in view of Reutov (Pub. No.: US 2015/0178708), and further in view of Lam (Pub. No.: US 2019/0378098).
As per claim 88, Zanzot teaches does not teach training a decision-type machine learning model based on previous routes for a given transaction type; and using the trained machine learning model to determine a payment rail for routing the payment transaction based on the transaction type and the payment rail preference.
Lam teaches training a decision-type machine learning model based on previous routes for a given transaction type; and using the trained machine learning model to determine a payment rail for routing the payment transaction based on the transaction type and the payment rail preference (see paragraph 0100, “implement a machine learning algorithm such as reinforcement learning that may make decisions based on the identified components in the MDP models”; see paragraph 0101, “The generation of the probability distribution may be referred to as the MDP model (or problem) generation, and may be determined from historical transaction data by training module”; see paragraph 0131, “The transaction request data may correspond to the data used in the transaction that is sent to the payment network when decision is made”; see paragraph 0132, “a routing decision (Tr) is determined from the machine learning routing model, the users (payor and/or payee preferences and the transaction request”).
It would have been obvious to one of ordinary skill in the art at the effective filing date to modify Zanzot with teaching from Lam to include training a decision-type machine learning model based on previous routes for a given transaction type; and using the trained machine learning model to determine a payment rail for routing the payment transaction based on the transaction type and the payment rail preference. The modification would have been obvious, because it is merely applying a known technique (i.e., using machine learning to make decision on payment routing) to a known method (i.e., reformatting and routing payment transaction) ready to provide predictable result (i.e., replace human with AI to speed up decision and reduce cost).
Claim 93 is rejected for the same reason as claim 88.
Claim 97 is rejected for the same reason as claim 88.
Response to Remarks
Applicant’s arguments, see Remarks, filed on 06/22/2026, with respect to double patenting and rejection under 35 U.S.C. 101 have been fully considered and are persuasive. The double patenting rejection and the rejection under 35 U.S.C. 101 have been withdrawn.
Examiner cites a new prior art, Reutov (Pub. No.: US 2015/0178708), to address the amended features. Updated rejection is provided in this Office Action.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine M Behncke can be reached at (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HAO FU/Primary Examiner, Art Unit 3695
JULY-2026
Prosecution Insights