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 the Application
Claims 1-12, 15-17, and 20 have been examined in this application.
The filling date of this application number recited above is 01-March-2024. Domestic Benefit/National Stage priority has been claimed for a 371 of international PCT/US2022/071864 and provisional 63/260900 in the Application Data Sheet, thus the examination will be undertaken in consideration of 22-April-2022 and 03-September-2021, as the priority date, for applicable claims.
The information disclosure statement (IDS) submitted on 09-July-2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-12, 15-17, and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The Claims are directed to an abstract idea, Methods of Organizing Human Activity. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
As per Claim 1, the claim recites “a … method comprising:
sending, by one or more [employees] on a merchant [group] amongst one or more merchant [groups] run by a merchant, a request for a credit evaluation for a customer, to a universal [entity] operatively coupled to the merchant [group] via a … communication …, wherein the universal [entity], in response to receiving the request for the credit evaluation, encodes a universal token for the customer with a bank account number corresponding to an open banking partner and payment card account number for a payment card service provider, and wherein the universal token enables the universal [entity] to access the open banking partner and the payment card service provider;
receiving, by the one or more [employees], the credit evaluation for the customer from the universal [entity] responsive to the request from the sending;
based on ascertaining that the credit evaluation for the customer satisfies a predefined credit threshold on a subscription for sale by the merchant, sending, by the one or more [employees], a request to set up a subscription service instance for the subscription between the merchant and the customer to the universal [entity] to thereby handle recurring payments corresponding to the subscription by the customer; and
receiving, by the one or more [employees], from the universal [entity], an acknowledgement that the subscription service instance has been successfully set up corresponding to the request for the subscription service instance, wherein the method further comprises, while the subscription is effective, and upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
accessing, via the universal token, the open banking partner to enable the universal [entity] to charge, by the subscription service instance for the subscription running on the universal [entity], the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date receiving, by the subscription service instance, a payment status on the current recurring payment from the open banking partner;
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had been successfully paid, sending a notification with the payment status on the current recurring payment to the merchant [group], by the subscription service instance;
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had not been successfully paid, accessing, via the universal token, the payment card service provider to enable the universal [entity] to charge the payment card service provider corresponding to the universal token for the amount of the current recurring payment on the scheduled date;
receiving, by the subscription service instance, a credit payment status on the current recurring payment from the payment network of the universal token; and
sending a notification with the credit payment status on the current recurring payment to the merchant [group].”
As per Claim 8, the claim recites “a … method comprising:
receiving, by one or more [employees] of a universal [entity], a request for a credit evaluation for a customer from a merchant [group] amongst one or more merchant [groups] run by a merchant, the merchant [group] being operatively coupled to the universal [entity] via a … communication …;
sending, by the one or more [employees], the credit evaluation for the customer to the merchant [group], based on completing a back-end processing for the credit evaluation with an open banking partner operatively coupled to the universal [entity];
obtaining, by the one or more [employees], a request from the merchant [group] for a subscription service instance to handle recurring payments corresponding to the subscription for the merchant by the customer; and
sending, by the one or more [employees], an acknowledgement, to the merchant [group], that the subscription service instance is successfully set up for handling the recurring payments, based on completing with setup of the subscription service instance for the merchant by the customer based on a universal token integrating payment card information and banking information of the customer, wherein the universal token is encoded with a bank account number corresponding to an open banking partner and payment card account number for a payment card service provider,
wherein the method further comprises, while the subscription is effective, and upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
accessing, via the universal token, the open banking partner to enable the universal [entity] to charge, by the subscription service instance for the subscription running on the universal [entity], the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date;
receiving, by the subscription service instance, a payment status on the current recurring payment from the open banking partner;
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had been successfully paid, sending a notification with the payment status on the current recurring payment to the merchant [group], by the subscription service instance;
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had not been successfully paid, accessing, via the universal token, the payment card service provider to enable the universal [entity] to charge the payment card service provider corresponding to the universal token for the amount of the current recurring payment on the scheduled date;
receiving, by the subscription service instance, a credit payment status on the current recurring payment from the payment network of the universal token; and
sending a notification with the credit payment status on the current recurring payment to the merchant [group].”
As per Claim 17, the claim recites “a [service] comprising:
a merchant [group] amongst one or more merchant [groups] for a merchant to access a payment service, wherein the merchant [group] is located at a retail store of the merchant, and wherein the merchant provides a retail product for sale to be purchased by a customer at the retail store by a subscription associated with recurring payments;
a universal [entity] configured to provide, to the merchant [group], the payment service, a subscription service to handle the recurring payments corresponding to the subscription, a token service to integrate financial information of the customer into a universal token for credit evaluation and payments, and a customer service to create and manage a customer account for the customer with respect to the subscription and the universal token;
one or more payment networks operatively coupled to the universal [entity] for credit transactions requested from the merchant [group]; and
one or more open banking partners operatively coupled to the universal [entity] for banking transactions requested from the merchant [group],
wherein the universal token is encoded with a bank account number corresponding to an open banking partner and a payment card account number for a payment card service provider, and
wherein the universal [entity] is further configured to:
access, via the universal token, the open banking partner to enable the universal [entity] to charge the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date while the subscription is effective;
receive a payment status on the current recurring payment from the open banking partner;
in response to ascertaining that the payment status indicates that the current recurring payment had not been successfully paid, access, via the universal token, the payment card service provider to enable the universal [entity] to charge the payment card service provided corresponding to the universal token for the amount of the current recurring payment;
receive a credit payment status on the current recurring payment from the payment network of the universal token; and
send a notification with the credit payment status on the current recurring payment to the merchant [group].”
The limitation of the claims recited above, considering the claims without the additional elements (e.g. processor, device, system, etc.), under its broadest reasonable interpretation (BRI), recites Certain Methods of Organizing Human Activities, specifically under fundamental economic principles or practices and/or commercial or legal interactions. The method recited above is a process with series of interactions between the associated parties (e.g. merchant, customer, universal gateway, open banking partner, etc.) to perform a credit evaluation for a subscription service, verifying the payment status, and completing the transaction by providing the subscription service with recurring payments. The process of performing a transaction, such as a subscription service with recurring payments by providing payment and banking information, is fundamental economic principles or practices, and the interactions performed for the transaction with the credit evaluation and payment status verification (e.g. sending and receiving messages) is commercial or legal interactions, which are both under certain methods of organizing human activities. Therefore, the claims recite an abstract idea.
This judicial exception is not integrated into practical application. In particular, the claims recite an additional element of “computer”, “processor”, “device”, “gateway”, “digital communication network”, “system”, and “payment network” to perform the method recited above by instructing the abstract idea to be performed “by” these generic computer components. These general computer components are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. These additional elements are generic, off-the-shelf components available to the public, and does not require any specialized hardware or equipment to perform the claimed method, but are merely applied to perform its basic functionalities, such as: receive data, send data, and read data, as disclosed by Specification:
[0089] “The present disclosure may be implemented as a system, a method, and/or a computer program product at any possible technical detail level of integration”
Mere instructions to implement the abstract idea on a computer, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of integration into a practical application; see MPEP 2106.05(f). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g. to receive, send, or verify data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g. certain methods of organizing human activities) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The claims also recite an additional element of “universal token”. However, this “token” is merely stored data or information associated with a payment method, as disclosed by the claims “wherein the universal token is encoded with a bank account number corresponding to an open banking partner and payment card account number for a payment card service provider”, and as disclosed by Specification:
[0014] “tokenizing the payment card information and the banking information corresponding to the customer into the universal token”;
[0021] “a token service to integrate financial information of the customer into a universal token for credit evaluation and payments”;
[0043] “By tokenizing financial information of the customer 103, the universal gateway 120 can access and be paid from the payment network 145 and the open banking partner 155 for each of the recurring payments by use of a token”,
which is still part of the abstract idea. The steps associated with the token is merely receiving, sending, or verifying the stored information associated with the transaction (i.e. recurring payment for subscription service) by using a generic computer system, wherein mere “apply it” is not indicative of integration into a practical application, as similarly discussed above.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, the additional element of using a computer based system is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the computer, how it could improve the computer itself, how it could manipulate the computer to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Mere instructions to implement the abstract idea on a computer, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of an inventive concept (aka “significantly more”). In view of the Specification cited above, the judicial exception is not applied with or used by a particular machine. As held in Parker v. Flook, 437 U.S. 584, 590, 198 USPQ 193, 199 (1978) and Bancorp Services v. Sun Life, 687 F.3d 1266, 1276, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012), “the routine use of a computer to perform calculations cannot turn an otherwise ineligible mathematical formula or law of nature into patentable subject matter.” The claims are not patent eligible.
Regarding dependent claims, they are still directed to an abstract idea without significantly more.
Claim 2 recites “the step of sending the request to set up the subscription service instance further comprising: prior to the sending the subscription service instance, obtaining respective values for an amount for the recurring payments, due dates for the recurring payments, a bank account number for a debit payment, and a payment card account number for a credit payment based on inputs by the merchant on the merchant device; and prior to the sending the subscription service instance, generating the subscription service instance with the respective values of the amount for the recurring payments, the due dates, the bank account number, and the payment card account number from the obtaining.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 3 recites “the step of sending the request for the credit evaluation for the customer further comprising: prior to the sending the request for the credit evaluation, obtaining respective values for a tax ID of the customer and personal identification information necessary to obtain a credit score report based on inputs on the merchant device as provided by the customer; prior to the sending the request for the credit evaluation, generating the request for the credit evaluation for the customer with the respective values for the tax ID and the personal identification information from the obtaining.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 4 recites “the step of sending the request for the credit evaluation for the customer further comprising: prior to the sending the request for the credit evaluation, obtaining respective values for a bank account number of the customer and personal identification information necessary to obtain bank statements based on inputs on the merchant device as provided by the customer; prior to the sending the request for the credit evaluation, generating the request for the credit evaluation for the customer with the respective values for the bank account number and the personal identification information from the obtaining.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 5 recites “further comprising: based on ascertaining that the credit evaluation for the customer does not satisfies the predefined credit threshold on the subscription for sale by the merchant, prompting the merchant for an input inquiring if the merchant would override the predefined credit threshold for the subscription, by displaying the credit evaluation for the customer along with a request for the input; obtaining, from the merchant, the input indicating that the merchant overrides the predefined credit threshold to thereby sell the subscription to the customer; sending the request to set up a subscription service instance for the subscription between the merchant and the customer to the universal gateway to thereby handle recurring payments corresponding to the subscription by the customer; and receiving, by the one or more processors, from the universal gateway, an acknowledgement that the subscription service instance has been successfully set up corresponding to the request for the subscription service instance.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 6 recites “further comprising: based on ascertaining that the credit evaluation for the customer does not satisfies the predefined credit threshold on the subscription for sale by the merchant, prompting the merchant for an input inquiring if the merchant would override the predefined credit threshold for the subscription, by displaying the credit evaluation for the customer along with a request for the input; obtaining, from the merchant, the input indicating that the merchant would not interfere with the predefined credit threshold thereby not to sell the subscription to the customer; and terminating inquiries on the subscription for the customer with the universal gateway.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 7 recites “further comprising: upon due dates respective to the recurring payments corresponding to the subscription, iteratively receiving a notification with a payment status on a current recurring payment from the universal gateway.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 9 recites “wherein the request for the credit evaluation comprises personal identification information, payment card information, and banking information, respectively corresponding to the customer.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 10 recites “the back-end processing for the credit evaluation comprising: creating a customer account for the customer; tokenizing the payment card information and the banking information corresponding to the customer into the universal token; inquiring the open banking partner for the credit evaluation for the customer with the universal token; and obtaining the credit evaluation corresponding to the universal token from the open banking partner.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 11 recites “wherein the request for the subscription service instance received from the merchant device to handle the recurring payments corresponding to the subscription for the merchant by the customer comprises respective values for an amount for the recurring payments, due dates for the recurring payments, a bank account number for a debit payment, and a payment card account number for a credit payment based on inputs by the merchant on the merchant device as provided by the customer.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 12 recites “further comprising: prior to the sending the acknowledgement of the subscription service instance, creating the subscription service instance based on respective values for an amount for the recurring payments corresponding to the subscription, due dates for the recurring payments, a bank account number for a debit payment for the recurring payments, and a payment card account number for a credit payment for the recurring payments; updating the universal token created upon the credit evaluation with the bank account number and the payment card account number set for the subscription service instance; and associating the customer account for the customer created upon the credit evaluation with the universal token resulting from the updating the universal token.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 15 recites “further comprising: while the subscription is effective, upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing: charging, by a subscription service instance for the subscription running on the universal gateway, the open banking partner of the universal token for an amount of a current recurring payment on a scheduled date; receiving, by the subscription service instance, a debit payment status on the current recurring payment from the open banking partner; based on ascertaining, by the subscription service instance, that the debit payment status indicates that the current recurring payment had not been successfully paid, charging the payment network of the universal token for the amount of the current recurring payment by the subscription service instance; receiving, by the subscription service instance, a credit payment status on the current recurring payment from the payment network of the universal token; and sending a notification with the debit payment status and the credit payment status on the current recurring payment to the merchant device.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 16 recites “further comprising: while the subscription is effective, upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing: charging, by a subscription service instance for the subscription running on the universal gateway, an alternative payment account of the customer comprising a reward point account and a gift card account as offered by the merchant or another merchant affiliated for payment exchange of the universal token for an amount of a current recurring payment on a scheduled date, wherein the universal token comprises the alternative payment account of the customer as provided by the customer or the merchant in relation with the subscription service instance.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
Claim 20 recites “wherein the universal gateway is further configured to: charge the open banking partner of the universal token for an amount of a current recurring payment on a scheduled date while the subscription is effective; receive a debit payment status on the current recurring payment from the open banking partner; based on ascertaining that the debit payment status indicates that the current recurring payment had not been successfully paid, charge the payment network of the universal token for the amount of the current recurring payment; receive a credit payment status on the current recurring payment from the payment network of the universal token; and send a notification with the debit payment status and the credit payment status on the current recurring payment to the merchant device.” The claim provides further steps and details with respect to the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application; see MPEP 2106.05(f).
These additional steps of each claims fail to remedy the deficiencies of their parent claim above because they are merely further limiting the rules used to conduct the previously recited abstract idea, and are therefore rejected for at least the same rationale as applied to their parent claim above.
Claims 2-7, 9-12, 15-16, and 20, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitations fail to establish that the claims are sufficient to integrate into a practical application and do not amount to significantly more than the judicial exception. Similarly to the independent claims, each claim recites using a generic computer component to perform the abstract idea as mentioned above, wherein mere “apply it” is not “significantly more”. Therefore, prong 2 and step 2B analysis are similar to above and these claims are not eligible.
Therefore, Claims 1-12, 15-17, and 20 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 103
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 following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Allen et al. (US 20100010930 A1), in view of Agarwal et al. (US 9449319 B1), in view of LUO et al. (CN 105282725 A), in view of Jain et al. (US 20200065796 A1), and in view of Khurana et al. (US 20180336557 A1).
As per Claim 1, Allen discloses a computer implemented method comprising:
sending, by one or more processors on a merchant device amongst one or more merchant devices run by a merchant, a request for a credit evaluation for a customer, to a universal gateway operatively coupled to the merchant device via a digital communication network … (See Figure 2 – step 205, as disclosed [0067] “MS 115 sends a TXA charge authorization request to the payment processor system, PPS 150. PPS 150 receives an authorization request from MS 115 (step 205)”);
receiving, by the one or more processors, the credit evaluation for the customer from the universal gateway responsive to the request from the sending (See Figure 2 – steps 210 to 235, as disclosed [0071] “PPS 150 creates a transaction authorization request message that includes the real time credit score (Step 215)” and [0072] “PPS 150 transmits the authorization reply to MS 115 (Step 230) and MS 115 informs user 105 of the authorization decision (Step 235)”);
Although Allen teaches of receiving transaction authorization request, the prior art does not seem to explicitly disclose of generating a token associated with different account numbers. However, Agarwal teaches:
… wherein the universal gateway, in response to receiving the request for the credit evaluation ([Col 4 Lines 20-23] “To engage in such a transaction, such as the purchase of an illustrated item, user 102(1) may provide an identifier linked with a payment instrument. User 102(1) may also provide a dynamic password for authenticating the identifier”), encodes a universal token for the customer with a bank account number corresponding to an open banking partner and payment card account number for a payment card service provider, and wherein the universal token enables the universal gateway to access the open banking partner and the payment card service provider ([Col 4 Lines 31-51] “In the latter instances, meanwhile, the identifier may comprise proxy for the linked payment instrument. For instance, the identifier provided by user 102(1) may comprise a transaction phrase token … Whatever its form, the transaction phrase token may link to a payment instrument, such as a bank account or a credit card. For example, a transaction phrase token associated with user 102(1) may link with a payment instrument (e.g., a credit card) of user 102(1) or some other person or entity” and see also [Col 7 Lines 8-19] “Identifier database 144 stores or has access to one or more identifiers 154(1), . . . , (R), each of which may be linked with one or more payment instruments … For instance, these identifiers may include credit card numbers, bank account numbers, transaction phrase tokens, and the like. Identifier issuer 146, meanwhile, may issue some these identifiers to users, such as user 102(1). For instance, issuer 146 may issue transaction phrase tokens to one or more users”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize transaction tokens associated with various identifiers, such as bank account or credit card numbers, as in Agarwal in the system executing the method of Allen, with the motivation of offering to [Col 1 Lines 6-14] ease users' ability to purchase items, enhance user experience by accepting various forms of payment, and increase security by utilizing tokens as taught by Agarwal over that of Allen.
Although Allen teaches of calculating a credit score for the customer for a requested transaction, the prior art does not seem to explicitly disclose that the transaction may be a request to set up a subscription service, and setting up the subscription service based on the credit score satisfying a threshold. However, LUO teaches:
based on ascertaining that the credit evaluation for the customer satisfies a predefined credit threshold on a subscription for sale by the merchant, sending, by the one or more processors, a request to set up a subscription service instance for the subscription between the merchant and the customer to the universal gateway to thereby handle recurring payments corresponding to the subscription by the customer ([Page 4 Lines 14-17] “Specifically, the user credit score can be integral with the preset threshold value, when the user credit score is greater than or equal to the predetermined integral threshold, receiving user service subscription request, when user credit score less than a predetermined integration threshold, does not accept user service subscription request”); and
receiving, by the one or more processors, from the universal gateway, an acknowledgement that the subscription service instance has been successfully set up corresponding to the request for the subscription service instance ([Page 4 Lines 9-11] “when it is determined that the accepted, deducts the relative cost of the user, transmits to the user the user ordering service (possibly virtual products, such as buy traffic packets), can transmit a message to tell the user the service subscription has been successfully, the user can use the service”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize comparing the credit score to a threshold to determine subscription service eligibility as in LUO in the system executing the method of Allen, wherein the system of Allen already teaches of calculating a credit score for the requested transaction, with the motivation of offering to [Page 3 Lines 3-10] reduce manual checking errors and improve charging efficiency while ensuring accuracy as taught by LUO over that of Allen.
Allen may not explicitly disclose, but Jain teaches:
… wherein the method further comprises, while the subscription is effective, and upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
accessing, via the universal token, the open banking partner to enable the universal gateway to charge, by the subscription service instance for the subscription running on the universal gateway, the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date (See Figure 6 – step 618, as disclosed [0116] “At 618, the issuer server 135 identifies the recurring transaction based on the RE flag and the unique identifier. Further, the customer payment account to be debited is also identified based on the customer payment account information included in the message”);
receiving, by the subscription service instance, a payment status on the current recurring payment from the open banking partner (See Figure 6 – step 620, as disclosed [0117] “At 620, the issuer server 135 provides a notification of the successful processing of the recurring payment (i.e., the next payment subsequent to the first payment) and debiting of the payment amount from the customer payment account to the customer 604”);
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had been successfully paid, sending a notification with the payment status on the current recurring payment to the merchant device, by the subscription service instance (See Figure 6 – step 626, as disclosed [0119] “At 626, the merchant bank, by using the server system 150, notifies the merchant 602 of the successful processing of the recurring payment and a crediting of the payment into the merchant payment account”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize notification for successful payment of recurring payments (i.e. subscription service) as in Jain in the system executing the method of Allen, with the motivation of offering to [0002-0005] improve customer experience and satisfaction for transactions with merchant through recuring payments as taught by Jain over that of Allen.
Allen may not explicitly disclose, but Khurana teaches:
… wherein the method further comprises, while the subscription is effective, and upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
accessing, via the universal token, the open banking partner to enable the universal gateway to charge, by the subscription service instance for the subscription running on the universal gateway, the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date (See Figure 3 – steps 301 to 305, as disclosed [0027] “In step 301, the system detects a payment date for a recurring payment associated with a customer account” and [0029] “In step 305, the system submits the customer payment information to a bank system”);
receiving, by the subscription service instance, a payment status on the current recurring payment from the open banking partner (See Figure 3 – step 307, as disclosed [0030] “In step 307, the system determines whether the payment has been authorized. In some embodiments, a payment system may provide either an authorization confirmation and/or an error code based on the bank system's response or lack of response to the charge request”);
…
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had not been successfully paid, accessing, via the universal token, the payment card service provider to enable the universal gateway to charge the payment card service provider corresponding to the universal token for the amount of the current recurring payment on the scheduled date (See Figure 3 – steps 311 to 314, as disclosed [0031] “In step 311, the system uses the received error code to determine whether the errors is associated with a customer payment information error” and [0034] “In step 314, the system determines whether the customer has provided updated payment information.”);
receiving, by the subscription service instance, a credit payment status on the current recurring payment from the payment network of the universal token (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information”); and
sending a notification with the credit payment status on the current recurring payment to the merchant device ([0036] “For each authorized payment, the system updates the customer account status and/or status in step 320. The process may repeat for the same account at the next payment date. In some embodiments, payment requests may be processed, resubmitted, and/or sent to the messaging server in a batch … Requests rejected for payment information errors may be aggregated at the messaging server and notifications may be generated and sent out to customers together at a set time (e.g. 8 am, noon, etc.)”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize updating account information for rejected recurring payments as in Khurana in the system executing the method of Allen, with the motivation of offering to improve user experience and satisfaction with automated notification system for recurring payments, while reducing fraudulent transactions as taught by Khurana over that of Allen.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Allen, in view of Agarwal, in view of LUO, in view of Jain, in view of Khurana, and in view of Melgar et al. (US 20180068294 A1).
As per claim 2, Allen may not explicitly disclose, but Melgar teaches the computer implemented method of claim 1, the step of sending the request to set up the subscription service instance further comprising:
prior to the sending the subscription service instance, obtaining respective values for an amount for the recurring payments, due dates for the recurring payments, a bank account number for a debit payment, and a payment card account number for a credit payment based on inputs by the merchant on the merchant device ([0028] “When staged money transfer transactions are provided by the system 100, a user may provide staging information to the system 100 … In an embodiment, the staging information may be received at the kiosk 110, the agent device 120, the central server 130, or a combination thereof” and the staging information is disclosed [0029] “In an embodiment, the staging information 144 may include scheduling information associated with a recurring money transfer transaction … The scheduling information may identify … a due date for the recurring money transfer transaction … Upon determining the particular frequency and amount of the recurring payments …” and the payment account information is also included, as disclosed [0032] “In an embodiment, the received staging information may further include information that identifies a preferred method for funding or receiving funds from the money transfer transaction and/or information indicating whether the money transfer transaction is a recurring money transfer transaction … ”); and
prior to the sending the subscription service instance, generating the subscription service instance with the respective values of the amount for the recurring payments, the due dates, the bank account number, and the payment card account number from the obtaining ([0029] “Upon determining the particular frequency and amount of the recurring payments, the receiving party may provide the scheduling information to the system 100, as described above” which is obvious that the staged recurring payment must be generated prior to being provided to the system).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize staging information including various information to setup a recurring payment schedule as in Melgar in the system executing the method of Allen, with the motivation of offering to [0003] “improves the performance of money transfer services provided via the money transfer network system and improves the performance of the underlying devices utilized to provide money transfer services” as taught by Melgar over that of Allen.
Claims 3-4 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Allen, in view of Agarwal, in view of LUO, in view of Jain, in view of Khurana, and in view of Hinderer (US 20040153396 A1).
As per claim 3, Allen may not explicitly disclose, but Hinderer teaches the computer implemented method of claim 1, the step of sending the request for the credit evaluation for the customer further comprising:
prior to the sending the request for the credit evaluation, obtaining respective values for a tax ID of the customer and personal identification information necessary to obtain a credit score report based on inputs on the merchant device as provided by the customer ([0041] “One of the ways in which the present invention can be used is to perform a credit check for a new telecommunications customer. Referring to FIG. 3, a process flow of the functioning of credit rules engine 104 during a credit check is shown. The first step is to take customer information, such as name, ID number (such as a tax ID …), address, bank account number, age, profession, etc., from an electronic commerce system 110 or another system”);
prior to the sending the request for the credit evaluation, generating the request for the credit evaluation for the customer with the respective values for the tax ID and the personal identification information from the obtaining ([0041] “A request for credit scoring for a customer is then sent to the appropriate external credit information source(s) 205” which is obvious that the request must be generated with the obtained information in order to send the request).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize obtaining customer information and generating the request for credit check as in Hinderer in the system executing the method of Allen, with the motivation of offering to provide [0011] fast credit decision, reduce payment delays and bad debt, increase revenues, reduce transaction cost, and improve customer relationships as taught by Hinderer over that of Allen.
As per claim 4, Allen may not explicitly disclose, but Hinderer teaches the computer implemented method of claim 1, the step of sending the request for the credit evaluation for the customer further comprising:
prior to the sending the request for the credit evaluation, obtaining respective values for a bank account number of the customer and personal identification information necessary to obtain bank statements based on inputs on the merchant device as provided by the customer ([0041] “One of the ways in which the present invention can be used is to perform a credit check for a new telecommunications customer. Referring to FIG. 3, a process flow of the functioning of credit rules engine 104 during a credit check is shown. The first step is to take customer information, such as name, ID number, address, bank account number, age, profession, etc., from an electronic commerce system 110 or another system”);
prior to the sending the request for the credit evaluation, generating the request for the credit evaluation for the customer with the respective values for the bank account number and the personal identification information from the obtaining ([0041] “A request for credit scoring for a customer is then sent to the appropriate external credit information source(s) 205” which is obvious that the request must be generated with the obtained information in order to send the request).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize obtaining customer information and generating the request for credit check as in Hinderer in the system executing the method of Allen, with the motivation of offering to provide [0011] fast credit decision, reduce payment delays and bad debt, increase revenues, reduce transaction cost, and improve customer relationships as taught by Hinderer over that of Allen.
As per claim 7, Allen may not explicitly disclose, but Hinderer teaches the computer implemented method of claim 1, further comprising:
upon due dates respective to the recurring payments corresponding to the subscription, iteratively receiving a notification with a payment status on a current recurring payment from the universal gateway ([0046] “When the receiving party's preferences indicate that receiving party prefers to pick up the payment as cash at a money transfer agent location and all funds for the money transfer transaction have been received from the one or more senders, the system 100 may generate a notification to the receiving party on the due date (or whenever the money transfer transaction is fully funded) indicating that the funds are available for pickup by the receiving party”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize notification of the payment status on the due date as in Hinderer in the system executing the method of Allen, with the motivation of offering to provide [0011] fast credit decision, reduce payment delays and bad debt, increase revenues, reduce transaction cost, and improve customer relationships as taught by Hinderer over that of Allen.
Claims 8-10 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Allen in view of Beadles et al. (US 20200258061 A1), in view of Agarwal, in view of Jain, and in view of Khurana.
As per claim 8, Allen teaches a computer implemented method comprising:
receiving, by one or more processors of a universal gateway, a request for a credit evaluation for a customer from a merchant device amongst one or more merchant devices run by a merchant, the merchant device being operatively coupled to the universal gateway via a digital communication network (See Figure 2 – step 205, as disclosed [0067] “MS 115 sends a TXA charge authorization request to the payment processor system, PPS 150. PPS 150 receives an authorization request from MS 115 (step 205)”);
sending, by the one or more processors, the credit evaluation for the customer to the merchant device, based on completing a back-end processing for the credit evaluation with an open banking partner operatively coupled to the universal gateway (See Figure 2 – steps 210 to 235, as disclosed [0071] “PPS 150 creates a transaction authorization request message that includes the real time credit score (Step 215)” and [0072] “PPS 150 transmits the authorization reply to MS 115 (Step 230) and MS 115 informs user 105 of the authorization decision (Step 235)”);
Although Allen teaches of calculating a credit score for the customer for a requested transaction, the prior art does not seem to explicitly disclose the steps associated with setting up a subscription service. However, Beadles teaches:
obtaining, by the one or more processors, a request from the merchant device for a subscription service instance to handle recurring payments corresponding to the subscription for the merchant by the customer ([0023] “rendering on a graphical user interface of the blockchain subscription pay manager application of a computing system, a new subscription payment plan set up tool for facilitating set up of new subscription payment plan by the merchant … the new subscription payment plan being implemented in the form of a subscription blockchain smart contract for automatically making recurring payments from a user subscription wallet associated with the user blockchain account of a user to the merchant subscription wallet associated with the merchant blockchain account”); and
sending, by the one or more processors, an acknowledgement, to the merchant device, that the subscription service instance is successfully set up for handling the recurring payments, based on completing with setup of the subscription service instance for the merchant by the customer based on a universal token integrating payment card information and banking information of the customer … ([0023] “generating a subscription payment plan invoice in said computing system for payment from the user subscription wallet according to said new said subscription plan; the subscription payment plan invoice including details of the new subscription payment plan and a request for the user to provide confirmation information for subscribing to the subscription payment plan … receiving user entered instructions into said graphical user interface confirming user information in subscription payment plan invoice for subscribing to said new subscription payment plan” and see also Figure 24 displaying GUI of a confirmation of subscription).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize subscription request and confirmation utilizing user wallet information as in Beadles in the system executing the method of Allen, wherein the system of Allen already teaches of calculating a credit score for the requested transaction, with the motivation of offering to [0150] “to enhance security, improve management of services, speed up the process of KYC (know your customer)/registration, provide merchants additional payment options, and enable customers greater flexibility; all in a decentralized high-performance open network” as taught by Beadles over that of Allen.
Although Allen teaches of receiving transaction authorization request, the prior art does not seem to explicitly disclose of generating a token associated with different account numbers. However, Agarwal teaches:
… wherein the universal token is encoded with a bank account number corresponding to an open banking partner and payment card account number for a payment card service provider ([Col 4 Lines 31-51] “In the latter instances, meanwhile, the identifier may comprise proxy for the linked payment instrument. For instance, the identifier provided by user 102(1) may comprise a transaction phrase token … Whatever its form, the transaction phrase token may link to a payment instrument, such as a bank account or a credit card. For example, a transaction phrase token associated with user 102(1) may link with a payment instrument (e.g., a credit card) of user 102(1) or some other person or entity” and see also [Col 7 Lines 8-19] “Identifier database 144 stores or has access to one or more identifiers 154(1), . . . , (R), each of which may be linked with one or more payment instruments … For instance, these identifiers may include credit card numbers, bank account numbers, transaction phrase tokens, and the like. Identifier issuer 146, meanwhile, may issue some these identifiers to users, such as user 102(1). For instance, issuer 146 may issue transaction phrase tokens to one or more users”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize transaction tokens associated with various identifiers, such as bank account or credit card numbers, as in Agarwal in the system executing the method of Allen, with the motivation of offering to [Col 1 Lines 6-14] ease users' ability to purchase items, enhance user experience by accepting various forms of payment, and increase security by utilizing tokens as taught by Agarwal over that of Allen.
Allen may not explicitly disclose, but Jain teaches:
wherein the method further comprises, while the subscription is effective, and upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
accessing, via the universal token, the open banking partner to enable the universal gateway to charge, by the subscription service instance for the subscription running on the universal gateway, the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date (See Figure 6 – step 618, as disclosed [0116] “At 618, the issuer server 135 identifies the recurring transaction based on the RE flag and the unique identifier. Further, the customer payment account to be debited is also identified based on the customer payment account information included in the message”);
receiving, by the subscription service instance, a payment status on the current recurring payment from the open banking partner (See Figure 6 – step 620, as disclosed [0117] “At 620, the issuer server 135 provides a notification of the successful processing of the recurring payment (i.e., the next payment subsequent to the first payment) and debiting of the payment amount from the customer payment account to the customer 604”);
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had been successfully paid, sending a notification with the payment status on the current recurring payment to the merchant device, by the subscription service instance (See Figure 6 – step 626, as disclosed [0119] “At 626, the merchant bank, by using the server system 150, notifies the merchant 602 of the successful processing of the recurring payment and a crediting of the payment into the merchant payment account”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize notification for successful payment of recurring payments (i.e. subscription service) as in Jain in the system executing the method of Allen, with the motivation of offering to [0002-0005] improve customer experience and satisfaction for transactions with merchant through recuring payments as taught by Jain over that of Allen.
Allen may not explicitly disclose, but Khurana teaches:
wherein the method further comprises, while the subscription is effective, and upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
accessing, via the universal token, the open banking partner to enable the universal gateway to charge, by the subscription service instance for the subscription running on the universal gateway, the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date (See Figure 3 – steps 301 to 305, as disclosed [0027] “In step 301, the system detects a payment date for a recurring payment associated with a customer account” and [0029] “In step 305, the system submits the customer payment information to a bank system”);
receiving, by the subscription service instance, a payment status on the current recurring payment from the open banking partner (See Figure 3 – step 307, as disclosed [0030] “In step 307, the system determines whether the payment has been authorized. In some embodiments, a payment system may provide either an authorization confirmation and/or an error code based on the bank system's response or lack of response to the charge request”);
…
in response to ascertaining, by the subscription service instance, that the payment status indicates that the current recurring payment had not been successfully paid, accessing, via the universal token, the payment card service provider to enable the universal gateway to charge the payment card service provider corresponding to the universal token for the amount of the current recurring payment on the scheduled date (See Figure 3 – steps 311 to 314, as disclosed [0031] “In step 311, the system uses the received error code to determine whether the errors is associated with a customer payment information error” and [0034] “In step 314, the system determines whether the customer has provided updated payment information.”);
receiving, by the subscription service instance, a credit payment status on the current recurring payment from the payment network of the universal token (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information”); and
sending a notification with the credit payment status on the current recurring payment to the merchant device ([0036] “For each authorized payment, the system updates the customer account status and/or status in step 320. The process may repeat for the same account at the next payment date. In some embodiments, payment requests may be processed, resubmitted, and/or sent to the messaging server in a batch … Requests rejected for payment information errors may be aggregated at the messaging server and notifications may be generated and sent out to customers together at a set time (e.g. 8 am, noon, etc.)”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize updating account information for rejected recurring payments as in Khurana in the system executing the method of Allen, with the motivation of offering to improve user experience and satisfaction with automated notification system for recurring payments, while reducing fraudulent transactions as taught by Khurana over that of Allen.
As per claim 9, Allen teaches the computer implemented method of claim 8, wherein the request for the credit evaluation comprises personal identification information, payment card information, and banking information, respectively corresponding to the customer ([0069] “In one embodiment, PPS 150 accesses credit bureau information directly and RTSE 155 calculates a credit score by performing a forecast that considers factors such as, for example … accounts receivable data, payment history, customer profile information, demographic data, economic trends etc. … For example, in one embodiment, the AIS 180 provides payment history, customer profile information and accounts receivable data to while PPS 150 receives other information regarding the customer's spending and payment habits” and see also Claim 12 “wherein the authorization request comprises multiple transaction account identifiers associated with multiple transaction accounts issued by different issuing banks, and wherein the credit score is based on analyzing information from the multiple transaction accounts”).
As per claim 10, Allen may not explicitly disclose, but Agarwal teaches the computer implemented method of claim 8, the back-end processing for the credit evaluation comprising:
creating a customer account for the customer ([0058] “In an illustrative embodiment, the transaction account interface component 114 can generate an interface for obtaining transaction phrase token configuration information, as will be illustrated with regard to FIG. 4B”);
tokenizing the payment card information and the banking information corresponding to the customer into the universal token ([0030] “Each transaction phrase token can be associated with configuration information that facilitates the processing of a transaction involving the transaction phrase token. In an illustrative embodiment, the configuration information can relate to the types of reconciliation activities (e.g., debits or credits) allowed for the transaction account associated with the transaction phrase token (e.g., bank accounts, credit card accounts, service provider created accounts, etc.)”);
inquiring the open banking partner for the credit evaluation for the customer with the universal token ([0031] “Upon receipt of the offered transaction phrase token, the other party may implement additional processing steps, such as security verifications, credit checks, etc.”); and
obtaining the credit evaluation corresponding to the universal token from the open banking partner ([0031] “Upon receipt of the offered transaction phrase token, the other party may implement additional processing steps, such as security verifications, credit checks, etc.” which is obvious to obtain a credit evaluation upon implementing a credit check step).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize token generation and utilizing token for additional authentication, such as credit check, as in Agarwal in the system executing the method of Allen, wherein the system of Allen already teaches of performing credit check for the requested transaction, with the motivation of offering to [0005] improve security and user experience by utilizing tokens for transactions without exchanging transaction account information as taught by Agarwal over that of Allen.
As per claim 15, Allen may not explicitly disclose, but Khurana teaches the computer implemented method of claim 8, further comprising:
while the subscription is effective, upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
charging, by a subscription service instance for the subscription running on the universal gateway, the open banking partner of the universal token for an amount of a current recurring payment on a scheduled date (See Figure 3 – steps 301 to 305, as disclosed [0027] “In step 301, the system detects a payment date for a recurring payment associated with a customer account” and [0029] “In step 305, the system submits the customer payment information to a bank system”);
receiving, by the subscription service instance, a debit payment status on the current recurring payment from the open banking partner (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information” wherein [0028] “In some embodiments, the customer payment information comprises one or more of … debit card number”);
based on ascertaining, by the subscription service instance, that the debit payment status indicates that the current recurring payment had not been successfully paid, charging the payment network of the universal token for the amount of the current recurring payment by the subscription service instance (See Figure 3 – steps 311 to 314, as disclosed [0031] “In step 311, the system uses the received error code to determine whether the errors is associated with a customer payment information error” and [0034] “In step 314, the system determines whether the customer has provided updated payment information.”);
receiving, by the subscription service instance, a credit payment status on the current recurring payment from the payment network of the universal token (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information”); and
sending a notification with the debit payment status and the credit payment status on the current recurring payment to the merchant device ([0036] “For each authorized payment, the system updates the customer account status and/or status in step 320. The process may repeat for the same account at the next payment date. In some embodiments, payment requests may be processed, resubmitted, and/or sent to the messaging server in a batch … Requests rejected for payment information errors may be aggregated at the messaging server and notifications may be generated and sent out to customers together at a set time (e.g. 8 am, noon, etc.)”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize updating account information for rejected recurring payments as in Khurana in the system executing the method of Allen, with the motivation of offering to improve user experience and satisfaction with automated notification system for recurring payments, while reducing fraudulent transactions as taught by Khurana over that of Allen.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Allen, in view of Beadles, in view of Agarwal, in view of Jain, in view of Khurana, and in view of Melgar.
As per claim 11, Allen may not explicitly disclose, but Melgar teaches the computer implemented method of claim 8, wherein the request for the subscription service instance received from the merchant device to handle the recurring payments corresponding to the subscription for the merchant by the customer comprises respective values for an amount for the recurring payments, due dates for the recurring payments, a bank account number for a debit payment, and a payment card account number for a credit payment based on inputs by the merchant on the merchant device as provided by the customer ([0028] “When staged money transfer transactions are provided by the system 100, a user may provide staging information to the system 100 … In an embodiment, the staging information may be received at the kiosk 110, the agent device 120, the central server 130, or a combination thereof” and the staging information is disclosed [0029] “In an embodiment, the staging information 144 may include scheduling information associated with a recurring money transfer transaction … The scheduling information may identify … a due date for the recurring money transfer transaction … Upon determining the particular frequency and amount of the recurring payments …” and the payment account information is also included, as disclosed [0032] “In an embodiment, the received staging information may further include information that identifies a preferred method for funding or receiving funds from the money transfer transaction and/or information indicating whether the money transfer transaction is a recurring money transfer transaction … ”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize staging information including various information to setup a recurring payment schedule as in Melgar in the system executing the method of Allen, with the motivation of offering to [0003] “improves the performance of money transfer services provided via the money transfer network system and improves the performance of the underlying devices utilized to provide money transfer services” as taught by Melgar over that of Allen.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Allen, in view of Beadles, in view of Agarwal, in view of Jain, in view of Khurana, in view of Melgar, and in view of TIETZEN et al. (CA 2998274 A1).
As per claim 12, Allen may not explicitly disclose, but Melgar teaches the computer implemented method of claim 8, further comprising:
prior to the sending the acknowledgement of the subscription service instance, creating the subscription service instance based on respective values for an amount for the recurring payments corresponding to the subscription, due dates for the recurring payments, a bank account number for a debit payment for the recurring payments, and a payment card account number for a credit payment for the recurring payments ([0028] “When staged money transfer transactions are provided by the system 100, a user may provide staging information to the system 100 … In an embodiment, the staging information may be received at the kiosk 110, the agent device 120, the central server 130, or a combination thereof” and the staging information is disclosed [0029] “In an embodiment, the staging information 144 may include scheduling information associated with a recurring money transfer transaction … The scheduling information may identify … a due date for the recurring money transfer transaction … Upon determining the particular frequency and amount of the recurring payments …” and the payment account information is also included, as disclosed [0032] “In an embodiment, the received staging information may further include information that identifies a preferred method for funding or receiving funds from the money transfer transaction and/or information indicating whether the money transfer transaction is a recurring money transfer transaction … ”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize staging information including various information to setup a recurring payment schedule as in Melgar in the system executing the method of Allen, with the motivation of offering to [0003] “improves the performance of money transfer services provided via the money transfer network system and improves the performance of the underlying devices utilized to provide money transfer services” as taught by Melgar over that of Allen.
Allen may not explicitly disclose, but TIETZEN teaches:
updating the universal token created upon the credit evaluation with the bank account number and the payment card account number set for the subscription service instance ([00477] “For example, as part of the loyalty program, a merchant may subscribe to different levels of membership, different loyalty program features or to access different customer groups” wherein [00480] “Tier 1: Merchants/merchant brands have access to customers who become members by opting into the loyalty program and linking a payment token (e.g. credit/debit card, bank account, mobile device configured for transacting) with the program”); and
associating the customer account for the customer created upon the credit evaluation with the universal token resulting from the updating the universal token ([00493] “profile groups can be based on any one or combination of factors such as … credit score …”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize token associated with subscription service and credit score as in TIETZEN in the system executing the method of Allen, with the motivation of offering to provide benefits such as [00109] improved customer loyalty and retention and increase in customer spending as taught by TIETZEN over that of Allen.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Allen, in view of Beadles, in view of Agarwal, in view of Jain, in view of Khurana, and in view of APPANA (US 20190333087 A1).
As per claim 16, Allen may not explicitly disclose, but APPANA teaches the computer implemented method of claim 8, further comprising:
while the subscription is effective, upon respective due dates for each of the recurring payments corresponding to the subscription, iteratively performing:
charging, by a subscription service instance for the subscription running on the universal gateway, an alternative payment account of the customer comprising a reward point account and a gift card account as offered by the merchant or another merchant affiliated for payment exchange of the universal token for an amount of a current recurring payment on a scheduled date, wherein the universal token comprises the alternative payment account of the customer as provided by the customer or the merchant in relation with the subscription service instance ([0050] “At 315, the user 108 creates a subscription account and chooses to pay using the gift card 106” and [0055] “At 340, the user 108 selects a subscription option for the subscription service 118 and performs a payment transaction for the subscription service 118 by performing at least a part payment using the balance amount in the gift card 106. The issuer server 116 determines payment amount based on the subscription option selected by the user 108 for the subscription service 118. The payment transaction for the subscription service 118 is performed by choosing the gift card 106 as the mode of payment for the payment transaction”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize gift cards for subscription payments as in APPANA in the system executing the method of Allen, with the motivation of offering to provide [0002-0006] tracking and rewarding distributors who play a role in acquisition of a new customer for a subscription service as taught by APPANA over that of Allen.
Claims 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Allen, in view of Beadles, in view of Agarwal, and in view of Khurana.
As per claim 17, Allen teaches a system comprising:
a merchant device amongst one or more merchant devices for a merchant to access a payment service, wherein the merchant device is located at a retail store of the merchant, and wherein the merchant provides a retail product for sale to be purchased by a customer at the retail store by a subscription associated with recurring payments (See Figure 2 – step 205, as disclosed [0067] “MS 115 sends a TXA charge authorization request to the payment processor system, PPS 150. PPS 150 receives an authorization request from MS 115 (step 205)”);
a universal gateway configured to provide, to the merchant device, the payment service, … a token service to integrate financial information of the customer into a universal token for credit evaluation and payments, … (See Figure 2 – steps 210 to 235, as disclosed [0071] “PPS 150 creates a transaction authorization request message that includes the real time credit score (Step 215)” and [0072] “PPS 150 transmits the authorization reply to MS 115 (Step 230) and MS 115 informs user 105 of the authorization decision (Step 235)”);
one or more payment networks operatively coupled to the universal gateway for credit transactions requested from the merchant device ([0039] “External data sources ("EDS") 195 include other sources of data that may be useful in assessing the credit-worthiness of a TXA holder such as, for example, data provided by other TXA issuers or other lending institutions”); and
one or more open banking partners operatively coupled to the universal gateway for banking transactions requested from the merchant device ([0033] “Payment processing system ("PPS") 150 provides services that enable transactions such as data transfer, message or request transfer, data augmentation and data retrieval from remote or third-party systems. PPS 150 communicates with MS 115 and account issuer system ("AIS") 180 to enable financial transactions”).
Although Allen teaches of calculating a credit score for the customer for a requested transaction, the prior art does not seem to explicitly disclose the steps associated with setting up a subscription service. However, Beadles teaches:
a universal gateway configured to provide, to the merchant device, the payment service, a subscription service to handle the recurring payments corresponding to the subscription ([0023] “rendering on a graphical user interface of the blockchain subscription pay manager application of a computing system, a new subscription payment plan set up tool for facilitating set up of new subscription payment plan by the merchant … the new subscription payment plan being implemented in the form of a subscription blockchain smart contract for automatically making recurring payments from a user subscription wallet associated with the user blockchain account of a user to the merchant subscription wallet associated with the merchant blockchain account”), a token service to integrate financial information of the customer into a universal token for credit evaluation and payments, and a customer service to create and manage a customer account for the customer with respect to the subscription and the universal token (See Figures 25-26 displaying GUI for subscription management services associated with the customer account);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize subscription request and subscription account management as in Beadles in the system executing the method of Allen, wherein the system of Allen already teaches of calculating a credit score for the requested transaction, with the motivation of offering to [0150] “to enhance security, improve management of services, speed up the process of KYC (know your customer)/registration, provide merchants additional payment options, and enable customers greater flexibility; all in a decentralized high-performance open network” as taught by Beadles over that of Allen.
Although Allen teaches of receiving transaction authorization request, the prior art does not seem to explicitly disclose of generating a token associated with different account numbers. However, Agarwal teaches:
wherein the universal token is encoded with a bank account number corresponding to an open banking partner and payment card account number for a payment card service provider ([Col 4 Lines 31-51] “In the latter instances, meanwhile, the identifier may comprise proxy for the linked payment instrument. For instance, the identifier provided by user 102(1) may comprise a transaction phrase token … Whatever its form, the transaction phrase token may link to a payment instrument, such as a bank account or a credit card. For example, a transaction phrase token associated with user 102(1) may link with a payment instrument (e.g., a credit card) of user 102(1) or some other person or entity” and see also [Col 7 Lines 8-19] “Identifier database 144 stores or has access to one or more identifiers 154(1), . . . , (R), each of which may be linked with one or more payment instruments … For instance, these identifiers may include credit card numbers, bank account numbers, transaction phrase tokens, and the like. Identifier issuer 146, meanwhile, may issue some these identifiers to users, such as user 102(1). For instance, issuer 146 may issue transaction phrase tokens to one or more users”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize transaction tokens associated with various identifiers, such as bank account or credit card numbers, as in Agarwal in the system executing the method of Allen, with the motivation of offering to [Col 1 Lines 6-14] ease users' ability to purchase items, enhance user experience by accepting various forms of payment, and increase security by utilizing tokens as taught by Agarwal over that of Allen.
Allen may not explicitly disclose, but Khurana teaches:
wherein the universal gateway is further configured to:
access, via the universal token, the open banking partner to enable the universal gateway to charge the open banking partner corresponding to the universal token for an amount of a current recurring payment on a scheduled date while the subscription is effective (See Figure 3 – steps 301 to 305, as disclosed [0027] “In step 301, the system detects a payment date for a recurring payment associated with a customer account” and [0029] “In step 305, the system submits the customer payment information to a bank system”);
receive a payment status on the current recurring payment from the open banking partner (See Figure 3 – step 307, as disclosed [0030] “In step 307, the system determines whether the payment has been authorized. In some embodiments, a payment system may provide either an authorization confirmation and/or an error code based on the bank system's response or lack of response to the charge request”);
in response to ascertaining that the payment status indicates that the current recurring payment had not been successfully paid, access, via the universal token, the payment card service provider to enable the universal gateway to charge the payment card service provider corresponding to the universal token for the amount of the current recurring payment (See Figure 3 – steps 311 to 314, as disclosed [0031] “In step 311, the system uses the received error code to determine whether the errors is associated with a customer payment information error” and [0034] “In step 314, the system determines whether the customer has provided updated payment information.”);
receive a credit payment status on the current recurring payment from the payment network of the universal token (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information”); and
send a notification with the credit payment status on the current recurring payment to the merchant device ([0036] “For each authorized payment, the system updates the customer account status and/or status in step 320. The process may repeat for the same account at the next payment date. In some embodiments, payment requests may be processed, resubmitted, and/or sent to the messaging server in a batch … Requests rejected for payment information errors may be aggregated at the messaging server and notifications may be generated and sent out to customers together at a set time (e.g. 8 am, noon, etc.)”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize updating account information for rejected recurring payments as in Khurana in the system executing the method of Allen, with the motivation of offering to improve user experience and satisfaction with automated notification system for recurring payments, while reducing fraudulent transactions as taught by Khurana over that of Allen.
As per claim 20, Allen may not explicitly disclose, but Khurana teaches the system of claim 17, wherein the universal gateway is further configured to:
charge the open banking partner of the universal token for an amount of a current recurring payment on a scheduled date while the subscription is effective (See Figure 3 – steps 301 to 305, as disclosed [0027] “In step 301, the system detects a payment date for a recurring payment associated with a customer account” and [0029] “In step 305, the system submits the customer payment information to a bank system”);
receive a debit payment status on the current recurring payment from the open banking partner (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information” wherein [0028] “In some embodiments, the customer payment information comprises one or more of … debit card number”);
based on ascertaining that the debit payment status indicates that the current recurring payment had not been successfully paid, charge the payment network of the universal token for the amount of the current recurring payment (See Figure 3 – steps 311 to 314, as disclosed [0031] “In step 311, the system uses the received error code to determine whether the errors is associated with a customer payment information error” and [0034] “In step 314, the system determines whether the customer has provided updated payment information.”);
receive a credit payment status on the current recurring payment from the payment network of the universal token (See Figure 3 – steps 314 to 305, as disclosed [0034] “In step 314, the system determines whether the customer has provided updated payment information … In some embodiments, when an updated payment information is received, the system may immediately return to step 305 and try to obtain payment authorization with the updated payment information”); and
send a notification with the debit payment status and the credit payment status on the current recurring payment to the merchant device ([0036] “For each authorized payment, the system updates the customer account status and/or status in step 320. The process may repeat for the same account at the next payment date. In some embodiments, payment requests may be processed, resubmitted, and/or sent to the messaging server in a batch … Requests rejected for payment information errors may be aggregated at the messaging server and notifications may be generated and sent out to customers together at a set time (e.g. 8 am, noon, etc.)”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize updating account information for rejected recurring payments as in Khurana in the system executing the method of Allen, with the motivation of offering to improve user experience and satisfaction with automated notification system for recurring payments, while reducing fraudulent transactions as taught by Khurana over that of Allen.
Response to Arguments
Applicant's arguments, see pages 11 to 16, filed 17-September-2025, with respect to 35 U.S.C. 101 rejection have been fully considered but they are not persuasive.
Applicant contends, see pages 12 to 14, under Step 2A Prong 1, that the claims do not recite certain methods of organizing human activity. Examiner respectfully disagrees. As discussed above under 35 U.S.C. 101 rejection, considering the claims as a whole without the additional elements (e.g. processor, device, gateway, system, etc.), under BRI, the claims recite various interactions between the associated parties (e.g. merchant, customer, open bank, payment service provider, etc.) to verify and set-up recurring transactions, wherein the additional intermediary party involved in performing the transaction still recites an abstract idea. Therefore, the claims recite an abstract idea.
Applicant contends, see pages 14 to 16, under Step 2A Prong 2, that the claims integrate the exception into a practical application. Examiner respectfully disagrees. As discussed above under 35 U.S.C. 101 rejection, the additional elements are generic computer components merely applied to implement the abstract idea (e.g. performing recurring payment transactions) by performing its generic functionalities (e.g. send data, receive data, verify data, etc.), which is not indicative of integration into a practical application. In view of the Specification cited above, the judicial exception is not applied with or used by a particular machine. As held in Parker v. Flook, 437 U.S. 584, 590, 198 USPQ 193, 199 (1978) and Bancorp Services v. Sun Life, 687 F.3d 1266, 1276, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012), “the routine use of a computer to perform calculations cannot turn an otherwise ineligible mathematical formula or law of nature into patentable subject matter.” The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the computer, how it could improve the computer itself, how it could manipulate the computer to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Therefore, the 35 U.S.C. 101 rejection is maintained.
Applicant’s arguments, see pages 16 to 17, with respect to 35 U.S.C. 103 rejection have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hutchison et al. (US 20050192896 A1) discloses [0094] “collecting payments from consumers and applying the payments to the consumer's account; transferring funds between merchants and consumer, for example by interfacing with financial institutions 59 for ACH transactions. Examples of standard transactions for the account enrollment sub-system include: obtaining credit information from credit bureaus; providing the credit information to the commerce gateway 52 for scoring; determining a credit score based on the credit information and providing the score to the commerce gateway; and providing scoring information to the account/billing sub-system 94 for account creation”;
Arya et al. (US 10984434 B1) discloses [Col 18 Lines 10-19] “At 204, the provider computing system 104 verifies that the customer meets criteria for the subscription account. For example, the criteria may include a certain level of risk that the customer meets or is below (e.g., based on the customer's credit score and financial history), a minimum balance that the customer needs to maintain in the subscription account, and so on. In some embodiments, the provider computing system 104 may offer the customer a subscription account with different terms based on whether the customer meets various account criteria thresholds”;
ANDERSON (US 20220398585 A1) discloses [0329] “In one embodiment, the associated terms include an interest rate, a reward information, a time period for repayment when the selected one of the plurality of payment scenarios is a non-credit account payment option, a predefined payment amount and a recurring payment due date within the time period for a repayment when the selected one of the plurality of payment scenarios is a non-credit account payment option, and the like”;
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 HENRY H JUNG whose telephone number is (571)270-5018. The examiner can normally be reached Mon - Fri 9:30 - 5:30.
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 Tran (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.
/HENRY H JUNG/ Examiner, Art Unit 3695
/CHRISTINE M Tran/ Supervisory Patent Examiner, Art Unit 3695