DETAILED ACTION
Status of the Application
Claims 1-20 are pending and currently under consideration for patentability under 37 CFR 1.104.
Priority
The instant application has a filing date of June 10, 2025, and claims for the benefit of prior-filed provisional application # 63/648,254, which was filed on May 16, 2024. Applicant’s claim for the benefit of the prior-filed provisional application is acknowledged, in view of the Petition Decision mailed February 17, 2026.
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 .
Claim Objections
Claim 1 is objected to because of the following informalities: --and-- should be inserted subsequent “one or more goods and services;” to ensure the claim language conforms with standard grammatical construction.
Claim 8 is objected to because of the following informalities: --available-- should be deleted in the phrase “using the highest-ranked available payment method” to maintain consistency of terminology throughout the claims (the claim previously refers to a ranked list of payment methods and selecting payment methods).
35 U.S.C. § 112 (f) or pre-AIA 35 U.S.C. § 112, sixth paragraph
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“an analysis module for determining an optimal payment method using one or more financial metrics” recited in claims 1 and 2 (as well as dependent claims 3-7 by association).
“further comprising an account linking module that securely connects to third-party financial services using tokenized API protocols” recited in claim 4.
“further comprising a learning module that refines future payment selections based on historical user behavior and reward optimization outcomes” recited in claim 15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
v Claim(s) 1-20 is/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.
Step 1:
Claim(s) 8-15 is/are drawn to methods (i.e., a process), claim(s) 1-7 is/are drawn to systems (i.e., a machine/manufacture), and claim(s) 16-20 is/are drawn to non-transitory computer readable storage medium (i.e., a machine/manufacture). As such, claims 1-20 is/are drawn to one of the statutory categories of invention (Step 1: YES).
Step 2A - Prong One:
In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Claim 1 (representative of independent claim(s) 8 and 16) recites/describes the following steps;
analyzing and determining an optimal method of payment
permit the user to select one or more goods and services;
determining an optimal payment method using one or more financial metrics
These steps, under its broadest reasonable interpretation, describe or set-forth a process for optimizing and selecting an optimal payment method for use for the purchase of one or more selected goods or services. This process amounts to a a commercial or legal interactions (specifically, an advertising, marketing or sales activity or behavior). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas.
Additionally, and/or alternatively, each of the above-recited steps/functions, under their broadest reasonable interpretation, encompass a human manually (e.g., in their mind, or using paper and pen) performing one or more concepts performed in the human mind, such as one or more observations, evaluations, judgments, opinions, but for the recitation of generic computer components. If one or more claim limitations, under their broadest reasonable interpretation, covers performance of the limitation(s) in the mind but for the recitation of generic computer components, then it falls within the “mental processes” subject matter grouping of abstract ideas.
As such, the Examiner concludes that claim 1 recites an abstract idea (Step 2A – Prong One: YES).
Independent claim(s) 8 and 15 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
Each of the depending claims likewise recite/describe these steps (by incorporation - and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis. Any element(s) recited in a dependent claim that are not specifically identified/addressed by the Examiner under step 2A (prong two) or step 2B of this analysis shall be understood to be an additional part of the abstract idea recited by that particular claim. The same reasoning is similarly applicable to the limitations in the remaining dependent claims, and their respective limitations are not reproduced here for the sake of brevity.
Step 2A - Prong Two:
In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The claim(s) recite the additional elements/limitations of
“a system… at least one user computing device in operable connection with a user network; an application server in operable communication with the user network, the application server configured to host an application program for.. the application program having a user interface module for providing access to the application program via the at least one user computing device; comprising an analysis module for…and an analysis module for…” (claim 1)
“…for online purchases…an online marketplace to permit the user to select one or more goods and services…” (claim 1)
“wherein the analysis module applies…” (claim 2)
“wherein the application program further comprises a dashboard interface for displaying…” (claim 3)
“…an account linking module that securely connects to third-party financial services using tokenized API protocols” (claim 4)
“wherein the online marketplace comprises a third-party website, e-commerce platform, or in-store mobile point-of-sale system” (claim 6)
“at least one user computing device in operable connection with a user network…from a user device…” (claim 8)
“wherein the transaction data is received from an in-store mobile wallet or NFC-enabled point-of-sale interface” (claim 13)
“a learning module that…” (claim 15)
“a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the system to perform operations comprising: providing a user interface for inputting…via an API...” (claim 16)
“wherein the instructions further cause the system to…” (claim 17)
“…wherein the user interface enables…” (claim 19)
“…further comprising instructions to…” (claim 20)
The requirement to execute the claimed steps/functions using “a system… at least one user computing device in operable connection with a user network; an application server in operable communication with the user network, the application server configured to host an application program for.. the application program having a user interface module for providing access to the application program via the at least one user computing device; comprising an analysis module for…and an analysis module for…” (claim 1) and/or “wherein the analysis module applies…” (claim 2) and/or “wherein the application program further comprises a dashboard interface for displaying…” (claim 3) and/or “…an account linking module that securely connects to third-party financial services using tokenized API protocols” (claim 4) and/or “at least one user computing device in operable connection with a user network…from a user device…” (claim 8) and/or “a learning module that…” (claim 15) and/or “a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the system to perform operations comprising: providing a user interface for inputting…via an API...” (claim 16) and/or “wherein the instructions further cause the system to…” (claim 17) and/or “…further comprising instructions to…” (claim 20) is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. Applicant’s own disclosure explains that these “additional” elements may be embodied as a general-purpose computer (e.g., the published specification at paragraphs [0050] “include both general and special purpose microprocessors”, [0100]-[0103] “The computer readable program instructions can be provided to a processor of a general purpose computer”, [0047] “The computer system 100 comprises a standalone computer or mobile computing device, a mainframe computer system, a workstation, a network computer, a desktop computer, a laptop, or the like. The computing device 100 can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player”, see also [0003] & [0056]-[0062] ). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
The recited additional element(s) of “…for online purchases…an online marketplace to permit the user to select one or more goods and services…” (claim 1) and/or “wherein the online marketplace comprises a third-party website, e-commerce platform, or in-store mobile point-of-sale system” (claim 6) and/or “at least one user computing device in operable connection with a user network…from a user device…” (claim 8) and/or “wherein the transaction data is received from an in-store mobile wallet or NFC-enabled point-of-sale interface” (claim 13) and/or “…wherein the user interface enables…” (claim 19) serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computing environments, such as distributed computing environments and/or the internet, where information is represented digitally, exchanged between computers over a network, and presented using graphical user interfaces. It also serves merely to limit the transaction to certain digital/electronic environments for conducting transactions. This reasoning was demonstrated in Bilski, where it was determined that certain claim elements limiting the basic concept of hedging to commodities and energy markets (merely limiting an abstract idea to one field of use) did not make the concept patentable. This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(g)).
Furthermore, although the claims recite a specific sequence of computer-implemented functions, and although the specification suggests certain functions may be advantageous for various reasons (e.g., business reasons), the Examiner has determined that the ordered combination of claim elements (i.e., the claims as a whole) are not directed to an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and do not amount to a technology-based solution to a technology-based problem. For example, Applicant’s published specification suggests that it is advantageous to implement the claimed business process because doing so can reduce the time and effort needed for a customer to identify a payment method that may be most beneficial to them (e.g., financially and/or preferentially). It can also reduce error when performing such an identification. (see, for example, Applicant’s published disclosure at paragraphs [0004]-[0005], [0008], and [0011]). These are non-technical business advantages/improvements. At most, the ordered combination of claim elements is directed to a non-technical improvement to an abstract idea itself (e.g., an improved process for optimizing and selecting an optimal payment method for use for the purchase of one or more selected goods or services).
Dependent claims 5, 7, 9-12, 14, and 18 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 5, 7, 9-12, 14, and 18 is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim). For example, claim 5 recites “wherein the financial metrics include user-defined maximum utilization thresholds per payment method”. This is an abstract limitation which further sets forth the abstract idea encompassed by claim 5. This limitation is not an “additional element”, and therefore it is not subject to further analysis under Step 2A- Prong Two or Step 2B. The same logic applies to each of the other dependent claims, whose limitations are not being repeated here for the sake of brevity and clarity. With respect to the other dependent claims not specifically listed here - each of the limitations/elements recited in these dependent claims other than those identified as being “additional” elements above (at the beginning of the Prong One analysis), are further part of the abstract idea encompassed by each respective dependent claim (i.e. it should be understood that these limitations are part of the abstract idea recited in each respective claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B:
In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966)
As discussed above in “Step 2A – Prong 2”, the requirement to execute the claimed steps/functions using “a system… at least one user computing device in operable connection with a user network; an application server in operable communication with the user network, the application server configured to host an application program for.. the application program having a user interface module for providing access to the application program via the at least one user computing device; comprising an analysis module for…and an analysis module for…” (claim 1) and/or “wherein the analysis module applies…” (claim 2) and/or “wherein the application program further comprises a dashboard interface for displaying…” (claim 3) and/or “…an account linking module that securely connects to third-party financial services using tokenized API protocols” (claim 4) and/or “at least one user computing device in operable connection with a user network…from a user device…” (claim 8) and/or “a learning module that…” (claim 15) and/or “a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the system to perform operations comprising: providing a user interface for inputting…via an API...” (claim 16) and/or “wherein the instructions further cause the system to…” (claim 17) and/or “…further comprising instructions to…” (claim 20) is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(f)).
As discussed above in “Step 2A – Prong 2”, the recited additional element(s) of “…for online purchases…an online marketplace to permit the user to select one or more goods and services…” (claim 1) and/or “wherein the online marketplace comprises a third-party website, e-commerce platform, or in-store mobile point-of-sale system” (claim 6) and/or “at least one user computing device in operable connection with a user network…from a user device…” (claim 8) and/or “wherein the transaction data is received from an in-store mobile wallet or NFC-enabled point-of-sale interface” (claim 13) and/or “…wherein the user interface enables…” (claim 19) serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(g)).
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer, and generally link the abstract idea to a particular technological environment or field of use.
Dependent claims 5, 7, 9-12, 14, and 18 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 5, 7, 9-12, 14, and 18 is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea identified by the Examiner to which each respective claim is directed).
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are 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 the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
v Claims 1 and 8 recite the phrase "the user." There is insufficient antecedent basis for this limitation in the claim. The claims previously refer to at least one user computing device and a user network and a user interface module. However, none of these elements technically provides antecedent basis support for a/the user itself. Examiner notes claims 3, and 11, and 18 also refer to the user (or the user’s), which similarly lacks sufficient antecedent basis. For the purpose of examination, the phrase “the user” in each of claims 1, 8, and 18 will be interpreted as being “a user.”
Each of dependent claims 2-7 and 9-15 are similarly rejected by virtue of their dependency on one of these claims.
v Claim 8 requires “analyzing the transaction data against user-defined preferences and one or more financial metrics comprising credit availability, utilization limits, and reward structures” and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The claim explicitly states that the transaction data is analyzed against one or more financial metrics (which could be only one) but then states that the one or more financial metrics comprise three different metrics the one or more metrics comprise. It is unclear how a single metric could comprise three different metrics and/or whether or not the claim language is requiring the transaction data to be analyzed against all three of these metrics. Therefore, the claim is indefinite for failing to particularly and distinctly claim the subject matter which the application regards as the invention. For the purpose of examination, the phrase “analyzing the transaction data against user-defined preferences and one or more financial metrics comprising credit availability, utilization limits, and reward structures” will be interpreted as being “analyzing the transaction data against user-defined preferences and one or more financial metrics comprising credit availability, utilization limits, and/or reward structures”
Each of dependent claims 9-15 are similarly rejected by virtue of their dependency on this claim.
v Claim 14 states “wherein reward yield is determined based on current vendor eligibility, purchase category, and reward program rules” and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Neither claim 8 nor claim 14 includes a step of determining reward yield. There is no antecedent basis for “reward yield”. It is unclear whether or not this limitation is intending on setting forth a new step of the claimed method, or whether this is merely descriptive of how reward yield is determined when one decides to determine reward yield. Therefore, the claim is indefinite for failing to particularly and distinctly claim the subject matter which the application regards as the invention. For the purpose of examination, the phrase “wherein reward yield is determined based on current vendor eligibility, purchase category, and reward program rules” will be interpreted as being “further comprising a step of determining reward yield for each payment method, wherein reward yield is determined based on current vendor eligibility, purchase category, and reward program rules”
v Claims 16 and 17 recites the phrase "the system." There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, the phrase “non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the system to perform operations comprising” will be interpreted as being “non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising.”
Each of dependent claims 18-20 are similarly rejected by virtue of their dependency on this claim.
v Claim 16 recites the phrase "the calculated metrics." There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, the phrase “the calculated metrics” will be interpreted as being “the calculated utilization percentages and reward yields.”
Each of dependent claims 17-20 are similarly rejected by virtue of their dependency on this claim.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
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.
v Claims 1, 2, 5-9, 11, and 13-15 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Goodwin (U.S. PG Pub No. 2014/0129357, May 8, 2014 - hereinafter "Goodwin”)
With respect to claim 1, Goodwin teaches a system for optimizing and automating the selection of a payment method used for online purchases ([0025]), comprising:
at least one user computing device in operable connection with a user network; ([0025]-[0026] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant. The user includes a customer or any individual who owns one or more payment options from a variety of financial institutions or payment card providers. The electronic device includes a mobile phone, portable electronic device, or the like…payment decision engine 102 may be available to the user's electronic device, either as a software application resided locally on the electronic device or located remotely over a data connection” – customer mobile device with local mobile app in connection with user network, see also [0070] & [0029] & [0048] & [0057])
an application server in operable communication with the user network, the application server configured to host an application program for analyzing and determining an optimal method of payment, ([0025]-[0026] “The intelligent payment system 100 comprises…The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant. The user includes a customer or any individual who owns one or more payment options from a variety of financial institutions or payment card providers. The electronic device includes a mobile phone, portable electronic device, or the like…payment decision engine 102 may be available to the user's electronic device, either as a software application resided locally on the electronic device or located remotely over a data connection… server side logic module 105 which runs on a remote server…the data exchange between the user's electronic device and the remote server can be carried out through communication means, preferably wireless communication means, such as 3rd generation mobile telecommunications (3G), Wi-Fi or the like...a local application that includes a user-specific profile created on the user's electronic device or a web portal.” – therefore the application functionality of the payment decision engine may be implemented at the user device via accessing a server hosting this software (i.e., an application server in operable communication with the user network and configured to host an application program for analyzing and determining an optimal method of payment), [0028]-[0029] “server side logic module”, [0071]-[0072] “remote server to determine at least one payment method (e.g., a preferred, recommended, expected best, or expected most suitable method) for the transaction under consideration”, see also [0048] & [0057]))
the application program having a user interface module for providing access to the application program via the at least one user computing device; ([0026] “The intelligent payment system 100 comprises…a direct user interface 109…The direct user interface 109 is a local application that includes a user-specific profile created on the user's electronic device or a web portal. The user accesses the direct user interface 109 and inputs all the data and information into the user-specific profile as required by the intelligent payment system 100. The direct user interface 109 operably communicates with the server side logic module 105 and the stored data module 108 to provide the data and information. The user interface 109 is also used for user prompted input”, [0057]-[0059] “communicates with the user through the direct user interface 109”)
an online marketplace to permit the user to select one or more goods and services; ([0025] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant….The merchant may include a Point of Sale (PoS) merchant (e.g. restaurants, clothing store), an online merchant (e.g. blogshops, online stores) or a payment intermediary. The point of sale may refer to a retail premise or location, an electronic retailer such as a web site…”, [0058] “goods and services to be provided”, [0164], [0052])
an analysis module for determining an optimal payment method using one or more financial metrics ([0072] “ the server side logic module 105 determines the best payment method for the present transaction in association with a payment method selection process, which considers information or data including transaction related information (e.g., transaction amount, date/time, and type), merchant related information, user-defined type criteria, server defined type criteria, and possibly other information to determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user” determines best payment method based on one or more financial metrics (benefit amount, expected cost, etc.,), [0025]-[0026] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant. The user includes a customer or any individual who owns one or more payment options from a variety of financial institutions or payment card providers….payment decision engine 102 may be available to the user's electronic device, either as a software application resided locally on the electronic device or located remotely over a data connection” – customer mobile device with local mobile app in connection with user network, [0036]-[0038] “The payment evaluation criteria are assessed to assist the payment decision engine 102…the user may define many criteria to assist in the payment decision….As the user inputs more data, the evaluation of the type of payment method suggested to the user will be better. The user-defined type criteria may include but not limited to the following: available payment methods; available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit…a preference to use a payment method to maximize a credit score (e.g. to use payment methods that support credit scores);” – therefore the payment decision module (analysis module) determines an optimal payment method based on user-defined criteria including available credit/balance limits on the payment methods (one or more financial metrics), see also [0046] & [0066]-[0067] & [0076]-[0095])
With respect to claim 2, Goodwin teaches the system of claim 1;
wherein the analysis module applies a weighted scoring algorithm that assigns value to reward points, cashback potential, and credit utilization ([0037]-[0038] “available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit; a preferred reward type, such as mileage points, cash back rebate, etc….a preference to use a payment method that has a most value for money, wherein the most value for money is determined based on a scoring evaluation by the server side logic module 105;” – therefore user defined criteria include rewards point preferences, cashback potential preferences and credit utilization preferences, [0076]-[0095] “User preferences can also be an input variable into the comparative decision process. For example, a user may prefer to collect American Airlines miles to British Airways (BA) miles, so the American Airlines miles may be associated with or given a multiplier weighting in a rule set. For example, a weighting of 120% may be applied to a certain loyalty point to artificially modify the scoring process to a certain user preferred reward…one or more modifiers…in addition to valuing reward points and modifying the weighting of results based on user-defined type criteria and/or other criteria, additional criteria can be included…one or more modifiers applied thereto…” – weighted algorithm, [0075] “cash back offer”)
With respect to claim 5, Goodwin teaches the system of claim 1;
wherein the financial metrics include user-defined maximum utilization thresholds per payment method ([0037]-[0038] “The payment evaluation criteria are assessed to assist the payment decision engine 102…the user may define many criteria to assist in the payment decision…The user-defined type criteria may include but not limited to the following: available payment methods; available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…a preference to use a payment method to maximize a credit score (e.g. to use payment methods that support credit scores);” – therefore the financial metrics include user-defined maximum utilization thresholds per payment method (credit/balance limits on the payment methods))
With respect to claim 6, Goodwin teaches the system of claim 1;
wherein the online marketplace comprises a third-party website, e-commerce platform, or in-store mobile point-of-sale system ([0025] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant….The merchant may include a Point of Sale (PoS) merchant (e.g. restaurants, clothing store), an online merchant (e.g. blogshops, online stores) or a payment intermediary. The point of sale may refer to a retail premise or location, an electronic retailer such as a web site…” – therefore the online marketplace comprises a third-party website and/or e-commerce platform and/or or in-store mobile point-of-sale system, see also [0049]-[0050] & [0047])
With respect to claim 7, Goodwin teaches the system of claim 1;
wherein the optimal payment method is selected based on at least one of: reward point valuation, loyalty tier progression, or promotional interest rates [0072] “ the server side logic module 105 determines the best payment method for the present transaction in association with a payment method selection process, which considers information or data including transaction related information (e.g., transaction amount, date/time, and type), merchant related information, user-defined type criteria, server defined type criteria, and possibly other information to determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user” - the optimal payment method is selected based on at least reward point valuation, see also & [0076]-[0095] for reward point valuation and loyalty tier progression)
With respect to claim 8, Goodwin teaches a method for automatically selecting a payment method for a transaction, the method comprising the steps of;
at least one user computing device in operable connection with a user network; ([0025]-[0026] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant. The user includes a customer or any individual who owns one or more payment options from a variety of financial institutions or payment card providers. The electronic device includes a mobile phone, portable electronic device, or the like…payment decision engine 102 may be available to the user's electronic device, either as a software application resided locally on the electronic device or located remotely over a data connection” – customer mobile device with local mobile app in connection with user network, see also [0070] & [0029] & [0048] & [0057])
receiving transaction data from a user device, ([0048] “transaction detail…The source of identification may be directly in-line with the Internet browser interaction, or by the user defining a transaction detail, this may include such detail as retailed information, value of transaction and the date the payment will be made, prior to the suggestion of the preferred payment method. The server side client implements the server side logic module 105 as a "payment processor" service. A payment method selection is made by the user as a "payment logic" service, and the server side logic module 105 interacts with the server over a secure connection to identify the user and the PoS information. This creates a rule set result calculation of the end result that is returned to the user or to the Internet website directly. Further, payment details that may be required by the user or the Internet website may also be completed. This is similar to the interaction between the user's electronic device and the server side logic module 105 as discussed earlier”, [0070]-[0072] “remote server to determine at least one payment method (e.g., a preferred, recommended, expected best, or expected most suitable method) for the transaction under consideration”, see also [0057]-[0058])
the transaction data including cost, vendor, and item description; ([0058] “The PoS Data includes information on a merchant, a user's location, and a payment transaction detail. In step 311, the information is collected on the merchant including such details as the merchant's name and merchant number. In step 312, the user's location may include such details as a country or other geographical data. In step 313, the payment transaction detail includes the payment transaction amount, and a type of goods and/or services to be provided. In step 314, a payment profile data including all the information from steps 310-313 is provided in a Point of Sale profile”, [0048] “transaction detail…The source of identification may be directly in-line with the Internet browser interaction, or by the user defining a transaction detail, this may include such detail as retailed information, value of transaction and the date the payment will be made, prior to the suggestion of the preferred payment method.”, [0042] “ In the merchant information, the information includes name of the merchant and the type of the merchant's business”, [0070]-[0072] transaction amount and merchant, [0090] “The merchant or PoS may provide information on the contents of the transaction, such as the item description(s) or item brand(s)”)
accessing a plurality of stored payment account profiles linked to the user; ([0059]-[0060] “The data inputs are obtained from the server-side…the payment methods include the various types of payment, credit or debit cards, electronic ticketing or vouchers etc available to the user…a payment option profile data that includes all the information from steps 315-318 is provided…provided to the intelligent payment system”, [0035] “the stored data module…available payment cards…available credit or balance limits on the payment methods”, [0074], foreign transaction charge/fee or certain exchange rate. Such charges can differ by payment option, payment card provider…card brand…card fee...”, [0081]-[0083] “ user and payment options available…what corresponding valid payment options does the user presently have available to them?”)
analyzing the transaction data against user-defined preferences and one or more financial metrics comprising credit availability, utilization limits, and reward structures; ([0076] – user defined preferences for reward structures, [0072 ] against one or more financial metrics comprising reward structures, [0025]-[0026] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant. The user includes a customer or any individual who owns one or more payment options from a variety of financial institutions or payment card providers….payment decision engine 102 may be available to the user's electronic device, either as a software application resided locally on the electronic device or located remotely over a data connection” – customer mobile device with local mobile app in connection with user network, [0036]-[0038] “The payment evaluation criteria are assessed to assist the payment decision engine 102…the user may define many criteria to assist in the payment decision….As the user inputs more data, the evaluation of the type of payment method suggested to the user will be better. The user-defined type criteria may include but not limited to the following: available payment methods; available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit…a preference to use a payment method to maximize a credit score (e.g. to use payment methods that support credit scores);” – one or more financial metrics comprising credit availability and/or utilization limits, see also [0046] & [0066]-[0067] & [0071]-[0072] & & [0076]-[0095])
determining a ranked list of payment methods based on the analysis; and ([0061]-[0062] “The intelligent payment system 100 processes the payment methods available and lists the payment methods accordingly in step 320…”, [0066] “step 335, intelligent scoring of the payment methods according to the plurality of payment evaluation criteria is provided.”, [0072] “ the server side logic module 105 determines the best payment method for the present transaction in association with a payment method selection process, which considers information or data including transaction related information (e.g., transaction amount, date/time, and type), merchant related information, user-defined type criteria, server defined type criteria, and possibly other information to determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user”, [0078] “such a payment method selection process can provide an automatically determined or user selectable result or output (e.g., corresponding to the identification of a preferred/best payment method and/or a relative comparison, ranking, or scoring of available payment methods)”, see also [0094]-[0096])
automatically selecting and initiating the transaction using the highest-ranked available payment method ([0052]-[0054] “ the intelligent payment system 100 determines which payment method should be suggested to the user in step 205. This can then be executed automatically, or may be used in conjunction with the input from the user, depending on preferences set…a preferred payment method in the list of preferred payment method from step 208 can be identified as a best payment method, the intelligent payment system 100 automatically chooses the preferred payment method in step 211. After the user has manually approved a payment method in step 210, or after the intelligent payment system 100 automatically chooses the payment method in step 211, the payment method is selected in step 212 and used to execute the payment”, see also [0046] & [0061]-[0062], [0078] “such a payment method selection process can provide an automatically determined or user selectable result or output (e.g., corresponding to the identification of a preferred/best payment method and/or a relative comparison, ranking, or scoring of available payment methods”)
With respect to claim 9, Goodwin teaches the method of claim 8;
further comprising the step of applying a service fee to the selected payment method and routing the fee to a linked user account ([0074] “a transaction or payment card financial institution may be overseas so one or more possible available payment methods may be charged a foreign transaction charge/fee or a certain exchange rate. Such charges can differ by payment option, payment card provider, financial institution, or card brand. Also, a transaction at a given merchant may attract a card fee, for example, a 0% fee for cash, voucher, coupon or debit card; a 2% fee for Visa; a 2.5% fee for MasterCard; and a 5% fee for American Express.”, [0093]-[0094] & [0103]-[0104])
Examiner notes that although Goodwin teaches a broadest reasonable interpretation of this limitation, prior art references Rajagopal and Rowe (cited at the end of this action) also disclose wherein the mobile app provider (i.e., the system that facilitates the determination and recommendation of the optimal payment method) also charges its own service fee.
With respect to claim 11, Goodwin teaches the method of claim 8;
further comprising displaying to the user a list of ranked payment options prior to transaction execution ([0072] “ the server side logic module 105 determines the best payment method for the present transaction in association with a payment method selection process, which considers information or data including transaction related information (e.g., transaction amount, date/time, and type), merchant related information, user-defined type criteria, server defined type criteria, and possibly other information to determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user”, [0061]-[0062] “The intelligent payment system 100 processes the payment methods available and lists the payment methods accordingly in step 320…If the user prefers to assist in the payment method selection, user is asked if the payment method recommended by the intelligent payment system 100 is acceptable in step 323. If the payment method recommended is not acceptable to the user, step 324 asks if the next payment method option in the list of payment methods from step 320 is to be shown, or if a payment method from the list of payment methods is to be manually selected. If the user prefers to manually select a payment method from the list of payment methods, the manually selected payment method is then sent to the merchant in step 322…”, per [0066] “step 335, intelligent scoring of the payment methods according to the plurality of payment evaluation criteria is provided.”, [0078] “such a payment method selection process can provide an automatically determined or user selectable result or output (e.g., corresponding to the identification of a preferred/best payment method and/or a relative comparison, ranking, or scoring of available payment methods)”, [0095]-[0102])
With respect to claim 13, Goodwin teaches the method of claim 8;
wherein the transaction data is received from an in-store mobile wallet or NFC-enabled point-of-sale interface ([0025]-[0026] “The payment method is used for a payment transaction initiated by the user with a merchant….The merchant may include a Point of Sale (PoS) merchant (e.g. restaurants, clothing store), an online merchant (e.g. blogshops, online stores) or a payment intermediary. The point of sale may refer to a retail premise or location, an electronic retailer such as a web site…The merchant-to-processor module 101 is generally located at the merchant side and communicates with the payment decision engine 102 through the user's electronic device. It is desired that the payment decision engine 102 residing in the user's electronic device and the merchant-to-processor module 101 communicate through a wireless communications, such as near field communication (NFC) technology or the like” – NFC-enabled POS interface, [0049]-[0052] “ payment points adapted with a wireless technology such as NFC via the electronic device… intelligent payment system 100 is activated when the user initiates the payment transaction via the electronic device at the merchant's point of sale counter. The payment transaction can be activated by placing the electronic device close to the merchant-to-processor module 101 so that the electronic device can communicate with the merchant-to-processor module 101 through NFC….”, see also [0005])
With respect to claim 14, Goodwin teaches the method of claim 8;
wherein reward yield is determined based on current vendor eligibility, purchase category, and reward program rules ([0072] “ determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user” – therefore the system can determine reward yield for each payment method which is necessarily based on reward program rules specifying how rewards/befits would yield rewards for a transaction, [0075] “loyalty point offer for the merchant and a loyalty point modifier for a partner…1.5 miles per USD…at an American Airlines site…specific to retail locations” – current vendor eligibility, [0092] “ [0092] (i) Are there any partner offers or affiliations, such as "Double BA air miles at BP petrol/gas stations"” – purchase category, see also [0078]-[0081])
With respect to claim 15, Goodwin teaches the method of claim 8;
further comprising a learning module that refines future payment selections based on historical user behavior and reward optimization outcomes ([0036]-[0037] “Data and information may further be provided by various sources (e.g. remote server, direct user interface 109, etc.)…The payment evaluation criteria are assessed to assist the payment decision engine 102 and passed to the server side logic module 105. The data may include transaction data, merchant data, payment method acceptance data or instances of user interaction with the payment decision on the electronic device (e.g., when a user selects to override or intervene with the recommended payment selection)” – therefore historic acceptance/overrides are used as evaluation criteria to help assist the payment decision engine to make/learn preferred payment methods for subsequent transactions, [0056] “Once the payment method selected is accepted, the payment method selected is processed with the merchant to complete the payment transaction in step 214. Thereafter, the intelligent payment system 100 stores the payment method selected as an analytics data in step 215, and also records information regarding any user interaction or payment method failures that occurred so that the information can be used by the server side logic module 105. This data is stored in the stored data module 108 and passed back to the server side logic module 105 when appropriate.”, [0104] – reward optimization outcomes, see also [0152] & [0065])
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
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.
v Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Goodwin (U.S. PG Pub No. 2014/0129357, May 8, 2014 - hereinafter "Goodwin”) in view of Rittman et al. (U.S. PG Pub No. 2022/0335519, October 20, 2022 - hereinafter "Rittman”)
With respect to claim 3, Goodwin teaches the system of claim 1. Goodwin does not appear to disclose,
wherein the application program further comprises a dashboard interface for displaying the user's total available credit, reward balances, and transaction history
However, Rittman discloses
wherein the application program further comprises a dashboard interface for displaying the user's total available credit, reward balances, and transaction history (Fig 13 and corresponding [0047]-[0051] & [0054]-[0055] shows dashboard interface in the mobile app that enables the user to see the user’s total available credit and reward balances and transaction history associated with the user’s linked credit cards)
Rittman suggests it is advantageous to include wherein the application program further comprises a dashboard interface for displaying the user's total available credit, reward balances, and transaction history, because doing so can increase user convenience/satisfaction by providing them with information regarding all of the linked payment methods/accounts ([0021] & [0027])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Goodwin to include wherein the application program further comprises a dashboard interface for displaying the user's total available credit, reward balances, and transaction history, as taught by Rittman, because doing so can increase user convenience/satisfaction by providing them with information regarding all of the linked payment methods/accounts.
v Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Goodwin (U.S. PG Pub No. 2014/0129357, May 8, 2014 - hereinafter "Goodwin”) in view of Wu (U.S. PG Pub No. 2017/0193485, July 6, 2017 - hereinafter "Wu”)
With respect to claim 4, Goodwin teaches the system of claim 1;
further comprising an account linking module that connects to third-party financial services ([0027] “The server side logic module 105 may have data communication with the financial institutions to acquire updates on variables that affect payment choices”)
Goodwin does not appear to disclose,
securely connects to third-party financial services using tokenized API protocols
However, Wu discloses
securely connects to third-party financial services using tokenized API protocols ([0021] “payment ranking system 112 also includes a number of application program interfaces including a vendor API 113, a user API 114, and a financial institution API 115. Each of these APIs facilitates communication between outside systems and the payment ranking system 112 via a network such as, for example, network 102….In addition, the payment ranking system 112, the financial institution system 120, the vendor system 130, and the user device 104 may communicate through the network 102 using any one of a number of secure communication, encryption, or private messaging protocols.” – therefore uses an encrypted API protocol (i.e., using a tokenized API protocol), [0027] “The financial institution API 115 may provide an interface between the payment ranking system 112 and one or more financial institution systems 120. Through this interface, financial institutions may interface with the payment ranking system 112 to provide information related to various payment options and their associated benefits. This interface may also be used to enable financial institutions to submit offers related to the user's list of payment options that can influence the ranking…”, see also [0030] & [0059])
Wu suggests it is advantageous to securely connect to third-party financial services using tokenized API protocols, because doing so can provide a higher level of security associated with the data conveyed between the system and the third-party financial services ([0021] & [0027])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Goodwin to securely connect to third-party financial services using tokenized API protocols, as taught by Wu, because doing so can provide a higher level of security associated with the data conveyed between the system and the third-party financial services.
v Claims 10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Goodwin (U.S. PG Pub No. 2014/0129357, May 8, 2014 - hereinafter "Goodwin”) in view of Ross (U.S. PG Pub No. 2012/0221420 August 30, 2012 - hereinafter "Ross”)
With respect to claim 10, Goodwin teaches the method of claim 8. Although Goodwin suggests a user may define payment card available credit or balance limits/thresholds on each candidate payment method ([0037]-[0038]) as well as preferences to use payment methods in a way that maximizes credit score ([0038]), Goodwin does not appear to explicitly disclose,
wherein securely analyzing the transaction data includes calculating the projected credit utilization after the transaction for each candidate payment method
However, Ross discloses
wherein securely analyzing the transaction data includes calculating the projected credit utilization after the transaction for each candidate payment method ([0071] “in some embodiments, the customer may be able to set limits on the overdraft protections, balance limits, available funds, etc. to prevent the system payment application 256 from applying transactions to an account that may surpass the available balance or credit limit. In some embodiments of the invention, payments are automatically debited from an account on a monthly or weekly basis. Therefore, if the available balance or credit limit is close to the limit of the account, the customer may want to prevent the system payment application 256 from automatically applying a transaction to a payment account because it provides the best promotions if the customer 202 knows that automatic payments are about to be deducted from the account that could create an overdraft issue… customer 202 may be able to set up account limits that will not let a transaction be applied to a specific account if the balance on the account is at a predetermined level.”), [0076] “Financial institution considerations are criteria that the financial institution has in place or inputted by the customer 202…system payment application 256 may access the selected payment account system 211 to ensure that funds are available in the respective account to process the transaction. In some embodiments, an account status inquiry of payment accounts may ensure the credit limit for an account has not yet been reached.)
Ross suggests it is advantageous to include wherein analyzing the transaction data includes calculating the projected credit utilization after the transaction for each candidate payment method, because doing so can ensure that the user’s credit or balance limits/thresholds are adhered to in view of the projected credit/balance utilization after the transaction under consideration and not just the current credit/balance ([0071] & [0076])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Goodwin to include wherein analyzing the transaction data includes calculating the projected credit utilization after the transaction for each candidate payment method, as taught by Ross, because doing so can ensure that the user’s credit or balance limits/thresholds are adhered to in view of the projected credit/balance utilization after the transaction under consideration and not just the current credit/balance.
With respect to claim 12, Goodwin teaches the method of claim 8. Goodwin suggests a user may define payment card available credit or balance limits/thresholds on each candidate payment method ([0037]-[0038]) as well as preferences to use payment methods in a way that maximizes credit score ([0038]). Goodwin therefore discloses filtering out payment methods that exceed preset utilization limits. However, Goodwin does not appear to explicitly disclose,
filtering out payment methods that would exceed preset utilization limits if used for the transaction
However, Ross discloses
filtering out payment methods that would exceed preset utilization limits if used for the transaction ([0071] “in some embodiments, the customer may be able to set limits on the overdraft protections, balance limits, available funds, etc. to prevent the system payment application 256 from applying transactions to an account that may surpass the available balance or credit limit. In some embodiments of the invention, payments are automatically debited from an account on a monthly or weekly basis. Therefore, if the available balance or credit limit is close to the limit of the account, the customer may want to prevent the system payment application 256 from automatically applying a transaction to a payment account because it provides the best promotions if the customer 202 knows that automatic payments are about to be deducted from the account that could create an overdraft issue…customer 202 may be able to set up account limits that will not let a transaction be applied to a specific account if the balance on the account is at a predetermined level.”), [0076] “Financial institution considerations are criteria that the financial institution has in place or inputted by the customer 202…system payment application 256 may access the selected payment account system 211 to ensure that funds are available in the respective account to process the transaction. In some embodiments, an account status inquiry of payment accounts may ensure the credit limit for an account has not yet been reached.)
Ross suggests it is advantageous to include filtering out payment methods that would exceed preset utilization limits if used for the transaction, because doing so can ensure that the user’s credit or balance limits/thresholds are adhered to in view of the projected credit/balance utilization after the transaction under consideration and not just the current credit/balance ([0071] & [0076])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Goodwin to include filtering out payment methods that would exceed preset utilization limits if used for the transaction, as taught by Ross, because doing so can ensure that the user’s credit or balance limits/thresholds are adhered to in view of the projected credit/balance utilization after the transaction under consideration and not just the current credit/balance.
v Claims 16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Goodwin (U.S. PG Pub No. 2014/0129357, May 8, 2014 - hereinafter "Goodwin”) in view of Bonfigli et al. (U.S. PG Pub No. 2021/0027357 January 28, 2021 - hereinafter "Bonfigli”)
With respect to claim 16, Goodwin teaches a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the system to perform operations comprising:
providing a user interface for ([0026] “The intelligent payment system 100 comprises…a direct user interface 109…The direct user interface 109 is a local application that includes a user-specific profile created on the user's electronic device or a web portal. The user accesses the direct user interface 109 and inputs all the data and information into the user-specific profile as required by the intelligent payment system 100. The direct user interface 109 operably communicates with the server side logic module 105 and the stored data module 108 to provide the data and information. The user interface 109 is also used for user prompted input”, [0057]-[0059] “communicates with the user through the direct user interface 109”)
setting payment preferences ([0076] – user defined preferences for reward structures, [0036]-[0038] “The payment evaluation criteria are assessed to assist the payment decision engine 102…the user may define many criteria to assist in the payment decision….As the user inputs more data, the evaluation of the type of payment method suggested to the user will be better. The user-defined type criteria may include but not limited to the following: available payment methods; available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit…a preference to use a payment method to maximize a credit score (e.g. to use payment methods that support credit scores);” – payment preferences set by user, see also [0046] & [0066]-[0067] & [0071]-[0072] & & [0076]-[0095])
retrieving…real-time account data for a plurality of linked payment methods; ([0027] “The server side logic module 105 may have data communication with the financial institutions to acquire updates on variables that affect payment choices”)
calculating a utilization percentage ([0036]-[0038] “The payment evaluation criteria are assessed to assist the payment decision engine 102…the user may define many criteria to assist in the payment decision….As the user inputs more data, the evaluation of the type of payment method suggested to the user will be better. The user-defined type criteria may include but not limited to the following: available payment methods; available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit…a preference to use a payment method to maximize a credit score (e.g. to use payment methods that support credit scores)” – as is known in the art available credit utilization percentage is the metric associated with a user’s credit score and would understand that determination of a payment method to maximize/support credit score involves determination of utilization percentage of their respective credit card methods – Examiner notes that prior art reference Dean (cited elsewhere in the action) evidences this is the utilization metric associated with credit score)
and reward yield for each payment method; ([0072] “ determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user” – therefore the system can determine reward yield for each payment method which is necessarily based on reward program rules specifying how rewards/befits would yield rewards for a transaction, [0075] “loyalty point offer for the merchant and a loyalty point modifier for a partner…1.5 miles per USD…at an American Airlines site…specific to retail locations” – current vendor eligibility, [0092] “ [0092] (i) Are there any partner offers or affiliations, such as "Double BA air miles at BP petrol/gas stations"” – purchase category, see also [0078]-[0081])
scoring each payment method based on the calculated metrics and user-defined weights; and ([0037]-[0038] “available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit; a preferred reward type, such as mileage points, cash back rebate, etc….a preference to use a payment method that has a most value for money, wherein the most value for money is determined based on a scoring evaluation by the server side logic module 105;” – therefore user defined criteria include rewards point preferences, cashback potential preferences and credit utilization preferences, [0076]-[0095] “User preferences can also be an input variable into the comparative decision process. For example, a user may prefer to collect American Airlines miles to British Airways (BA) miles, so the American Airlines miles may be associated with or given a multiplier weighting in a rule set. For example, a weighting of 120% may be applied to a certain loyalty point to artificially modify the scoring process to a certain user preferred reward…one or more modifiers…in addition to valuing reward points and modifying the weighting of results based on user-defined type criteria and/or other criteria, additional criteria can be included…one or more modifiers applied thereto…” – weighted algorithm, [0075] “cash back offer”)
selecting a payment method that maximizes user-defined benefit criteria while maintaining compliance with specified utilization thresholds ([0072] “ the server side logic module 105 determines the best payment method for the present transaction in association with a payment method selection process, which considers information or data including transaction related information (e.g., transaction amount, date/time, and type), merchant related information, user-defined type criteria, server defined type criteria, and possibly other information to determine a list of payment methods, options, or alternatives, including a recommended or expected best payment method, where such a list can be a prioritized list of payment methods in order of preference (e.g., which can be based upon or be organized in accordance with expected best to expected least benefit; or expected lowest cost to expected highest cost; or expected highest award/bonus to expected least award/bonus or least penalty to the user” determines best payment method based on one or more financial metrics (benefit amount, expected cost, etc.,), [0025]-[0026] “The intelligent payment system 100 is adaptable to work with a user's electronic device for automating a preferred possible payment method according to the user's interest. The payment method is used for a payment transaction initiated by the user with a merchant. The user includes a customer or any individual who owns one or more payment options from a variety of financial institutions or payment card providers….payment decision engine 102 may be available to the user's electronic device, either as a software application resided locally on the electronic device or located remotely over a data connection” – customer mobile device with local mobile app in connection with user network, [0036]-[0038] “The payment evaluation criteria are assessed to assist the payment decision engine 102…the user may define many criteria to assist in the payment decision….As the user inputs more data, the evaluation of the type of payment method suggested to the user will be better. The user-defined type criteria may include but not limited to the following: available payment methods; available credit or balance limits on the payment methods; user-defined manual payment rules; and user-defined targets or goals…In the available credit or balance limits on the payment methods, the user defines the limits of the various payment methods in the profile accordingly…spending target limit…a preference to use a payment method to maximize a credit score (e.g. to use payment methods that support credit scores);” – therefore the payment decision module (analysis module) determines an optimal payment method based on user-defined criteria including available credit/balance limits on the payment methods (one or more financial metrics), see also [0046] & [0066]-[0067] & [0076]-[0095])
Goodwin does not appear to disclose,
inputting account credentials
retrieving, via an API…account data for a plurality of linked payment methods;
However, Bonfigli discloses
inputting account credentials ([0021]-[0023] & [0063]-[0065] & [0074]-[0076] access credentials for accessing plurality of credit card provider systems are input by the ser to provide the system with access to this information)
retrieving, via an API…account data for a plurality of linked payment methods ([0053] & [0076]-[0077] & [0084]-[0085] & [0099] API used to retrieve account data for the linked payments methods for which the user provided account credentials)
Bonfigli suggests it is advantageous to include inputting account credentials retrieving, via an API account data for a plurality of linked payment methods, because doing so can provide the system with the information and authorization to obtain pertinent information associated with each of the user’s accounts associated with their payment options/methods and because doing so can facilitate flexible and secure information transmission ([0021]-[0023] & [0063]-[0065] & [0074]-[0076] & [0053] & [0076]-[0077] & [0084]-[0085] & [0099] ).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the medium of Goodwin to include instructions for inputting account credentials retrieving, via an API account data for a plurality of linked payment methods, as taught by Bonfigli, because doing so can provide the system with the information and authorization to obtain pertinent information associated with each of the user’s accounts associated with their payment options/methods and because doing so can facilitate flexible and secure information transmission.
With respect to claim 18, Goodwin teaches the medium of claim 16;
wherein the reward yield includes estimated point value per transaction type selected by the user ([0076]-[0078] determines estimated point value per transaction selected by user (e.g., transaction on a Sunday))
With respect to claim 19, Goodwin teaches the medium of claim 16;
wherein the user interface enables customization of optimization rules by assigning point values or monetary equivalents to various reward types ([0076]-[0078] “user preferences…multiplier weighting in a rule set…scoring of loyalty points…scoring of a given loyalty point to a normalised scoring mechanism, for example, valuing or generating estimated valuations for all loyalty points in USD. This can allow for loyalty points that cannot be directly compared to be relatively scored with respect to each other and/or discounts, offers, promotions, and the like. While it can be straightforward to score two payment options offering BA miles, comparative scoring involving a comparison between the value of a BA mile to an American Airlines mile can involve normalization of a BA mile and an American Airlines mile to a standard reference, benchmark, or unit (e.g., USD or another currency). There can be additional variables or normalizations involved in scoring a BA mile to a Hilton hotel point. By normalising scoring for each possible reward to common value reference, informed comparative or relative scoring decisions and preferred/best payment method selection decisions can be made, for instance, associated with or indicating a `best value` payment method… modifying the weighting of results based on user-defined type criteria and/or other criteria” – user can input preferences/weightings (user inputs are via the interface as discussed elsewhere) which factor into the normalized monetary equivalent used to compare benefit value – i.e., the user interface enables customization of optimization rules by assigning point values or monetary equivalents to various reward types, see also [0106])
With respect to claim 20, Goodwin teaches the medium of claim 16;
further comprising instructions to detect duplicate or recurring transactions and apply historical optimization data to accelerate future payment selections ([0070]-[0071] system caches rule to accelerate future payment selections based on detected duplicate (e.g., same transaction amounts and merchant/POS combination) which is historical optimization data)
v Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Goodwin in view of Bonfigli, as applied to claim 16 above, and further in view of Regen (U.S. PG Pub No. 2020/0286064 , September 10, 2020- hereinafter "Regen”)
With respect to claim 17, Goodwin and Bonfigli teach the medium of claim 16. Goodwin does not appear to explicitly disclose,
wherein the instructions further cause the system to track cumulative monthly utilization across all linked accounts and issue warnings when thresholds are approached
However, Regen discloses a system where user can input custom credit card utilization percentage thresholds such that credit cards are selected for transactions in a manner that will improve their credit score. Regan also discloses
wherein the instructions further cause the system to track cumulative monthly utilization across all linked accounts and issue warnings when thresholds are approached (Fig 2 tags 31 and 32 & [0019] & [0024] auto alerts may alert user when cumulate monthly balance-to-limit ration/thresholds across each linked account are approached)
Regen suggests it is advantageous to include wherein the instructions further cause the system to track cumulative monthly utilization across all linked accounts and issue warnings when thresholds are approached, because doing so can provide the user with pertinent information regarding relevant information (e.g., credit utilization limits and/or information related to their credit score) (Fig 2 & [0019] & [0024])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the medium of Goodwin in view of Bonfigli to include wherein the instructions further cause the system to track cumulative monthly utilization across all linked accounts and issue warnings when thresholds are approached, as taught by Regen, because doing so can provide the user with pertinent information regarding relevant information (e.g., credit utilization limits and/or information related to their credit score).
Prior Art of Record
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
Collart (U.S. PG Pub No. 2014/0278892, September 18, 2014) teaches a mobile app/wallet where a user can link their multiple payment cards/methods and various payment preferences/criteria and that automatically determines an optimal payment card/method to use for a given transaction in view of these preferences/criteria.
Rajogopal (U.S. PG Pub No. 2020/0265408, August 20, 2020) teaches a mobile app/wallet where a user can link their multiple payment cards/methods and various payment preferences/criteria and that automatically determines an optimal payment card/method to use for a given transaction in view of these preferences/criteria.
Dean et al. (U.S. PG Pub No. 2019/0197528, June 27, 2019) teaches a system for identifying/recommending a payment card to use for a transaction based on credit utilization thresholds/amounts associated with each card. Discloses an interface that shows the user’s current credit utilization percentage for each card as it relates to the threshold.
Rowe et al. (U.S. PG Pub No. 2008/0097882, April 24, 2008) teaches a system for identifying/recommending an optimal payment card to use for a transaction and wherein the system charges a service fee for providing this payment-method-recommendation service
Conclusion
No claim is allowed
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES M DETWEILER whose telephone number is (571)272-4704. The examiner can normally be reached on Monday-Friday from 8 AM to 5 PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Waseem Ashraf can be reached at telephone number (571)-270-3948. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/JAMES M DETWEILER/Primary Examiner, Art Unit 3621
