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.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 73, 75, and 77 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 25 of copending Application No. 18/946,134 (reference application) and claim 79 and 83 of copending Application No. 18/946,386 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because they are directed to reformatting payment transaction into different format and sending the reformatted payment transaction to a payment rail for processing.
Claim 74, 76, and 78 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 82 and 84 of copending Application No. 18/946,386 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because they are directed to reformatting payment transaction into different format and sending the reformatted payment transaction to a payment rail for processing.
Claim 84, 89, and 94 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 79 of copending Application No. 18/946,386 (reference application).
Claim 85, 90, and 95 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 85 of copending Application No. 18/946,386 (reference application).
Claim 86, 91, and 86 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 26 of copending Application No. 18/946,134 (reference application).
Claim 87, 92, and 96 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 27-29 of copending Application No. 18/946,134 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because they are directed to reformatting payment transaction into different format and sending the reformatted payment transaction to a payment rail for processing.
Claim 88, 93, and 97 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 32 of copending Application No. 18/946,134 (reference application) and claim 86 of copending Application No. 18/946,386 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because they are directed to reformatting payment transaction into different format and sending the reformatted payment transaction to a payment rail for processing.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejection – 35 U.S.C. 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 73-78 and 84-97 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards processing payment transactions. The concept is related to managing transactions between human, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 73-78 and 84-97 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 73-78 and 84-97 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 73, 71, and 84-88 are directed to a process (i.e., method claims).
Claims 75, 76, and 94-97 are directed to a machine (i.e., device/system claims).
Claims 77, 78, and 89-93 are directed to a manufacture (i.e., machine-readable medium claims).
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards processing payment transactions. The concept comprises receiving a payment transaction in a first format, reformatting the payment transaction into a second format, processing the payment transaction in the second format, reformatting the payment transaction into a third format, and sending the payment transaction in the third format to a payment rail for additional processing. Processing payment transaction is a fundamental economic activity and managing human transaction activities, thus the present claims clearly fall within the Certain Method of Organizing Human Activity grouping. With regards to reformatting the payment transaction into different format, the claim language does not make it clear whether the formats are data structural formats (i.e. organizing information for machine processing, efficiency, and storage) or merely writing formats (i.e., organizing content for human readability, comprehension, and stylistic conventions). Under the broadest reasonable interpretation, reformatting payment transaction can be rearranging payment instruction from one writing format to another writing format and the data structural format remaining the same. As such, reformatting payment instruction into different formats is not necessarily related to computer technology. The performance of the claim limitations using generic computer component (i.e., a real-time payments system) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Independent claim 73 recites a real-time payments transaction system as additional element. Independent claim 75 and 77 recite a processor and a memory as additional elements. Dependent claims 74, 76, 78 and 84-97 do not recite any other additional element. The additional elements are claimed to perform basic computer functions, such as receiving payment transaction, reformatting payment transaction, processing payment transaction, and sending payment transaction. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. The present claims do not solve a problem specifically arising in the realm of computer networks. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, independent claim 73 recites a real-time payments transaction system as additional element. Independent claim 75 and 77 recite a processor and a memory as additional elements. The additional elements are claimed to perform well-understood, routine, and conventional computer functions, such as receiving payment transaction, reformatting payment transaction, processing payment transaction, and sending payment transaction. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 73-78 and 84-87, 89-92, and 94-96 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Zanzot et al. (Pub. No.: US 2010/0211499).
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; 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”).
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).
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 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) 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 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.
Conclusion
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
MAR-2026