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 June 2, 2025.
Claim(s) 1-36 are currently pending and have been examined.
This action is made Non-Final.
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-36 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-9 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 system claim 1 as the claim that represents the claimed invention for analysis. Claim 1 recites the following limitations:
[A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising:]
providing, [by a bridging system of a bridging service provider], an issuer list comprising one or more available issuers [to a user device of a payer]; and
receiving, [by the bridging system], a delivery request [from the issuer system] of the selected issuer selected from the one or more available issuers;
wherein: the delivery request is generated based on a checkout URL;
the delivery request requests a delivery transaction [to the acquirer system] of the acquirer; and
the selected issuer is different from the acquirer.
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 fundamental economic principle or practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The bridging system, user device, issuer system, and acquirer system in Claim 1 are 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 bridging system, a user device, an issuer system, and an acquirer system. 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(s) 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(s) 1 is not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-9 further define the abstract idea that is present in their respective independent claim(s) 1 and thus correspond to certain methods of organizing human activity and hence are abstract for the reasons presented above. Dependent claims 2-9 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-9 are directed to an abstract idea. Thus, claim(s) 1-9 are not patent-eligible.
Claim(s) 10-22 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 system claim 10 as the claim that represents the claimed invention for analysis. Claim 10 recites the following limitations:
[a method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising:]
receiving, [by a user device of a payer], an issuer list comprising one or more available issuers; and
providing, [by the user device of the payer], a delivery request [to the issuer system] of the selected issuer selected from the one or more available issuers;
wherein: the delivery request is generated based on a checkout URL;
the delivery request requests a delivery transaction [to the acquirer system] of the acquirer; and
the selected issuer is different from the acquirer.
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 fundamental economic principle or practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The user device, issuer system, and acquirer system in Claim 10 are 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 user device, an issuer system, and an acquirer system. 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(s) 10 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(s) 10 is not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 11-22 further define the abstract idea that is present in their respective independent claim(s) 10 and thus correspond to certain methods of organizing human activity and hence are abstract for the reasons presented above. Dependent claims 11-22 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 11-22 are directed to an abstract idea. Thus, claim(s) 10-22 are not patent-eligible.
Claim(s) 23-26 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 system claim 23 as the claim that represents the claimed invention for analysis. Claim 23 recites the following limitations:
[a method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising:]
receiving, [by the issuer system] of the selected issuer, a delivery request [from a user device] of a payer; and
providing, [by the issuer system] of the selected issuer, the delivery request [to a bridging system] of a bridging service provider;
wherein: the delivery request is generated based on a checkout URL;
the delivery request requests a delivery transaction [to the acquirer system] of the acquirer; and
the selected issuer is different from the acquirer.
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 fundamental economic principle or practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The issuer system, user device, bridging system, and acquirer system in Claim 23 are 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 an issuer system, a user device, a bridging system, and an acquirer system. 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(s) 23 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(s) 23 is not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 24-26 further define the abstract idea that is present in their respective independent claim(s) 23 and thus correspond to certain methods of organizing human activity and hence are abstract for the reasons presented above. Dependent claims 24-26 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 24-26 are directed to an abstract idea. Thus, claim(s) 23-26 are not patent-eligible.
Claim(s) 27-36 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 claim 27 as the claim that represents the claimed invention for analysis and is similar to independent Claim 32. Claim 27 recites the following limitations:
[a method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising:]
receiving, [by an acquirer system] of the acquirer, a list request [from a user device] of a payer;
redirecting, [by the acquirer system, the user device] to a bridging system of a bridging service provider, so that [the bridging system] provides providing an issuer list comprising one or more available issuers [to the user device]; and
receiving, [by the acquirer system], a delivery request [from an issuer system] of the selected issuer [via the bridging system], the selected issuer is selected from the one or more available issuers;
wherein: the delivery request is generated based on a checkout URL;
the delivery request requests a transaction [to the acquirer system] of the acquirer; and
the selected issuer is different from the acquirer.
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 fundamental economic principle or practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The acquirer system, user device, bridging system, and issuer system in Claim 27 are 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. Claim 32 is also abstract for similar reasons. (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 an acquirer system, a user device, a bridging system, and an issuer system. 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(s) 27 and 32 are 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(s) 27 and 32 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 28-31 and 33-36 further define the abstract idea that is present in their respective independent claim(s) 27 and 32 and thus correspond to certain methods of organizing human activity and hence are abstract for the reasons presented above. Dependent claims 28-31 and 33-36 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 28-31 and 33-36 are directed to an abstract idea. Thus, claim(s) 27-36 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-36 are rejected under 35 U.S.C. 103 as being unpatentable over Malhotra (US 2017/0364878) in view of Kohli (US 2022/0012698).
Regarding claim(s) 1:
Malhotra teaches:
A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: (Malhotra: pgh 19, “…the customer device may engage in an online shopping session with an e-commerce website hosted by the merchant device.”; pgh 20, “The acquirer FI computer may then route the authorization request message via a card network to an issuer FI computer.”; pgh 72, “When the user engages in checkout from such an interface…”)
the delivery request requests a delivery transaction to the acquirer system of the acquirer; and (Malhotra: pgh 20, “…the authorization response message generated by the payment issuer server computer is routed back to the merchant device via the card network and the acquirer FI computer.”)
Malhotra does not teach, however, Kohli teaches:
providing, by a bridging system of a bridging service provider, an issuer list comprising one or more available issuers to a user device of a payer; and (Kohli: pgh 50, “A payment rule may refer to a rule that specifies whether or not a given payment system permits providing payments to other payment systems. In some examples, a payment rule may include a whitelist payment rule or a blacklist payment rule.”; pgh 87, “The payment network may forward the pull payment request to an issuer…”; pgh 97, “…then the payment network may transmit the payment instruction to the payment network via a bridged connection…”)
receiving, by the bridging system, a delivery request from the issuer system of the selected issuer selected from the one or more available issuers; (Kohli: pgh 124, “The method may further include transmitting, via the payment network, a payment request to be funded from the payment card number to the payment network merchant account identifier…”)
wherein: the delivery request is generated based on a checkout URL; (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
the selected issuer is different from the acquirer. (Kohli: pgh 33, “The sender FI may therefore fund a payment from the sender.”; pgh 34, “…the recipient FI may be enrolled as an acquirer that interfaces with the payment network…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 2:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 1. Malhotra further teaches:
before providing the issuer list comprising one or more available issuers further comprising: receiving, by the bridging system, a list request from the user device of the payer. (Malhotra: pgh 92, “…in a set-up, configuration or re-configuration mode for the gateway computer, one or more business rules may be stored in the gateway computer. As will be seen, the business rules may guide the gateway computer in selecting between the payment card account system and the EFT system for further routing of transaction messages received by the gateway computer.”)
Regarding claim(s) 3:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 2. Malhotra further teaches:
wherein the list request is redirected from the acquirer system before receiving by the bridging system. (Malhotra: pgh 65, “The processing at block 608 may include the acquirer/originator PSP 406 receiving and retransmitting a transaction request message (e.g., by routing the message to the gateway computer 402).
Regarding claim(s) 4:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 1. Kohli further teaches:
wherein the user device is a portable device, and the checkout URL is configured to open issuer apps of the one or more available issuers installed on the portable device. (Kohli: pgh 36, “The user device may include a device such as a smartphone, a tablet device, a wearable device, a personal computer, and/or other device…”; pgh 55, “…the wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 5:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 2. Kohli further teaches:
wherein the checkout URL is configured to direct the user device to the bridging system. (Kohli: pgh 55, “…wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data to match the parsed URL with a RUL of an encoding scheme in the mapping…”; pgh 58, “The wallet connector system may mediate the transaction to provide interoperability between a payment system of a sender and a payment system of a recipient.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 6:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 5. Kohli further teaches:
wherein the checkout URL is embedded in a QR code of the bridging service provider. (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 7:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 3. Kohli further teaches:
wherein the checkout URL is configured to direct the user device to the acquirer system. (Kohli: pgh 55, “…wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data to match the parsed URL with a RUL of an encoding scheme in the mapping…”; pgh 58, “The wallet connector system may mediate the transaction to provide interoperability between a payment system of a sender and a payment system of a recipient.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 8:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 7. Kohli further teaches:
wherein the checkout URL is embedded in a QR code of the acquirer. (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 9:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 1. Malhotra further teaches:
receiving, by the bridging system, a payment confirmation confirming the payment request from the issuer system; and (Malhotra: pgh 23, “The payment card account system communications among the merchants, acquirers, card network and/or issuers may conform to a known standard such as ISO 8583.” ISO 8583 includes payment confirmation.)
providing, by the bridging system, the payment confirmation to the acquirer system. (Malhotra: pgh 73, “The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message.”)
Malhotra does not teach, however, Kohli teaches:
after receiving the delivery request from the issuer system further comprising: providing, by the bridging system, the delivery request to the acquirer system; (Kohli: pgh 47, “In some examples, the payment network may operate a push payment platform in which payments may be pushed from senders to recipients over multiple delivery channels…”)
receiving, by the bridging system, a payment request from the acquirer system; (Kohli: pgh 124, “The method may further include transmitting, via the payment network, a payment request to be funded from the payment card number to the payment network merchant account identifier…”)
providing, by the bridging system, the payment request to the issuer system; (Kohli: pgh 87, “The payment network may forward the pull payment request to an issuer, which may check the funds of and debit a sender account…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 10:
Malhotra teaches:
a method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: (Malhotra: pgh 19, “…the customer device may engage in an online shopping session with an e-commerce website hosted by the merchant device.”; pgh 20, “The acquirer FI computer may then route the authorization request message via a card network to an issuer FI computer.”; pgh 72, “When the user engages in checkout from such an interface…”)
the delivery request requests a delivery transaction to the acquirer system of the acquirer; and (Malhotra: pgh 20, “…the authorization response message generated by the payment issuer server computer is routed back to the merchant device via the card network and the acquirer FI computer.”)
Malhotra does not teach, however, Kohli teaches:
receiving, by a user device of a payer, an issuer list comprising one or more available issuers; and (Kohli: pgh 50, “A payment rule may refer to a rule that specifies whether or not a given payment system permits providing payments to other payment systems. In some examples, a payment rule may include a whitelist payment rule or a blacklist payment rule.”; pgh 87, “The payment network may forward the pull payment request to an issuer…”; pgh 97, “…then the payment network may transmit the payment instruction to the payment network via a bridged connection…”)
providing, by the user device of the payer, a delivery request to the issuer system of the selected issuer selected from the one or more available issuers; (Kohli: pgh 124, “The method may further include transmitting, via the payment network, a payment request to be funded from the payment card number to the payment network merchant account identifier…”)
wherein: the delivery request is generated based on a checkout URL; (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
the selected issuer is different from the acquirer. (Kohli: pgh 33, “The sender FI may therefore fund a payment from the sender.”; pgh 34, “…the recipient FI may be enrolled as an acquirer that interfaces with the payment network…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 11:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 10. Malhotra further teaches:
before receiving the issuer list comprising one or more available issuers further comprising: providing a list request by the user device. (Malhotra: pgh 92, “…in a set-up, configuration or re-configuration mode for the gateway computer, one or more business rules may be stored in the gateway computer. As will be seen, the business rules may guide the gateway computer in selecting between the payment card account system and the EFT system for further routing of transaction messages received by the gateway computer.”)
Regarding claim(s) 12:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 10. Kohli further teaches:
wherein the user device is a portable device, and the checkout URL is configured to open issuer apps of the one or more available issuers installed on the portable device. (Kohli: pgh 36, “The user device may include a device such as a smartphone, a tablet device, a wearable device, a personal computer, and/or other device…”; pgh 55, “…the wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 13:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 11. Malhotra further teaches:
wherein the list request is provided to the acquirer system. wherein the list request is redirected from the acquirer system before receiving by the bridging system. (Malhotra: pgh 65, “The processing at block 608 may include the acquirer/originator PSP 406 receiving and retransmitting a transaction request message (e.g., by routing the message to the gateway computer 402).
Regarding claim(s) 14:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 13. Malhotra further teaches:
wherein the issuer list is received from the acquirer system. (Malhotra: pgh 65, “The processing at block 608 may include the acquirer/originator PSP 406 receiving and retransmitting a transaction request message (e.g., by routing the message to the gateway computer 402).
Regarding claim(s) 15:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 13. Kohli further teaches:
wherein the issuer list is received from a bridging system of a bridging service provider. (Kohli: pgh 50, “A payment rule may refer to a rule that specifies whether or not a given payment system permits providing payments to other payment systems. In some examples, a payment rule may include a whitelist payment rule or a blacklist payment rule.”; pgh 87, “The payment network may forward the pull payment request to an issuer…”; pgh 97, “…then the payment network may transmit the payment instruction to the payment network via a bridged connection…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 16:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 11. Kohli further teaches:
wherein the list request is provided to a bridging system of a bridging service provider, and the issuer list is received from the bridging system. (Kohli: pgh 50, “A payment rule may refer to a rule that specifies whether or not a given payment system permits providing payments to other payment systems. In some examples, a payment rule may include a whitelist payment rule or a blacklist payment rule.”; pgh 87, “The payment network may forward the pull payment request to an issuer…”; pgh 97, “…then the payment network may transmit the payment instruction to the payment network via a bridged connection…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 17:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 15. Malhotra further teaches:
wherein the list request is redirected from the acquirer system to the bridging system. (Malhotra: pgh 65, “The processing at block 608 may include the acquirer/originator PSP 406 receiving and retransmitting a transaction request message (e.g., by routing the message to the gateway computer 402).
Regarding claim(s) 18:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 16. Kohli further teaches:
wherein the checkout URL is configured to direct the user device to the bridging system. (Kohli: pgh 55, “…wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data to match the parsed URL with a RUL of an encoding scheme in the mapping…”; pgh 58, “The wallet connector system may mediate the transaction to provide interoperability between a payment system of a sender and a payment system of a recipient.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 19:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 18. Kohli further teaches:
wherein the checkout URL is embedded in a QR code of the bridging service provider. (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 20:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 13. Kohli further teaches:
wherein the checkout URL is configured to direct the user device to the acquirer system. (Kohli: pgh 55, “…wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data to match the parsed URL with a RUL of an encoding scheme in the mapping…”; pgh 58, “The wallet connector system may mediate the transaction to provide interoperability between a payment system of a sender and a payment system of a recipient.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 21:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 20. Kohli further teaches:
wherein the checkout URL is embedded in a QR code of the acquirer. (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 22:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 10. Malhotra further teaches:
providing, by the user device, a payment confirmation confirming the payment request to the issuer system. (Malhotra: pgh 23, “The payment card account system communications among the merchants, acquirers, card network and/or issuers may conform to a known standard such as ISO 8583.” ISO 8583 includes payment confirmation.)
Malhotra does not teach, however, Kohli teaches:
after providing the delivery request to the issuer system further comprising: receiving, by the user device, a payment request from the issuer system; and (Kohli: pgh 26, “The wallet server or sender FI may debit the sender’s closed loop user account in the first closed loop payment system…”; pgh 37, “In some examples, the user device may include a digital wallet.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 23:
Malhotra teaches:
a method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: (Malhotra: pgh 19, “…the customer device may engage in an online shopping session with an e-commerce website hosted by the merchant device.”; pgh 20, “The acquirer FI computer may then route the authorization request message via a card network to an issuer FI computer.”; pgh 72, “When the user engages in checkout from such an interface…”)
the delivery request requests a delivery transaction to the acquirer system of the acquirer; and (Malhotra: pgh 20, “…the authorization response message generated by the payment issuer server computer is routed back to the merchant device via the card network and the acquirer FI computer.”)
Malhotra does not teach, however, Kohli teaches:
receiving, by the issuer system of the selected issuer, a delivery request from a user device of a payer; and (Kohli: pgh 124, “The method may further include transmitting, via the payment network, a payment request to be funded from the payment card number to the payment network merchant account identifier…”)
providing, by the issuer system of the selected issuer, the delivery request to a bridging system of a bridging service provider; (Kohli: pgh 97, “…then the payment network may transmit the payment instruction to the payment network via a bridged connection…”)
wherein: the delivery request is generated based on a checkout URL; (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
the selected issuer is different from the acquirer. (Kohli: pgh 33, “The sender FI may therefore fund a payment from the sender.”; pgh 34, “…the recipient FI may be enrolled as an acquirer that interfaces with the payment network…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 24:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 23. Kohli further teaches:
wherein the issuer system does not resolve a payment request embedded in the checkout URL. (Kohli: pgh 20, “The wallet server may not recognize the encoded data because the encoded data may use an encoding scheme of the second closed loop payment system…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 25:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 24. Kohli further teaches:
wherein the checkout URL is resolved by the bridging system or the acquirer system. (Kohli: pgh 23, “…the wallet connector system may access and apply payment rules to ensure that the first closed loop payment system has approved sending payments to the second closed loop payment system and/or apply acceptance rules to ensure that the second closed loop payment platform has approved receiving payments from the first closed loop payment system.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 26:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claim 23. Malhotra further teaches:
providing, by the issuer system, the payment confirmation to the bridging system. (Malhotra: pgh 73, “The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message.”)
receiving, by the issuer system, a payment confirmation confirming the payment request from the user device; and (Malhotra: pgh 23, “The payment card account system communications among the merchants, acquirers, card network and/or issuers may conform to a known standard such as ISO 8583.” ISO 8583 includes payment confirmation.)
Malhotra does not teach, however, Kohli teaches:
after providing the delivery request to the bridging system further comprising: receiving, by the issuer system, a payment request from the bridging system; (Kohli: pgh 87, “The payment network may forward the pull payment request to an issuer, which may check the funds of and debit a sender account…”)
providing, by the issuer system, the payment request to the user device; (Kohli: pgh 26, “The wallet server or sender FI may debit the sender’s closed loop user account in the first closed loop payment system…”; pgh 37, “In some examples, the user device may include a digital wallet.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 27 and 32:
Malhotra teaches:
A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: (Malhotra: pgh 19, “…the customer device may engage in an online shopping session with an e-commerce website hosted by the merchant device.”; pgh 20, “The acquirer FI computer may then route the authorization request message via a card network to an issuer FI computer.”; pgh 72, “When the user engages in checkout from such an interface…”)
redirecting, by the acquirer system, the user device to a bridging system of a bridging service provider… (Malhotra: pgh 18, “The payment card system includes a customer device such as a magnetic stripe card…or a payment-enabled mobile device (such as a Smartphone that includes a payment application)…”; pgh 19, “…the customer device may be a personal computer or a mobile device running mobile browser software or the like.”)
the delivery request requests a transaction to the acquirer system of the acquirer; and (Malhotra: pgh 20, “…the authorization response message generated by the payment issuer server computer is routed back to the merchant device via the card network and the acquirer FI computer.”)
Malhotra does not teach, however, Kohli teaches:
…so that the bridging system provides providing an issuer list comprising one or more available issuers to the user device; and (Kohli: pgh 50, “A payment rule may refer to a rule that specifies whether or not a given payment system permits providing payments to other payment systems. In some examples, a payment rule may include a whitelist payment rule or a blacklist payment rule…”)
receiving, by an acquirer system of the acquirer, a list request from a user device of a payer; (Kohli: pgh 50, “A payment rule may refer to a rule that specifies whether or not a given payment system permits providing payments to other payment systems. In some examples, a payment rule may include a whitelist payment rule or a blacklist payment rule.”; pgh 87, “The payment network may forward the pull payment request to an issuer…”; pgh 97, “…then the payment network may transmit the payment instruction to the payment network via a bridged connection…”)
receiving, by the acquirer system, a delivery request from an issuer system of the selected issuer via the bridging system, the selected issuer is selected from the one or more available issuers; (Kohli: pgh 124, “The method may further include transmitting, via the payment network, a payment request to be funded from the payment card number to the payment network merchant account identifier…”)
wherein: the delivery request is generated based on a checkout URL; (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
the selected issuer is different from the acquirer. (Kohli: pgh 33, “The sender FI may therefore fund a payment from the sender.”; pgh 34, “…the recipient FI may be enrolled as an acquirer that interfaces with the payment network…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 28 and 33:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claims 27 and 32, respectively. Kohli further teaches:
wherein the user device is a portable device, and the checkout URL is configured to open issuer apps of the one or more available issuers installed on the portable device. (Kohli: pgh 36, “The user device may include a device such as a smartphone, a tablet device, a wearable device, a personal computer, and/or other device…”; pgh 55, “…the wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 29-34:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claims 27 and 32, respectively. Kohli further teaches:
wherein the checkout URL directs the user device to the acquirer system. (Kohli: pgh 55, “…wallet connector server may receive encoded data that includes text having a URL. The wallet connector server may parse the URL in the encoded data to match the parsed URL with a RUL of an encoding scheme in the mapping…”; pgh 58, “The wallet connector system may mediate the transaction to provide interoperability between a payment system of a sender and a payment system of a recipient.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 30 and 35:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claims 29 and 34, respectively. Kohli further teaches:
wherein the checkout URL is embedded in a QR code of the acquirer. (Kohli: pgh 3, “The closed loop payment system may provide the merchant with a digital encoding such as a Quick Response (QR) code that encodes a merchant identifier…The merchant may display…the QR code and request a payment amount.”; pgh 121, “…the URL or other network address may be included with and read from the encoded data.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Regarding claim(s) 31 and 36:
The combination of Malhotra/Kohli, as shown in the rejection above, discloses the limitations of claims 27 and 32, respectively. Malhotra further teaches:
receiving, by the acquirer system, a payment confirmation confirming the payment request from the bridging system. (Malhotra: pgh 73, “The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message.”)
Malhotra does not teach, however, Kohli teaches:
after receiving the delivery request from the issuer system further comprising: providing, by the acquirer system, a payment request to the bridging system; and (Kohli: pgh 87, “The payment network may forward the pull payment request to an issuer…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Malhotra to include the teachings of Kohli because “A payment system may be incompatible with another payment system when a payment from an account of one payment system cannot be made to an account of another payment system.” (Kohli: pgh 6).
Conclusion
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure. Klatt (US 2003/0154166) discloses a method for allowing a cash adjustment between payment systems in communications network.
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 9:00 am - 5: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 3698
July 25, 2026
/ERIC T WONG/Primary Examiner, Art Unit 3693
Prosecution Insights