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 .
Status of Claims
This action is in reply to the application filed on February 26, 2026.
Claim 1 was amended.
Claims 8-11 were added.
Claim(s) 1-11 are currently pending and have been examined.
This action is made Final.
Response to Arguments
Applicant argued that Examiner’s 101 rejection was improper because the amended claims are integrated into a practical application by reciting specific message-level operations that must occur in a particular dataflow. Examiner disagrees. The specific message-level operations identified by Applicant comprise features of the abstract idea, and the abstract idea cannot integrate itself into a practical application. An abstract idea requires additional limitations not included in the abstract idea to integrate the abstract idea into a practical application. Applicant’s claimed invention included a processor as an additional limitation. The processor did not integrate the abstract idea into a practical application because it was recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that Examiner’s 101 rejection was improper because the claimed invention specifies a payment-network message-processing architecture that improves interoperability between systems using different message formats. Examiner disagrees. Applicant’s payment-network message-processing architecture is an abstract methodology that manipulates data with the aid of a processor. Any improved interoperability is a feature of the abstract methodology and does not affect the abstract nature of the claimed invention as a whole. In other words, an improved upon abstract idea is still abstract. Applicant’s claimed invention lacks the structural components necessary to be a network because the processor is the only structural component claimed. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that Examiner’s 101 rejection was improper because the claim’s technical, message-format-specific interoperability pipeline provides the “something more” that goes beyond a generic computer implementation of a funding decision. Examiner disagrees. The interoperability pipeline does not add “something more” because it is not a part of the additional limitations. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that Examiner’s 101 rejection was improper because the ordered combination of filter parse/convert route parse backend response approval generate formatted authorization response is a specific interoperability mechanism that does more than implement a funding allocation concept on generic hardware. Examiner disagrees. The ordered combination referenced by Applicant is a component of the abstract idea and is not transformed from its abstract state by the additional limitation of a processor. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art fails to teach or suggest “filtering to determine eligible backend funding sources based on card enrollment and merchant participation”. Examiner disagrees. The Fourez reference teaches “filtering to determine eligible backend funding sources based on card enrollment and merchant participation” (Fourez: pgh 42). Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art fails to teach or suggest a conversion of the incoming payment request “from a payment request format to a target format compatible with identified backend funding sources using a parser”. Examiner disagrees. The Fourez reference teaches the limitation “from a payment request format to a target format compatible with identified backend funding sources using a parser” (Fourez: pgh 42). Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art fails to teach or suggest translating an authorization request from ISO 8583 (or any specified interchange format) into back-end-specific formats such as EBCDIC or JSON as part of an interoperability pipeline. Examiner disagrees. The Kumnick reference teaches translating an authorization request from ISO 8583 (or any specified interchange format) into back-end-specific formats such as EBCDIC or JSON as part of an interoperability pipeline (Kumnick: pghs 38, 41, and 80). Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art fails to teach or suggest parsing “backend response message” to obtain an approval, and returning an authorization response “in a message format corresponding to the received payment request message”. Examiner disagrees. The Martin reference teaches parsing “backend response message” to obtain an approval, and returning an authorization response “in a message format corresponding to the received payment request message” (Martin: pgh 103). Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art fails to teach or suggest iterative partial settlement with remaining-amount updates where subsequent sources are accessed to settle the remaining amount due. Examiner disagrees. The Martin reference teaches iterative partial settlement with remaining-amount updates where subsequent sources are accessed to settle the remaining amount due (Martin: pgh 103). Therefore, Examiner finds Applicant’s argument non-persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 8 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention. Claim 8 is indefinite because it relies on applicable laws and regulations (i.e. ISO 8583), which are likely to vary over time.
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.
Claim(s) 1-11 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim(s) 1-11 are directed to a system, method, or product, which are/is one of the statutory categories of invention. (Step 1: YES).
The Examiner has identified independent method claim 1 as the claim that represents the claimed invention for analysis. Claim 1 recites the following limitations:
1) receiving a payment request [from a frontend payment processor] at a merchant;
2) filtering the payment request through a request filter to determine a list of backend funding sources, including an issuing bank, based on card enrollment and merchant participation, converting the payment request from a payment request format to a target format compatible with the backend funding sources using a parser; and routing the converted payment request to selected backend funding sources through a call module;
3) determining, [by a processor,] if one or more of the backend funding sources in the list of backend funding sources have funds available to settle the payment request, wherein determining whether funds are available comprises receiving, via the call module, a backend response message and parsing the backend response message to obtain an approval; 3a) if there are one or more backend funding sources that have funds and that are not the issuing bank, determining, [by a processor,]
3ai) if the backend funding source has sufficient funds to settle the payment request, using the funds to settle the payment request and sending, by the processor, an authorization response message to the frontend payment processor in a message format corresponding to the received payment request message notifying the frontend payment processor that the payment request is complete; or
3aii) if the backend funding source does not have sufficient funds to settle the request applying the available funds to the payment request and repeating step 3; or
3b) if there are no backend funding sources that have funds and that are not the issuing bank, determining, [by a processor,]
3bi) if the issuing bank has sufficient funds to settle the payment request, and if the issuing bank has sufficient funds sending a message, [by processor,] to the frontend payment processor to notify the frontend payment processor that the payment request is complete; or
3bii) if the issuing bank does not have sufficient funds to settle the request sending a message, [by processor,] to the frontend payment processor that the payment request could not be completed; or
3c) if there are no backend funding sources that have funds available to settle the payment request sending a message, [by processor,] to the frontend payment processor that the payment request could not be completed.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity because the limitations recite fundamental economic principles or practices. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a commercial or legal interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The processor in Claim 1 is just applying generic computer components to the recited abstract limitations. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: YES. The claims recite an abstract idea)
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of a processor. The computer hardware/software is/are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, claim 1 is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, these additional elements do not change the outcome of the analysis when considered separately and as an ordered combination. Thus, claim 1 is not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-11 further define the abstract idea that is present in independent claim 1 and thus correspond to certain methods of organizing human activity and hence are abstract for the reasons presented above. Dependent claims 2-11 do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, dependent claims 2-11 are directed to an abstract idea. Thus, claim(s) 1-11 are not patent-eligible.
Claim Rejections - 35 USC § 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.
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.
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-5 and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Martin (US 2016/0314451) in view of Fourez (US 2010/0036770).
Regarding claim(s) 1:
Martin teaches:
3) determining, by a processor, if one or more of the backend funding sources in the list of backend funding sources have funds available to settle the payment request, wherein determining whether funds are available comprises receiving, via the call module, a backend response message and parsing the backend response message to obtain an approval; (Martin: pgh 103, “Processing then proceeds to decision 1006, where it is determined if the payment could be assigned among the user’s virtual budgeting accounts in accordance with their rules.”)
3a) if there are one or more backend funding sources that have funds and that are not the issuing bank, determining, by a processor, (Martin: pgh 103, “In some embodiments, rules may allow for multiple potential assignments…In such embodiments, the assignment selected among multiple feasible assignments can be determined based on the ordering of the user’s rules.”)
3ai) if the backend funding source has sufficient funds to settle the payment request, using the funds to settle the payment request and sending, by the processor, an authorization response message to the frontend payment processor in a message format corresponding to the received payment request message notifying the frontend payment processor that the payment request is complete; or (Martin: pgh 103, “If a feasible budgeting assignment exists, processing proceeds to step 1008.”; pgh 104, “At step 1008, the amount assigned to each virtual budgeting account is deducted from the remaining balance in the corresponding account.”)
3aii) if the backend funding source does not have sufficient funds to settle the request applying the available funds to the payment request and repeating step 3; or (Martin: pgh 103, “In some embodiments, spillover rules may be permitted such that, if an otherwise-feasible assignment would cause a particular budgeting category to exceed its available funds, the excess can be deducted from a spillover account.”)
3b) if there are no backend funding sources that have funds and that are not the issuing bank, determining, by a processor, 3bi) if the issuing bank has sufficient funds to settle the payment request, and if the issuing bank has sufficient funds sending a message, by processor, to the frontend payment processor to notify the frontend payment processor that the payment request is complete; or (Martin: pgh 37, “Embodiments of the invention can further allocate a single purchase among multiple payment accounts. This can be used, for example, to automatically aggregate credit limits where no single funding account has sufficient credit to fund the purchase alone.”)
3bii) if the issuing bank does not have sufficient funds to settle the request sending a message, by processor, to the frontend payment processor that the payment request could not be completed; or (Martin: pgh 108, “…a rejection is sent based on insufficient funds remaining on the payment vehicle.”)
3c) if there are no backend funding sources that have funds available to settle the payment request sending a message, by processor, to the frontend payment processor that the payment request could not be completed. (Martin: pgh 108, “In some embodiments, the lack of sufficient funds remaining on the payment vehicle will cause a hard rejection…”)
Martin does not teach, however, Fourez teaches:
1) receiving a payment request from a frontend payment processor at a merchant; (Fourez: pgh 33, “The cardholder presents the payment card to a merchant to initiate the transaction.”)
2) filtering the payment request through a request filter to determine a list of backend funding sources, including an issuing bank, based on card enrollment and merchant participation, converting the payment request from a payment request format to a target format compatible with the backend funding sources using a parser; and routing the converted payment request to selected backend funding sources through a call module; (Fourez: pgh 42, “…wherein said managing platform includes a hierarchal list of at least one fallback funding source for use when any of said at least two funding sources have insufficient funds.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin to include the teachings of Fourez because it would be advantageous to provide a single payment card that provides the user the ability to choose multiple funding sources (pgh 8).
Regarding claim(s) 2:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Martin further teaches:
determining whether the merchant accepts any of the backend funding sources and, if it does, adding only those backend funding sources that the merchant accepts to the list of funding sources. (Martin: pgh 80, “Once the merchant has been identified, the applicable rewards programs may be determined…the rewards programs applicable to the purchase may depend on the merchant…”)
Regarding claim(s) 3:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 2. Martin further teaches:
wherein each backend funding source in the list of funding sources has a priority assigned to it and wherein step 3 of the method uses the priority to determine an order in which the backend funding sources are accessed. (Martin: pgh 64, “Using buttons, the user can configure which rule is applied first…According to these rules, payments would be allocated first to the funding accounts that offered cash rewards, in decreasing order of reward amount…”)
Regarding claim(s) 4:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Martin further teaches:
determining whether the payment request is eligible for any rewards and, if it is, recording the rewards with the backend funding source that is appropriate for the rewards. (Martin: pgh 64, “Thus a user might configure a first rule to maximize cash rewards…”)
Regarding claim(s) 5:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Fourez further teaches:
wherein step 1 includes a request filter that accepts the payment request and determines which backend funding sources may be available for the payment request. (Fourez: pgh 42, “…designating a set of pre-defined routing rules for funding transactions made with the payment card from said first and second funding sources…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin to include the teachings of Fourez because it would be advantageous to provide a single payment card that provides the user the ability to choose multiple funding sources (pgh 8).
Regarding claim(s) 9:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Fourez further teaches:
wherein routing the converted payment request to selected backend funding sources through a call module further includes transmitting, via a TCP/IP socket server interface, the converted payment request to the selected backend funding source. (Fourez: pgh 7, “…none of the issuer processors support multiple funding sources at the network level across separate banks or financial institutions.”; pgh 41, “Advantages of the present invention include the ability to support multiple funding sources across multiple or different banks and financial institutions and support for funding a single transaction from multiple funding sources.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin to include the teachings of Fourez because it would be advantageous to provide a single payment card that provides the user the ability to choose multiple funding sources (pgh 8).
Regarding claim(s) 10:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Martin further teaches:
wherein step 3aii further includes: upon receiving a response indicating insufficient funds from a backend funding source, applying the available funds, updating a remaining amount due, and continuing the iterating through the list of funding sources for the remaining amount due. (Martin: pgh 103, “In some embodiments, spillover rules may be permitted such that, if an otherwise-feasible assignment would cause a particular budgeting category to exceed its available funds, the excess can be deducted from a spillover account.”)
Regarding claim(s) 11:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Martin further teaches:
displaying, on a graphical user interface of a mobile device application, a funding-source management screen that presents a user-selectable list of a plurality of backend funding sources associated with a payment card, wherein the plurality of backend funding sources includes at least one reward-program funding source and at least one issuing bank funding source; (Martin: Fig. 11, item 1102; pgh 113, “Account user interface 1102 may further provide user 902 with several options for managing the funds in the prepaid account.”)
Martin does not teach, however, Fourez teaches:
receiving, via the graphical user interface, user input that assigns a relative priority among the plurality of backend funding sources to define an ordered priority list; storing the ordered priority list; and, (Fourez: pgh 19, “The pre-defined rules may be changed via a dedicated consumer interface, which includes but is not limited to a web interface, a voice interface, or a mobile interface.”; pgh 23, “Then, the cardholder designates a set of pre-defined rules for selecting a preferred funding source, which may also be a first funding source or primary account, and at least one alternate funding source, which may also be a second funding source or a secondary account.”)
for a subsequently received payment request, accessing the plurality of backend funding sources in an order determined by the ordered priority list such that a highest-priority backend funding source is accessed before a lower-priority backend funding source to settle at least a portion of the payment request. (Fourez: pgh 19, “Once the pre-defined rules are changed, the pre-defined rules will be applied to each subsequent transaction until the consumer changes the pre-defined rules.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin to include the teachings of Fourez because it would be advantageous to provide a single payment card that provides the user the ability to choose multiple funding sources (pgh 8).
Claims 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over Martin/Fourez in view of Kumnick (US 2012/0221468 A1)
Regarding claim(s) 6:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 4. Kumnick further teaches:
wherein in step 1 the request filter passes the payment request to a parser that is configured to convert the payment request into a language that the backend funding sources accept. (Kumnick: pgh 136, “Processing the authorization request message can include determining whether the authorization request message is to be formatted into a different file format prior to transmission out to an issuer computer…”; pgh 288, “The data conversion module…converts the authorization request message from one format to another format.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin/Fourez to include the teachings of Kumnick because there is a need to simplify existing payment processing systems and provide for enhanced functionality (Kumnick: pgh 5).
Regarding claim(s) 7:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 5. Kumnick further teaches:
wherein in step 1 the parser sends the converted payment request to a call module that sends the payment request to the backend founding sources. (Kumnick: pgh 58, “…the server computer can parse the authorization request message to determine whether to route the message to an issuer or to another payment network or debit gateway.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin/Fourez to include the teachings of Kumnick because there is a need to simplify existing payment processing systems and provide for enhanced functionality (Kumnick: pgh 5).
Regarding claim(s) 8:
The combination of Martin/Fourez, as shown in the rejection above, discloses the limitations of claim 1. Kumnick further teaches:
wherein converting the payment request from a payment request format to a target format compatible with identified backend funding sources using a parser includes parsing, by the parser, an incoming payment request message in an ISO 8583 format and converting the incoming payment request message into a target format selected from EBCDIC and JSON compatible with a selected backend funding source, and (Kumnick: pgh 80, “The data conversion module…can convert authorization request messages from one format to another format.”; pgh 38, “An authorization request message may comply with ISO 8583, which is a standard for systems that exchange electronic transactions made by consumers using payment devices.”; pgh 41, “However, embodiments of the invention are not restricted to use of XML and may also be implemented using any other markup language, such as YAML, JSON, etc…”)
routing, by a call module, the converted payment request to the selected backend funding source. (Kumnick: pgh 58, “…the server computer can parse the authorization request message to determine whether to route the message to an issuer or to another payment network or debit gateway.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Martin/Fourez to include the teachings of Kumnick because there is a need to simplify existing payment processing systems and provide for enhanced functionality (Kumnick: pgh 5).
Conclusion
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure. Chuang et al (US 8,595,133) discloses a system and method for presenting alternative funding options at substantially the same time as a transaction is being processed at a point of sale.
THIS ACTION IS MADE FINAL. 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 JOHN O PRESTON whose telephone number is (571)270-3918. The examiner can normally be reached 12:00 pm - 8:00 pm.
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, MICHAEL ANDERSON can be reached on 571-270-0508. 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.
/JOHN O PRESTON/Examiner, Art Unit 3693 May 15, 2026
/ELIZABETH H ROSEN/Primary Examiner, Art Unit 3693
Prosecution Insights