Ear1 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 .
DETAILED ACTION
1. The following is a non-final, First Office Action on the merits. Claims 1-20 are pending.
The Examiner’s Notes:
2. Dependent claim 9 (its dependency are claims 10 and 11) as a whole recites a combination of limitations that has been found as define over prior art of record {The combination of Ali et al; (US 2014/0067677 A1), Khan et al; (US 2020/0058047 A1), Chandrasekaran et al; (US 2015/0324830 A1), Rao et al; (US 2022/0020049 A1).
Dependent claim 12 as a whole recites a combination of limitations that has been found as define over prior art of record {The combination of Ali et al; (US 2014/0067677 A1), Khan et al; (US 2020/0058047 A1), Chandrasekaran et al; (US 2015/0324830 A1), Rao et al; (US 2022/0020049 A1) and Agrawal et al; (US 2025/0285105 A1)} fails to fairly teaches the claimed system and method as a whole include the underlined subject matter: “for each of the one or more bank account data elements: (i) calculating a frequency of performing payment transactions using a respective bank account identifier; and (ii) recalculating a respective at least one fee value, based on the calculated frequency; and wherein inferring, by the payment server, the respectively pretrained first ML- based model is further performed on the recalculated at least one fee value, to calculate the one or more cost-effective payment methods.”
Claim Rejections - 35 USC § 112
However, please notes that claims 1-20 are rejected under 101 below.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
3. Dependent claim 13 is rejected under 35 U.S.C. 112 (b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention:
Dependent claim 13 (dependency of claim 4, which is dependency of claim 3, which is dependency of claim 1) recites: “providing via a user interface (UI) of the payment terminal, a third suggestion data element….”. The scope of this limitation is confusing since there is no recitation of “a first suggestion data element” and “a second suggestion data element” in claims 1, 3 and/or 4 at all. Appropriated correction is required.
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.
4. The claimed invention (Claims 1-20) is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) abstract ideas including “Certain Methods of Organizing Human Activity”, and/or Mathematical Concepts, which has/have been identified/found by the courts as abstract ideas in MPEP 2106.04(a). This judicial exception is not integrated into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because it/they is/are recited at a high level of generality and/or are recited as performing generic computer functions routinely used in the computer applications:
5. Step 1: Does the Claim Fall within a statutory Category?
Claims 1-19: Yes, these claims are method and therefore are directed to the statutory class of process.
Claim 20: Yes, this claim is a system, which recite a mobile device; a payment terminal and a payment server, and at least one procesor…….., and therefore are directed to the statutory class of machine and article of manufacture.
6. Step 2A prong 1, Step 2A prong 2 and Step 2B:
Independent claim 1 (Step 2A, Prong I): is directed to an abstract idea of “Certain Methods of Organizing Human Activity”, and/or Mathematical Concepts:
Steps 2-6 of receiving, by the merchant from the user/customer a payment token (step 2); receiving, by the payment entity from the merchant: (i) the payment token, (ii) a store or product identifier, and (iii) an amount to be paid (step 3); retrieving, from a record, payment information comprising: one or more bank account data elements, and a loyalty card data
element; said payment information being associated with the received payment token, and said loyalty card data element being further associated with the received store or product identifier (step 4); recalculating, by the payment entity, the amount to be paid, based on the retrieve loyalty card data element (step 5); and initiating, by the payment entity, the payment transaction, using: (i) the recalculated amount to be paid; and (ii) the retrieved one or more bank account data elements (step 6) falls within “Certain Methods of Organizing Human Activity” grouping of abstract idea because these steps mainly describe the concepts of commercial or legal interactions (include subject matter relating to agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); and/or managing personal behavior or relationships or interactions between people (including following rules or instructions).
Further, step 5 mentioned above of recalculating, by the payment entity, the amount to be paid, based on the retrieve loyalty card data element (step 5) also fall under Mathematical Concepts (mathematical relationships, mathematical formulas or equations, and/or mathematical calculations) grouping of abstract idea because there must be mathematical operations/algorithm involve in order to “recalculating, by the payment entity, the amount to be paid, based on the retrieve loyalty card data element”.
Independent claim 1, Step 2A (Prong II): Accordingly, the claim recites an abstract idea(s) as pointed out above. This judicial exception(s) is/are not integrated into a practical application. In particular, the claim recites underlined additional elements (i.e., establishing wireless connection between a payment terminal and a mobile device, said payment terminal being connected to a payment server; the payment terminal; the payment server; a database stored on the payment server; a digital wallet; …) to perform abstract steps/limitations 2-6 mentioned above. The additional element(s) in all of the steps is/are recited at a high-level of generality such that it amounts no more than mere instructions of computers or other machinery merely as a tool to perform/apply the judicial exception(s) of steps/limitations 2-6 mentioned above; thus, they do not integrate the identified abstract idea into a practical application. See MPEP 2106.05(f). Further, in claim 1, the steps 2-4 of receiving, by the payment terminal from the mobile device via the established wireless connection, a payment token (step 2); receiving, by the payment server from the payment terminal: (i) the payment token, (ii) a store or product identifier, and (iii) an amount to be paid (step 3); and retrieving, from a database stored on the payment server, a digital wallet information comprising: one or more bank account data elements, and a loyalty card data element; said digital wallet information being associated with the received payment token, and said loyalty card data element being further associated with the received store or product identifier (step 4)
are merely receiving data/ gathering data which are considered as “insignificant extra solution activity”; thus, they do not integrate the identified abstract idea into a practical application. See MPEP 2106.05(g). Furthermore, the additional element from step 2 of “the mobile device” is merely recited as a source, wherein information is being received from, which is considered as general link to technological environment; thus, does not integrate the identified abstract idea into a practical application. See MPEP 2106.05(h). Accordingly, again, this/these additional element(s) does/do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Again, the claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Again, as discussed above with respect to integration of the abstract idea into a practical application, again, the additional element of using generic computer components (i.e., establishing wireless connection between a payment terminal and a mobile device, said payment terminal being connected to a payment server; the payment terminal; the payment server; a database stored on the payment server; a digital wallet; …….) to perform the steps amounts to no more than mere instructions to apply the exception using a generic computer component. see MPEP 2106.05(f). For the above mentioned reasons, viewed the claim as a whole, the additional elements/additional steps/additional limitations individually and in combination do not integrate the identified abstract idea into a practical application. Furthermore, there is neither improvement to another technology or technical field nor an improvement to the functioning of the computer itself.
Independent claim 1 (step 2B): The additional underlined elements in claim 1 of (i.e., establishing wireless connection between a payment terminal and a mobile device, said payment terminal being connected to a payment server; the payment terminal; the payment server; a database stored on the payment server; a digital wallet; ……) is/are recited at a high level of generality and/or are recited as performing generic computer functions routinely used in the computer applications; thus they are not significantly more than the identified abstract idea. In other word, the underlined additional elements “i.e., establishing wireless connection between a payment terminal and a mobile device, said payment terminal being connected to a payment server; the payment terminal; the payment server; a database stored on the payment server; a digital wallet; …” is/are amounts no more than mere instructions of computers or other machinery merely as a tool to perform/apply the judicial exception(s) of steps/limitations 2-6 mentioned above; thus, they are not significantly more than the identified abstract idea. see MPEP 2106.05(f). Further, in claim 1, the steps 2-4 of receiving, by the payment terminal from the mobile device via the established wireless connection, a payment token (step 2); receiving, by the payment server from the payment terminal: (i) the payment token, (ii) a store or product identifier, and (iii) an amount to be paid (step 3); and retrieving, from a database stored on the payment server, a digital wallet information comprising: one or more bank account data elements, and a loyalty card data element; said digital wallet information being associated with the received payment token, and said loyalty card data element being further associated with the received store or product identifier (step 4) are merely receiving data/ gathering data which are considered as “insignificant extra solution activity”; thus, are not significantly more than the identified abstract idea. See MPEP 2106.05(g). Furthermore, the additional element from step 2 of “the mobile device” is merely recited as a source, wherein information is being received from, which is considered as general link to technological environment; thus, is not significantly more than the identified abstract idea. See MPEP 2106.05(h). Again, the claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
When revaluating the steps 2-4 mentioned above of of receiving, by the payment terminal from the mobile device via the established wireless connection, a payment token (step 2); receiving, by the payment server from the payment terminal: (i) the payment token, (ii) a store or product identifier, and (iii) an amount to be paid (step 3); and retrieving, from a database stored on the payment server, a digital wallet information comprising: one or more bank account data elements, and a loyalty card data element; said digital wallet information being associated with the received payment token, and said loyalty card data element being further associated with the received store or product identifier (step 4) in step 2B here, these gathering data/receiving data are also well-understood, routine and conventional activities. The use of generic computer to receiving data/gathering data through an unspecified generic computer does not impose any meaningful limit on the computer implementation of the abstract idea, and is/are considered as well-understood, routine, conventional activity. According to MPEP 2106.05 (d), elements that the Courts have recognized as well-understood, routine, conventional activity in particular fields are e.g., "Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93”.
Thus, evidences has been provided to show these additional elements are well-understood, routine, conventional activity according to MPEP 2106.07 (a) (III). Therefore, for the above mentioned reasons, viewed as a whole, even in combination, the above additional steps/additional elements/additional limitations do not amount to significantly more/do not provide an inventive concept. Furthermore, there is neither improvement to another technology or technical field nor an improvement to the functioning of the computer itself.
As per independent claim 20: Alice Corp. also establishes that the same/similar analysis should be used for all categories of claims. Therefore, a system claim 1 is also rejected as ineligible subject matter under 35 U.S.C. 101 for substantially the same/similar reasons as the method claim(s) 1. The additional components (i.e., a mobile device; a/the payment terminal; a/the payment server in operative with the payment terminal; wherein each of the mobile device, the payment terminal and the payment server comprises a non-transitory memory module, wherein the modules of program instructions are stored, and at least one processor associated with memory module and configured to execute the modules of program instructions, whereupon execution of said modules of program instructions; the processors of the mobile device and the payment terminal are configured to establish wireless between the payment terminal and the mobile device; a database stored on the payment server, a digital wallet…etc.,) described in independent claim 20 add nothing of substance to the underlying abstract idea. They are merely using as tools to implement the identified abstract idea and/or are general link to technological environment. Thus, are not significantly more than the identified abstract idea. At best, the claim(s) are merely providing an environment to implement the abstract idea.
Dependent claims 1-19 are merely add further details of the abstract steps/elements recited in claim 1 without including an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Please note that the additional elements in claims 5-6, 8-13 of (e.g., a/the user interface (UI) of the payment terminal; a/the first machine-learning (ML)-based model; a/the second machine-learning (ML)-based model) are recited at a high level of generality such that they are merely recited as performing generic computer or other machinery functions routinely used in the computer applications {see MPEP 2106.05(f)}; thus, they do not integrate the identified abstract idea into a practical application and are not significantly more than the identified abstract idea. Therefore, Looking at the limitations as an ordered combinations adds nothing that is not already present when looking at the elements taken individually. Furthermore, there is neither improvement to another technology or technical field nor an improvement to the functioning of the computer itself. Therefore, dependent claims 1-19 are also non-statutory subject matter.
Claim Rejections - 35 USC § 103
7. 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 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.
8. Claims 1-4 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ali et al; (US 2014/0067677 A1) in view of Khan et al; (US 2020/0058047 A1):
9. Claims 1 and 20: Ali teaches a method and system for initiating payment transactions, the system comprising:
a mobile device (limitation 1) {At least paras 0007-0010, 0047, fig. 1 para 0060 in context with paras 0047-0048};
a payment terminal (limitation 2) {e.g., POS in para 0010-0011, 0019-0020, fig. 1 paras 0046, 0054}; and
a payment server (e.g., secure processing server in paras 0019-0020) in operative connection with the payment terminal (limitation 3) {At least paras 0019-0020, fig. 1 paras 0042-0045};
wherein each of the mobile device (see paras 0007-0010, 0047, fig. 1 para 0060 in context with paras 0047-0048), the payment terminal and the payment server comprises a non-transitory memory module, wherein modules of program instructions are stored, and at least one processor associated with the memory module (see at least figs. 1-2 paras 0042-0045), and configured to execute the modules of program instructions, whereupon execution of said modules of program instructions (limitation 4) {At least figs. 1-2 paras 0042-0045};
the processors of the mobile device and the payment terminal are configured to establish wireless connection between the payment terminal and the mobile device (limitation 5) {At least paras 0007, 0010 in context with paras 0019-0020, fig. 1 paras 0042-0047};
the processor of the mobile device is configured to transfer, to the payment terminal, via the established wireless connection (paras 0007-0010, 0047, fig. 1 para 0060 in context with paras 0047-0048), a payment token (e.g., token in paras 0018-0019, 0021, 0023 in context with paras 0096-0097) (limitation 6) {At least paras 0018-0019, 0021, 0023 in context with paras 0096-0097};
the processor of the payment terminal {e.g., POS in para 0010-0011, 0019-0020, fig. 1 paras 0046, 0054} is configured to (limitation 7):
receive, from the mobile device, via the established wireless connection (paras 0007, 0010), the payment token (e.g., token in paras 0018-0019, 0021, 0023 in context with paras 0096-0097, 0140) (limitation 7a) {At least paras 0007, 0010, 0018-0019, 0021, 0023 in context with paras 0096-0097, 0140}; and
transfer, to the payment server: (i) the payment token, (ii) a store or product identifier, and (iii) an amount to be paid (limitation 7b) {At least para 0019 in context with paras 0027, 0055, 0132}; and
the processor of the payment server (e.g., secure processing server in paras 0019-0020, 0131) is configured to (limitation 8):
receive, from the payment terminal: (i) the payment token, (ii) a store or product identifier, and (iii) an amount to be paid (limitation 8a) {At least para 0019 in context with paras 0027, 0055, 0132};
retrieve, from a database stored on the payment server, a digital wallet (e.g., wallet in paras 0017, 0023, 0028, 0056, 0060, 0062, 0091, 0113, 0135) information comprising: one or more bank account data elements (e.g., credit card in para 0019), and a loyalty card data element (e.g., reward and loyalty program/reward card in para 0019) {At least paras 0019 in context with paras 0017-0018, 0023, 0028, 0060, 0062, 0087, 0091, 0113-0114, 0135, 0143}; said digital wallet information being associated with the received payment token {At least paras 0017, 0023, 0091, 0113} (part of limitation 8b) {At least paras 0019 in context with paras 0017-0018, 0023, 0028, 0060, 0062, 0087, 0091, 0113-0114, 0135, 0143};
However, Ali does not explicitly teach the underlined features: the processor of the payment server is configured to:
retrieve, from a database stored on the payment server, a digital wallet information comprising: one or more bank account data elements, and a loyalty card data element, said digital wallet information being associated with the received payment token, and said loyalty card data element being further associated with the received store or product identifier (part of limitation 8b);
recalculate the amount to be paid based on the retrieved loyalty card data element (limitation 8c); and
initiate the payment transaction, using: (i) the recalculated amount to be paid; and (ii) the retrieved one or more bank account data elements (limitation 8d)
Khan teaches:
retrieve, from a database, payment account information comprising: one or more bank account data elements (e.g., payment instrument e.g., payment account, gift card account…etc., in para 0131 in context with fig. 3B paras 0078-0086 and fig. 3E paras 0096-0100, see Cool Pay Card) , and a loyalty card data element (e.g., reward account, loyalty account in para 0131 in context with fig. 3B paras 0078-0086 and fig. 3E paras 0096-0101, see rewards/coupons), and said loyalty card data element being further associated with received store identifier or product identifier (fig. 3B paras 0078-0086, fig. 3E paras 0096-0101, see rewards/coupons associated with products and/or store offers in context with para 0131) (part of limitation 8b) {At least para 0131 in context with fig. 3B paras 0078-0086 and fig. 3E paras 0096-0101};
recalculate the amount to be paid based on the retrieved loyalty card data element (limitation 8c) {At least fig. 3E paras 0096-0100 especially para 0100}; and
initiate the payment transaction, using: (i) the recalculated amount to be paid; and (ii) the retrieved one or more bank account data elements (e.g., payment instrument such as Cool Pay Card in fig. 3E especially para 0100) (limitation 8d) {At least fig. 3E paras 0096-0100 especially para 0100}.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify “retrieve, from a database stored on the payment server, a digital wallet information comprising: one or more bank account data elements, and a loyalty card data element; said digital wallet information being associated with the received payment token” of Li to include “retrieve, from a database, payment account information comprising: one or more bank account data elements, and a loyalty card data element, and said loyalty card data element being further associated with received store or product identifier; recalculate the amount to be paid based on the retrieved loyalty card data element; and initiate the payment transaction, using: (i) the recalculated amount to be paid; and (ii) the retrieved one or more bank account data elements”, taught by Khan. One would be motivated to do this in order to provide merchants with the opportunity to provide loyalty, rewards, promotions, or other enticements to the consumer; provide consumers with the opportunity to make decisions based on such enticements, prior to making the payment or otherwise concluding the transaction, when such transactions are made using a mobile device; provide electronic transaction systems that allow a merchant and a consumer to engage in a high degree of interaction prior to conclusion of the transaction; and perform secure mobile payment transactions with integrated loyalty, rewards, and promotions {Khan: At least para 0007}.
10. Claim 2: The combination of Ali and Khan teaches the claimed invention as in claim 1. The combination further teaches wherein the payment token is a numerical or alphanumerical identification code {Ali: At least paras 0017-0019, 0070-0071, 0201}.
11. Claim 3: The combination of Ali and Khan teaches the claimed invention as in claim 1. The combination further teaches wherein the one or more bank account data elements
comprise a bank account identifier, said bank account identifier selected from a list
consisting of: (i) a credit card number associated with an authorized user of the mobile
device {Ali: At least paras 0017-0023 in context with paras 0010, 0042, 0063}, and also {Khan: At least paras 0130-0134}; (ii) a billing address associated with the authorized user of the mobile device {Ali: At least para 0063}; and (iii) a bank account number associated with the authorized user of the mobile device {Ali: At least paras 0017-0023 in context with paras 0010, 0042, 0063}, and also {Khan: At least paras 0130-0134}.
12. Claim 4: The combination of Ali and Khan teaches the claimed invention as in claim 3. The combination further teaches wherein the digital wallet information {Ali: At least paras 0017-0019, 0023, 0067, 0091, 0095} further comprises a plurality of loyalty card data elements {Ali: At least para 0019 in context with paras 0042-0043, 0058, 0089-0091, 0095, 0139}, containing the loyalty card data element associated with the received store or product identifier {Ali: At least paras 0017-0019, 0089-0091, 0095, 0139 in context with paras 0149-0170}, in context with {Khan: At least fig. 3E paras 0096-0100 especially para 0100 in context with fig. 3B paras 0071-0086}, said plurality of loyalty card data elements being associated with the payment token {Ali: At least paras 0017-0019};
wherein the method further comprises selecting the loyalty card data element associated with the received store or product identifier from the plurality of loyalty card
data elements, based on the received store and product identifier {Khan: At least fig. 3E paras 0096-0100 especially para 0100 in context with fig. 3B paras 0071-0086}.
13. Claims 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ali et al; (US 2014/0067677 A1) in view of Khan et al; (US 2020/0058047 A1), and further in view of Chandrasekaran et al; (US 2015/0324830 A1):
14. Claim 5: The combination of Ali and Khan teaches the claimed invention as in claim 4. The combination further teaches providing, via a user interface (UI) of the payment terminal, a first suggestion data element representing a suggestion of obtaining at least one of: loyalty card data elements; credit card data elements; and bank accounts; based on at least one of: the retrieved digital wallet information/payment information; the amount to be paid (Khan: para 0065); and the store or product identifier (Khan: fig. 2 paras 0059-0065) {Khan: At least fig. 2 paras 0059-0065, fig. 3B paras 0071-0086, fig. 3C paras 0087-0094 and fig. 3E paras 0096-0100}.
However, the combination of Ali and Khan does not explicitly teach the underlined features: “providing, via a user interface (UI) of the payment terminal, a first suggestion data element representing a suggestion of obtaining at least one of: new loyalty card data elements; new credit card data elements; and new bank accounts; based on at least one of: the retrieved digital wallet information; the amount to be paid; and the store or product identifier”.
Chandrasekaran teaches providing, via a user interface (UI), a first suggestion data element representing a suggestion of obtaining at least one of: new loyalty card data elements (e.g., see new/recommended available reward account in paras 0027, 0035, 0051 in context with para 0003); new credit card data elements (e.g., see new/recommended available account in paras 0027, 0035, 0051 in context with para 0003); and new bank accounts (e.g., see new/recommended available account in paras 0027, 0035, 0051 in context with para 0003); based on at least one of: retrieved payment information (paras 0034-0036) or amount spend (para 0032) or product identifier (para 0033) {At least fig 2 paras 0032-0036, 0051 in context with para 0003}.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify “providing, via a user interface (UI) of the payment terminal, a first suggestion data element representing a suggestion of obtaining at least one of: loyalty card data elements; credit card data elements; and bank accounts; based on at least one of: the retrieved digital wallet information/payment information; the amount to be paid; and the store or product identifier” of the combination of Ali and Khan to include “providing, via a user interface (UI), a first suggestion data element representing a suggestion of obtaining at least one of: new loyalty card data elements; new credit card data elements; and new bank accounts; based on at least one of: retrieved payment information or amount spend or product identifier”, taught by Chandrasekaran. One would be motivated to do this in order to present recommended reward cards (e.g., new cards in paras 0027, 0035, 0051) to users to maximize the benefits that users may receive from using the reward cards, and provide various ways of recommending reward cards to users may help users determine what cards to use for what transactions {Chandrasekaran: At least paras 0001-0002 in context with paras 0027, 0035, 0051}.
15. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Ali et al; (US 2014/0067677 A1) in view of Khan et al; (US 2020/0058047 A1), in view of Chandrasekaran et al; (US 2015/0324830 A1), and further in view of Rao et al; (US 2022/0020049 A1):
16. Claim 6: The combination of Ali, Khan, Chandrasekaran teaches the claimed invention as in claim 5. The combination further teaches wherein initiating the payment transaction is further performed based on the calculated one or more cost-effective payment methods {Khan: e.g., payment instrument such as Cool Pay Card in fig. 3E para 0096-0100 especially para 0100 in context with fig. 3B paras 0071-0086, fig. 3C paras 0087-0095}.
However, the combination of Ali, Khan Chandrasekaran does not explicitly teach the underlined features: “inferring, by the payment server, a respectively pretrained first machine-learning (ML)-based model on: the retrieved digital wallet information; the amount to be paid; and the store or product identifier, to calculate one or more cost-effective payment methods,
each comprising at least one of: (i) a combined application of a specific bank account
identifier of the one or more bank account identifiers and a specific loyalty card data
element of the plurality of loyalty card data elements; (ii) a combined application of a
specific bank account identifier of the one or more bank account identifiers and a specific
new loyalty card data element; (iii) a combined application of a specific new bank account
or a specific new credit card data element and a specific loyalty card data element of the
plurality of loyalty card data elements; (iv) a combined application of a specific new bank
account or a specific new credit card data element and a specific new loyalty card data
element; (v) credit, and/or loan, and/or split payments options; and (vi) payment options
involving cryptocurrencies and/or central bank digital currencies (CBDC)”
Rao teaches inferring, by a payment server, a respectively pretrained first machine-learning (ML)-based model on: the retrieved digital wallet information (e.g., payment modes such as mobile wallets in paras 0027, 0030 in context with paras 0020-0026); the amount to be paid (para 0020, fig. 4 para 0042-0046); and the store or product identifier (para 0020, fig. 4 paras 0042-0046), to calculate one or more cost-effective payment methods (e.g. payment mode in para 0020, fig. 4 paras 0042-0046), each comprising at least one of: (i) a combined application of a specific bank account identifier of the one or more bank account identifiers and a specific loyalty card data element of the plurality of loyalty card data elements {At least fig. 4 paras 0042-0046 in context with paras 0020-0026}.
Rao also teaches initiating the payment transaction is further performed based on the calculated one or more cost-effective payment methods (already taught by Khan as mentioned above) {At least fig. 4 paras 0072-0046 especially para 0046}.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify “initiating the payment transaction is further performed based on the calculated one or more cost-effective payment methods” of the combination of Ali, Khan Chandrasekaran to include “inferring, by a payment server, a respectively pretrained first machine-learning (ML)-based model on: the retrieved digital wallet information; the amount to be paid; and the store or product identifier, to calculate one or more cost-effective payment methods, each comprising at least one of: (i) a combined application of a specific bank account identifier of the one or more bank account identifiers and a specific loyalty card data element of the plurality of loyalty card data elements; and initiating the payment transaction is further performed based on the calculated one or more cost-effective payment methods”, taught by Rao. One would be motivated to do this in order to effectively and accurately determine the most optimal payment modes that, if used, for the purchase transaction would provide the maximum benefit not only on monetary terms but also in terms of the user's preferences {Rao: At least para 0001}.
17. Claim 7: The combination of Ali, Khan, Chandrasekaran and Rao teaches the claimed invention as in claim 6. The combination further teaches:
for each of the one or more cost-effective payment methods, calculating confidence metric value, representing a probability of a respective cost-effective payment method of the one or more cost-effective payment methods to have the highest cost effectiveness {Rao: At least fig. 1 paras 0029-0034 in context with fig. 4 paras 0042-0046}; and
initiating the payment transaction further based on a first cost-effective payment method of the one or more cost-effective payment methods, said first cost-effective payment method having a highest calculated confidence metric value {Rao: At least fig. 4 paras 0042-0046 especially para 0046 in context with fig. 1 paras 0029-0034}.
18. Claim 8: The combination of Ali, Khan, Chandrasekaran and Rao teaches the claimed invention as in claim 7. The combination further teaches:
providing, via a user interface (UI) of the payment terminal, a second suggestion data element representing a suggestion of selecting one of the one or more cost-effective payment methods {Khan: At least fig. 3B paras 0071-0086, fig. 3C paras 0087-0094, fig. 3D para 0095 and fig. 3E paras 0096-0100}, also {Chandrasekaran: At least fig. 2 paras 0030-0031, 0035-0036, fig. 3 paras}, and also {Rao: At least fig. 6 para 0048, fig. 7A paras 0048-0050} ;
receiving, via the UI of the payment terminal, a current user response data element representing one of (a) a confirmation of selecting the one of the one or more cost-effective payment methods (Khan: e.g., Cool Pay Card in figs. 3B, 3C, 3D and 3E); and (b) a declination of selecting the one of the one or more cost-effective payment methods {Khan: At least figs. 3C, 3D paras 0087-0095 in context with fig. 3E paras 0096-0100}, and also {Rao: At least At least fig. 6 para 0048, fig. 7A paras 0048-0050 in context fig. 7C para 0052};
receiving, by the payment server from the payment terminal, the current user response data element {Khan: At least figs. 3C, 3D paras 0087-0095 in context with fig. 3E paras 0096-0100}, and also {Rao: At least fig. 7C paras 0052-0054}; and
wherein initiating the payment transaction is further based on the current user response data element {Khan: At least figs. 3C, 3D paras 0087-0095 in context with fig. 3E paras 0096-0100 especially para 0100}, and also {Rao: AT least At least fig. 7C paras 0052-0054 in context with fig. 9 paras 0056}.
19. Claims 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ali et al; (US 2014/0067677 A1) in view of Khan et al; (US 2020/0058047 A1), and further in view of Cao et al; (US 2020/0153821 A1):
20. Claim 14: The combination of Ali and Khan teaches the claimed invention as in claim 3. The combination further teaches:
receiving, by the payment terminal from the mobile device via the established wireless connection (Khan: paras 0041, 0069), a reference authentication data element, uniquely identifying the authorized user of the mobile device (limitation 1) {Khan: At least fig. 4A para 0105 in context with paras 0032-0034, 0130-0134, 0175 especially paras 0032, 0133, 0175};
receiving, via an input module of the payment terminal, an input authentication data element, entered by a current user, said input authentication data element uniquely identifying the current user (limitation 2) {Khan: At least fig. 4A para 0105 in context with paras 0032-0034, 0130-0134, 0175 especially paras 0032, 0133, 0175};
receiving, by the payment server from the payment terminal: (i) the reference authentication data element; and (ii) the input authentication data element (limitation 3) {Khan: At least fig. 4A para 0105 in context with paras 0032-0034, 0130-0134, 0175 especially paras 0032, 0133, 0175};
determining, by the payment server, a similarity, representing the similarity between the reference authentication data element and the input authentication data element (part of limitation 4) {Khan: At least fig. 4A para 0105 in context with paras 0032-0034, 0130-0134, 0175 especially paras 0032, 0133, 0175}; and
wherein initiating the payment transaction further comprises authorizing the payment transaction, based on the similarity (part of limitation 5) {Khan: At least fig. 4A para 0105-0107 in context with paras 0032-0034, 0130-0134, 0175 especially paras 0032, 0133, 0175 and further in context with fig. 4B paras 0114-0119 and fig. 4C paras 0120-0127}.
However, the combination of Ali and Khan does not explicitly teach the underlined features: “
determining, by the payment server, a similarity metric value, representing a degree of similarity between the reference authentication data element and the input authentication data element (part of limitation 4); and
wherein initiating the payment transaction further comprises authorizing the payment transaction, based on the similarity metric value (part of limitation 5).
Cao teaches a general concept of: determining a similarity metric value, representing a degree of similarity between the reference authentication data element and the input authentication data element {At least para 0059}.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify “determining, by the payment server, a similarity, representing the similarity between the reference authentication data element and the input authentication data element; and wherein initiating the payment transaction further comprises authorizing the payment transaction, based on the similarity” of the combination Ali and Khan especially Ali to include “determining a similarity metric value, representing a degree of similarity between the reference authentication data element and the input authentication data element”, taught by Cao so that the combination of Ali, Khan and Cao would yield “……; determining, by the payment server, a similarity metric value, representing a degree of similarity between the reference authentication data element and the input authentication data element; and wherein initiating the payment transaction further comprises authorizing the payment transaction, based on the similarity metric value”. One would be motivated to do this in order to reduce fraudulent, increase security and make the authorization process transparent and auditable.
21. Claim 15: The combination of Ali, Khan and Cao teaches the claimed invention as in claim 14. The combination further teaches: wherein the input module comprises a biometric data capturing module, and wherein the reference authentication data element and the input
authentication data element represent biometric data of the authorized user and the current
user, respectively {Khan: At least paras 0032, 0133, 0175 in context with para 0105}, and also {Cao: At least paras 0059, 0130, 0136}.
22. Claim 16: The combination of Ali, Khan and Cao teaches the claimed invention as in claim 14. The combination further teaches: wherein authorizing a payment transaction, based on the similarity metric value, comprises confirming that the current user is the authorized user, provided that the similarity metric value surpasses a predefined similarity metric threshold value {Cao: At least para 0059}.
23. Claim 17: The combination of Ali, Khan and Cao teaches the claimed invention as in claim 14. The combination further teaches:
receiving, by a merchant bank server (Khan: para 0125-0126) associated with the store or product identifier (Khan: fig. 2 paras 0059-0065), from the payment server, a fund transfer mandate data element, providing permission to request, from one or more user bank servers associated with a respective retrieved one or more bank account identifiers, a fund transfer to a merchant bank account according to the recalculated amount to be paid {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125}; and
initiating, by the merchant bank server, the fund transfer to the merchant bank account according to the fund transfer mandate data element {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125}.
24. Claim 18: The combination of Ali, Khan and Cao teaches the claimed invention as in claim 17. The combination further teaches:
retrieving, from the database stored on the payment server, the fund transfer mandate data element, based on at least one of: (i) the payment token; and (ii) the reference authentication data element {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125};
amending the fund transfer mandate data element to provide permission to the merchant bank server associated with the store or product identifier to request, from one or more user bank servers associated with the respective retrieved one or more bank account identifiers, a fund transfer to the merchant bank account according to the recalculated amount to be paid {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125}; and
transferring, from the payment server to the merchant bank server, the fund transfer mandate data element, provided that the payment transaction is authorized {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125}.
25. Claim 19: The combination of Ali, Khan and Cao teaches the claimed invention as in claim 14. The combination further teaches:
receiving, by one or more user bank servers associated with a respective retrieved one or more bank account identifiers, from the payment server, a fund transfer mandate data element, providing permission to transfer, to a merchant bank account associated with the store or product identifier, funds according to the recalculated amount to be paid {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125};
initiating, by the one or more user bank servers, the fund transfer to the merchant bank account according to the fund transfer mandate data element {Khan: At least fig. 2 paras 0059-0065 in context with fig. 3E paras 0097-0100 especially para 0100 and further in context with fig. 4A paras 0105-0107, fig. 4B paras 0114-0119 and fig. 4C paras 0120-0128 especially para 0125}.
26. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Ali et al; (US 2014/0067677 A1) in view of Khan et al; (US 2020/0058047 A1), and further in view of Paradise et al; (US 2011/0145093 A1):
27. Claim 13: The combination of Ali and Khan teaches the claimed invention as in claim 4. The combination further teaches providing, via a user interface (UI) of the payment terminal, a third suggestion data element {Khan: At least in figs. 3B, 3C, 3D and 3E}.
However, the combination does not explicitly teach the underlined features: “providing, via a user interface (UI) of the payment terminal, a third suggestion data element representing a suggestion of purchasing a new product, based on at least one of: the store or product identifier; and a plurality of store or product identifiers associated with previous transactions.”
Paradise teaches providing, via a user interface, a suggestion data representing a suggestion of purchasing a new product, based on at least one of: product identifiers {At least para 0014 in context with fig. 4A-4B paras 0091-0102 especially para 0093}.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify “providing, via a user interface (UI) of the payment terminal, a third suggestion data element” of the combination of Ali and Khan to include “providing, via a user interface, a suggestion data representing a suggestion of purchasing a new product, based on at least one of: product identifiers”, taught by Paradise. One would be motivated to do this in order to increase the effectiveness of the product advertisement to the user/customer/buyer.
Prior Art that is pertinent to Applicant’s disclosure
28. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
AGRAWAL et al; (US 2025/0285105 A1), wherein teaches A method provides techniques for credit card management. The method includes identifying an intended spend amount for a financial transaction to be paid for via use of one of multiple payment sources within the digital wallet. The method further includes determining, in part based on the intended spend amount, the minimum spending criteria, and the end/renewal data, a preferred payment source from among the multiple payment sources to suggest for use in completing the financial transaction, while maximizing a collective financial benefit of selectively utilizing the multiple payment sources within the digital wallet to complete financial transactions up to and following the end/renewal date. The method continues with presenting, on an output device, an indication to utilize a particular payment source in response to determining that reducing a balance remaining to meet the minimum spending criteria is a best option to maximize the collective financial benefit.
Singh et al; (US 2023/0206237 A1), wherein teaches A system receives a remote pay authorization request message from a first consumer. The message includes a transaction token with transaction details. The system also receives first user mapping data from a first issuer. The mapping data includes a unique ID corresponding to a second consumer (i.e., a paying consumer). The system receives a second remote pay authorization request message from the second consumer. The message includes a payment token that includes consumer payment account data. The system also receives second user mapping data from a second issuer. The second user mapping data includes the unique ID. The system determines that the unique ID is included in the first and second user mapping data. The system merges the transaction token and the payment token into a combined payment token, thereby enabling the second consumer to pay for a transaction performed by the first consumer.
Jones; (US 2021/0224789 A1), wherein teaches A system has a datastore including a pro-rata digital wallet associated with a cardholder. The pro-rata digital wallet includes two or more payment card accounts. The system includes a processor programmed to receive an authorization request message from a point-of-sale terminal. The authorization request includes an identification number from a transaction device presented by the cardholder. The processor is programmed to determine whether the identification number corresponds to one of the payment card accounts associated with the pro-rata digital wallet and, if so, identify each of the payment card accounts associated with the pro-rata digital wallet. The processor is programmed to determine a pro-rata payment amount for each of the payment card accounts associated with the pro-rata digital wallet. Each pro-rata payment is based on an available balance of each of the payment card accounts relative to a total available balance for a combination of each of the payment card
BEN-AVI et al; (US 2024/0289768 A1), wherein teaches A system, apparatus and a method for purchasing goods with a digital wallet application is disclosed. The digital wallet application is configured to perform a payment from a user digital wallet module by a near field communication (NFC) radio of a mobile device. The mobile application is configured to upload a first token with a user creditability to the user digital wallet to enable a purchase, receive from the user digital wallet module a request for an amount of payment, receive approval for the payment from a user server and transfer the amount of payment to a merchant, remove the first token from the user digital wallet module; and upload a second token with the user creditability information for use in the next purchase, wherein the second token comprises a different identification code than the first token.
Mo et al; (US 8,396,794 B1), wherein teaches A method for performing a financial transaction that includes identifying a plurality of payment options associated with a payer executing the financial transaction, wherein each of the plurality of payment options is linked to a financial account of the payer, obtaining cost data and benefit data for each of the plurality of payment options, wherein the cost data includes a cost of using the payment option for the financial transaction and the benefit data includes a benefit of using the payment option for the financial transaction, selecting a preferred payment option from the plurality of payment options for the financial transaction based on the cost data and the benefit data, and processing the financial transaction using the preferred payment option to obtain a transaction confirmation.
Further, see additional references cited in PTO-892.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Thuy Nguyen whose telephone number is 571-272-4585 and fax number is 571-273-4585. The examiner can normally be reached on Mon-Thurs, 8:30 am to 5: 00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Ilana Spar can be reached on 571-270-7537. The FAX 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.
/THUY N NGUYEN/
Primary Examiner, Art Unit 3622.
Prosecution Insights