DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
The following terms and/or phrases have been interpreted in light of the applicant’s specification:
A computer implemented method and a system for optimizing purchasing reward comprising a rewards management system data lake comprising a user database and a merchant database; an optimization engine; by a transaction application programming interface: software (Based on the applicant’s disclosure in paragraph 27 and figure 1, the method, system, data lake, user database, merchant database, optimization engine and transaction application programming interface are all components of a software program.)
Claim Objections
Claims 1-10 are objected to because of the following informalities: Independent claim 1 recites “obtaining a plurality of purchasing options and storing into a user database, obtaining merchant data and storing into a merchant database”. In regards to “storing into a user database” and “storing into a merchant database”, the claim does not provide an indication as to exactly what is being stored and, as such, the limitations do not have proper antecedent basis. Since it is clear that the applicant intends the limitation to be “obtaining a plurality of purchasing options and storing the plurality of purchasing options into a user database, obtaining merchant data and storing the merchant data into a merchant database”, the examiner has raised an Objection rather than a 112(b) rejection. Dependent claims 2-10 inherit the deficiencies of the claims from which they depend and, as such, are objected to by virtue of dependency. The applicant is required to amend the claims to correct the antecedent basis issue. For the purpose of prosecuting the claims the examiner is going to interpret the limitation as if it had been amended to recite: “obtaining a plurality of purchasing options and storing the plurality of purchasing options into a user database, obtaining merchant data and storing the merchant data into a merchant database”. Appropriate 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.
Claim 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because they merely recite “software per se”. Independent claims 1 and 11 recite “a computer-implemented method for optimizing purchasing rewards” and “a system for optimizing purchasing reward” respectively. The method comprises an optimization engine, a transaction application programming interface, and a rewards management system data lake comprising a user database and a merchant database. The remaining limitations of the system are functional steps. While one of ordinary skill in the art would expect at least the claimed databases, data lake, and system to be hardware, this is apparently not the case. Based on the applicant’s specification in paragraph 27 and figure 1 each of the claimed system, method, optimization engine, transaction application programming interface, rewards management system data lake, user database and merchant database can be just parts of software program. As such, independent claims 1 and 11 recite no structural elements and instead merely recite functional steps that are performed only by software. Since independent claims 1 and 11 recite no limitations that must be interpreted as structure. The broadest reasonable interpretation of the claims is software without any structure that performs all recited functions. As such, independent claims 1 and 11 are merely “software per se”. The examiner suggests, assuming that support can be found in the applicant’s disclosure, amending claim 1 to recite that each of the functional steps are performed by a computer such as “obtaining, by a computer, a plurality of purchasing options and storing, by the computer, the plurality of purchasing options into a physical user database”; “obtaining, by the computer, …”; analyzing, by the computer,…”; “generating, by the computer,…”; “receiving, by the computer,…” etc. The examiner suggest, assuming that support can be found in the applicant’s disclosure, amending claim 11 to recite: “A system for optimizing purchasing rewards, comprising: a physical rewards management system data lake comprising a physical user database and a physical merchant database, wherein…; and a computer, wherein the computer further comprises: an optimization engine…; and a transaction application programming interface…”. Dependent claims 2-10 and 12-20 fail to correct the deficiencies of the claims from which they depend and, as such, also recite “software-per-se”. (i.e., 2019 Revised Patent Subject Matter Eligibility Guidance (hereinafter “PEG”) “PEG” Step 1=No)
Assuming the applicant was able to find support in the applicant’s disclosure to amend the require structure in a manner similar to the recommended amendments above claims 1-20 would be directed to a method and a system which would be classified under one of the listed statutory classifications (i.e., 2019 Revised Patent Subject Matter Eligibility Guidance (hereinafter “PEG”) “PEG” Step 1=Yes).
However, claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Independent claim(s) 1 and 11 recite(s) the following abstract idea:
obtaining a plurality of purchasing options;
storing the plurality of purchasing option;
obtaining merchant data, wherein the merchant data comprises a merchant classification and transaction classification;
storing the merchant data;
analyzing, periodically, the plurality of purchasing options against the merchant data to produce a reward value for each purchase option against the merchant classification and the transaction classification,
generating, periodically, a lookup table to rank the plurality of purchasing options based on the reward value,
receiving a transaction input, wherein the transaction input comprises a merchant code and a transaction code,
evaluating the transaction input by matching the merchant code against the merchant classification and matching the transaction code with the transaction classification,
identifying an optimized purchasing option from the plurality of purchasing options in the lookup table, wherein the optimized purchasing option comprises the highest reward value, and
generating a transaction output for the optimized purchasing option.
The limitations as detailed above, as drafted, falls within the “Certain Method of Organizing Human Activity” grouping of abstract ideas namely commercial or legal interactions because they recite advertising, marketing and sales activities or behaviors because they merely gather data, analyze the data, determine results based on the analysis, generate tailored content based on the results, and/or transmit the tailored content. Accordingly, the claim recites an abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes).
This judicial exception is not integrated into a practical application because the claim only recites the additional elements of a computer comprising one or more databases and software (i.e., an optimization engine and a transaction application programming interface).
The following limitations, if removed from the abstract idea and considered additional elements, merely perform generic computer function of processing, communicating (e.g., transmitting and receiving), and displaying:
obtaining a plurality of purchasing options (receiving data);
storing the plurality of purchasing option (storing data);
obtaining merchant data, wherein the merchant data comprises a merchant classification and transaction classification (receiving data);
storing the merchant data (storing data); and
receiving a transaction input, wherein the transaction input comprises a merchant code and a transaction code (receiving data).
The additional technical elements above are recited at a high-level of generality (i.e., as a generic processor and generic computer components performing a generic computers function of processing, communicating and displaying) such that it amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and generic computer components. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional technical elements above do not integrate the abstract idea/judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. More specifically, the additional elements fail to include (1) improvements to the functioning of a computer or to any other technology or technical field (see MPEP 2106.05(a)), (2) applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition (see Vanda memo), (3) applying the judicial exception with, or by use of, a particular machine (see MPEP 2106.05(b)), (4) effecting a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)), or (5) applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (see MPEP 2106.05(e) and Vanda memo).
Rather, the limitations merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on one or more computers, or merely uses computers as a tool to perform an abstract idea (see MPEP 2106.05(f)), or generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)).
Thus, the claim is “directed to” an abstract idea (i.e. “PEG” Revised Step 2A Prong Two=Yes)
When considering Step 2B of the Alice/Mayo test, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims do not amount to significantly more than the abstract idea.
More specifically, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computer comprising one or more databases; a display (e.g., output hardware) and software (i.e., an optimization engine, a transaction application programming interface, expense tracker) to perform the claimed functions amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and one or more generic computer component.
“Generic computer implementation” is insufficient to transform a patent-ineligible abstract idea into a patent-eligible invention (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2352, 2357) and more generally, “simply appending conventional steps specified at a high level of generality” to an abstract idea does not make that idea patentable (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Mayo, 132 S. Ct. at 1300). Moreover, “the use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent-eligible subject matter (See FairWarning, 120 U.S.P.Q.2d. 1293, citing DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1256 (Fed. Cir. 2014)). As such, the additional elements of the claim do not add a meaningful limitation to the abstract idea because they would be generic computer functions in any computer implementation. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of the computer or improves any other technology. Their collective functions merely provide generic computer implementation.
The Examiner notes simply implementing an abstract concept on one or more computers, without meaningful limitations to that concept, does not transform a patent-ineligible claim into a patent-eligible one (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bancorp, 687 F.3d at 1280), limiting the application of an abstract idea to one field of use does not necessarily guard against preempting all uses of the abstract idea (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bilski, 130 S. Ct. at 3231), and further the prohibition against patenting an abstract principle “cannot be circumvented by attempting to limit the use of the [principle] to a particular technological environment” (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Flook, 437 U.S. at 584), and finally merely limiting the field of use of the abstract idea to a particular existing technological environment does not render the claims any less abstract (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2358; Mayo, 132 S. Ct. at 1294; Bilski v. Kappos, 561 U.S. 593, 612 (2010); Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat’l Ass’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014).
Applicant herein only requires one or more general-purpose computer and generic computer components (as evidenced from the Affinity v. DirectTV decision a computer with generic computer components such as an interface and database does not make an otherwise ineligible claim patent-eligible); therefore, there does not appear to be any alteration or modification to the generic activities indicated, and they are also therefore recognized as insignificant activity with respect to eligibility. Finally, the following limitations, if removed from the abstract idea and considered additional elements, would be considered insignificant extra solution activity as they are directed to merely receiving, storing and/or transmitting data:
obtaining a plurality of purchasing options (receiving data);
storing the plurality of purchasing option (storing data);
obtaining merchant data, wherein the merchant data comprises a merchant classification and transaction classification (receiving data);
storing the merchant data (storing data); and
receiving a transaction input, wherein the transaction input comprises a merchant code and a transaction code (receiving data).
Thus, taken individually and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea) (i.e., “PEG” Step 2B=No).
The dependent claims 2-10 and 12-20 appear to merely further limit the abstract idea by adding an additional step of generating additional tables which is considered part of the abstract idea (Claims 2 and 12); further limiting the obtaining of the merchant data which is considered part of the abstract idea and adding an additional step of organizing the merchant data which is considered part of the abstract idea (Claims 3 and 13); adding additional tracking and evaluating steps which are both considered part of the abstract idea (Claims 4 and 14); further limiting the analyzing of the plurality of purchasing option which is considered part of the abstract idea (Claims 5-6 and 15-16); further limiting the transaction output which is considered part of the abstract idea (Claims 7-8 and 17-18); adding an additional step updating the lookup table which is considered part of the abstract idea (Claims 9 and 19); and further limiting the generating of the lookup table which is considered part of the abstract idea (Claims 10 and 20), and therefore only further limit the abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes), does/do not include any new additional elements of the claimed invention, which have not already been addressed above, that are sufficient to amount to significantly more than the judicial exception, and as such are “directed to” said abstract idea (i.e. “PEG” Step 2A Prong Two=Yes); and do not add significantly more than the idea (i.e. “PEG” Step 2B=No)..
Thus, based on the detailed analysis above, claims 1-20 are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 4-6, 9-12, 14-16, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Taylor et al. (PGPUB: 2023/0230094) in view of Bugenhagen (PGPUB: 2018/0322419) in further view of Alspach-Goss et al. (PGPUB: 2006/0053056).
Claims 1 and 11: Taylor discloses a computer-implemented method and a system for optimizing purchasing rewards, comprising:
obtaining a plurality of purchasing options, and storing the plurality of purchasing option in a user database of a reward management system data lake; and obtaining merchant data, wherein the merchant data comprises a merchant classification and transaction classification, and storing the merchant data in a merchant database of the reward management system data lake;
Taylor discloses obtaining a plurality of purchasing options, and storing the plurality of purchasing option in association with a user of a reward management system; and obtaining merchant data, wherein the merchant data comprises a merchant classification and transaction classification, and storing the merchant data in association with merchant of the reward management system (Paragraph 18: one or more of the payment devices may be associated with a rewards program that offers a reward for initiating a financial transaction with a preselected vendor and/or a reward for initiating a financial transaction with a vendor associated with a preselected merchant category code (or type); Paragraph 26: the user is associated with three payment device with respective three rewards programs; Paragraph 17: vendor information can include, but is not limited to, a merchant category code of the vendor, a merchant category type of the vendor, a geographic location of the vendor, a presence (online vs. offline) of the vendor, and/or whether the user has engaged in prior financial transactions with the vendor, without limitation; Paragraph 18: vendors are associated with preselected merchant category code (or other type); Paragraphs 48-49: such data is stored in a memory or storage on the computer system; Paragraph 46: setting personal choices and preferences for the user:).
Taylor does not disclose that the data is stored in databases associated with a data lake.
However, the analogous art of Bugenhagen discloses that it is known to store information collected from various sources in a relational database configured to host one more data lakes in at least paragraphs 34 and 104.
It would have been obvious to one of ordinary skill in the art to modify the invention of Taylor to store the associated data include databases comprised of one or more data lakes as disclosed by Bugenhagen.
The motivation for doing so is that it would be obvious to try. There are a limited number of predictable ways in which to store associated data an one such predictable way is to store the data in databases comprised of one or more data lakes.
analyzing, periodically and by an optimization engine, the plurality of purchasing options against the merchant data to produce a reward value for each purchase option against the merchant classification and the transaction classification; and generating, periodically and by the optimization engine, a lookup table to rank the plurality of purchasing options based on the reward value;
Taylor and Bugenhagen disclose analyzing, periodically and by an optimization engine, the plurality of purchasing options against the merchant data to produce a reward value for each purchase option against the merchant classification and the transaction classification; and generating, periodically and by the optimization engine, a ranking of the plurality of purchasing options based on the reward value in at least paragraphs 42-43 of Taylor (Paragraphs 42-43: at the time of each transaction, analyzing and ranking the payment devices based on the highest reward value for a given transaction type, wherein the rule is to select the payment device with the highest reward value for the given transaction type and merchant).
However, the rankings in Taylor and Bugenhagen are performed in real-time and, as such, Taylor and Bugenhagen do not disclose periodically generating a lookup table to rank the plurality of purchasing options based on the reward value.
However, the analogous art of Alspach-Goss discloses that it is known to store any type of data that is calculated and or received in a look-up table in at least paragraphs 22, 37, 96, 116-117, and 132-137.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention to modify the invention of Taylor and Bugenhagen such that the analyzing of the plurality of purchasing options against the merchant data to produce a reward value for each purchase option against the merchant classification and the transaction classification; and the generating of the ranking the plurality of purchasing options based on the reward value is done less frequently than in real-time, such that the rankings could be stored in a lookup table, which are used in identification of an optimized purchasing option from the plurality of purchasing options, and to modify all other stored data in the databases to be organized in lookup tables as disclosed by Alspach-Goss.
The rationale for doing so it that it merely requires the use of known techniques to improve similar devices or methods in the same way. Taylor and Bugenhagen discloses the base method of receiving and storing data in databases; analyzing the plurality of purchasing options against the merchant data to produce a reward value for each purchase option against the merchant classification and the transaction classification; and the generating of the ranking the plurality of purchasing options based on the reward value. Alspach-Goss discloses an improved method of organizing and storing such received and calculated data. One or ordinary skill in the art would have recognized the adaption of using lookup tables (disclosed by Alspach-Goss) to the storing of received data; analyzing, in real-time, the plurality of purchasing options against the merchant data to produce a reward value for each purchase option against the merchant classification and the transaction classification; and the generating, in real-time of the ranking the plurality of purchasing options based on the reward value of Taylor and Bugenhagen for the predicted result of reducing the system overhead associated with performing the analyzing and ranking and simplifying the searching for data in the databases.
receiving, by a transaction application programming interface, a transaction input, wherein the transaction input comprises a merchant code and a transaction code (Taylor - Paragraphs 12-17: receiving financial transaction information, wherein the transaction information includes: information about the financial transaction including information about the goods and/or services being purchased including a purchase quantity, a purchase price, a description of the goods and/or services, a model number of the goods and/or services, an availability of the goods and/or services, a date and/or time of the financial transaction, a shipping and/or delivery deadline for the goods and/or services, a payment term, and/or a duration term, without limitation; the user initiating the financial transaction; and/or at least one merchant or other vendor for attending to or otherwise fulfilling the financial transaction including a merchant category code of the vendor, a merchant category type of the vendor, a geographic location of the vendor, a presence (online vs. offline) of the vendor, and/or whether the user has engaged in prior financial transactions with the vendor);
evaluating, by the transaction application programming interface, the transaction input by matching the merchant code against the merchant classification and matching the transaction code with the transaction classification (Taylor - Paragraphs 39 -42: utilize one or more rules for evaluating the received financial transaction information and selecting the selected payment device for consummating the financial transaction, wherein the rules can be preset or generated at the time of the financial transaction; Paragraph 43: ranking the payment devices based on the highest reward value for a given transaction type, wherein the rule is to select the payment device with the highest reward value for the given transaction type at a given merchant);
identifying, by the transaction application programming interface, an optimized purchasing option from the plurality of purchasing options in the lookup table, wherein the optimized purchasing option comprises the highest reward value (Taylor - Paragraph 18: payment device determination can be based upon a rewards program associated with each payment device; Paragraph 25: selecting a payment device associated with the user for consummating the financial transaction; the selected payment device preferably comprises a best or otherwise optimal payment device associated with the user for consummating the financial transaction based upon an evaluation of the received financial transaction information; such as the payment device with the best rewards based on the financial transaction information; Paragraphs 27-28 and 31-34: identifying the best payment device for a transaction based on it having the greatest rewards value; as modified above to use look-up tables instead of real-time in Alspach-Goss - Paragraphs 22, 37, 96, 116-117, and 132-137); and
generating, by the transaction application programming interface, a transaction output for the optimized purchasing option. (Taylor - Paragraph 45: providing or routing an authorization for the financial transaction to the selected payment device)
Claims 2 and 12: Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, wherein the optimization engine generates, for the lookup table, a customer specific holistic table, a customer specific merchant classification code table, and a customer specific retailer table. (Taylor – Paragraphs 17-19, 24-34, 46-49: such data is stored in a memory or storage on the computer system; Paragraph 46 as modified by Alspach-Goss to use lookup tables in Paragraphs 22, 37, 96, 116-117, and 132-137: the generated lookup table is customer specific and generated from data stored in the user database as lookup tables and data stored in the merchant database as lookup tables, where in the user database comprises a customer specific holistic table of all payment devices; customer specific merchant classification code comprising financial transaction history of the user including merchant category codes of vendors, an a customer specific retailer table of user preferences with regards to vendors and payment devices)
Claims 4 and 14. Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, the optimization engine further comprises tracking the transaction output in a transaction table, wherein a cap for the reward value of a purchasing option is evaluated against the transaction table. (Taylor – Paragraph 40-41: a fourth rule for presetting a specific payment device or other payment method to be used for financial transactions with a transaction amount that is greater than a first predetermined financial transaction amount, and/or a fifth rule for presetting a specific payment device or other payment method to be used for financial transactions with a transaction amount that is less than a second predetermined financial transaction amount; Paragraph 44: for a financial transaction with a transaction amount that is greater than (and/or equal to) a predetermined transaction amount threshold, one or more of the payment devices can be excluded from the ranking of the available payment devices; and/or excluding a payment device if an available credit limit or other funding limit that is less than the transaction amount of the financial transaction; an excluded payment device can be excluded from the payment device ranking for the financial transaction even if the rewards program associated with the excluded payment device is more beneficial than the rewards programs of the ranked payment devices)
Claims 5 and 15. Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 4 and the system of claim 14, wherein the analyzing of the plurality of purchasing options further comprises updating, by the optimization engine, the lookup table based on the cap for the reward value of a purchasing option. (Taylor - Paragraph 44: for a financial transaction with a transaction amount that is greater than (and/or equal to) a predetermined transaction amount threshold, one or more of the payment devices can be excluded from the ranking of the available payment devices; and/or excluding a payment device if an available credit limit or other funding limit that is less than the transaction amount of the financial transaction; an excluded payment device can be excluded from the payment device ranking for the financial transaction even if the rewards program associated with the excluded payment device is more beneficial than the rewards programs of the ranked payment devices)
Claims 6 and 16. Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, wherein the analyzing of the plurality of purchasing options further comprises evaluating, by the optimization engine, a holistic reward value for each of the plurality of purchasing options, wherein the holistic reward value is independent of the merchant classification and transaction classification. (Taylor – Paragraph 26 and 28: each card is evalutated based on the specific transaction, thus the holistic reward value of the first payment device (1x points) is used for analyzing and ranking the first payment device when the transaction is not a restaurant or bar purchase; and the holistic reward value of the second payment device (1% cash back) is used for analyzing and ranking the second payment device when the transaction is not a restaurant or online shopping purchase)
Claims 9 and 19. Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, further comprising utilizing an expense tracker of the optimization engine to update the lookup table with the merchant classification and transaction classification. (Taylor – Paragraph 40-41: a fourth rule for presetting a specific payment device or other payment method to be used for financial transactions with a transaction amount that is greater than a first predetermined financial transaction amount, and/or a fifth rule for presetting a specific payment device or other payment method to be used for financial transactions with a transaction amount that is less than a second predetermined financial transaction amount; Paragraph 44: for a financial transaction with a transaction amount that is greater than (and/or equal to) a predetermined transaction amount threshold, one or more of the payment devices can be excluded from the ranking of the available payment devices; and/or excluding a payment device if an available credit limit or other funding limit that is less than the transaction amount of the financial transaction; an excluded payment device can be excluded from the payment device ranking for the financial transaction even if the rewards program associated with the excluded payment device is more beneficial than the rewards programs of the ranked payment devices)
Claims 10 and 20. Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, wherein the generating of the lookup table further comprises downloading, by the transaction application programming interface, the lookup table onto a local device. (Taylor: Paragraph 47: various functionality of the financial transaction processing method 100 discussed herein can be performed by and/or with the help of one or more computers, thus the lookup table may be generated on a different computer and downloaded to a client device that is performing remainder of the steps; or the client device can perform all of the steps but download the lookup table to a local device for storage)
Claim(s) 7-8 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Taylor et al. (PGPUB: 2023/0230094) in view of Bugenhagen (PGPUB: 2018/0322419) in view of Alspach-Goss et al. (PGPUB: 2006/0053056) in further view of Loomis (PGPUB: 2016/0055514)
Claims 7-8 and 17-18. The computer-implemented method of claim 1 and the system of claim 11, wherein the transaction output is a recommendation of the optimized purchasing option generated by the transaction API, wherein the transaction output is an embodiment, by an output module, of the optimized purchasing option through an output hardware.
Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, wherein the transaction output is generated by the transaction API in at least Taylor - Paragraph 45 where a selected payment device is providing or routing an authorization for the financial transaction to the selected payment device.
While Taylor, Bugenhagen, and Alspach-Goss disclose ranking the payment devices in order based on the highest reward value for a given transaction, and indicates that they are choices in at least paragraphs 27-34 of Taylor, he never specifically states that they are displayed to the user as a recommendation.
As such Taylor, Bugenhagen, and Alspach-Goss do not disclose the transaction output is a recommendation of the optimized purchasing option generated, wherein the transaction output is an embodiment, by an output module, of the optimized purchasing option through an output hardware.
However, the analogous art of Loomis discloses that it is known for transaction output to be a recommendation of the optimized purchasing option generated, wherein the transaction output is an embodiment, by an output module, of the optimized purchasing option through an output hardware in at least paragraphs 17, 35, 49, and 52.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify the invention of Taylor, Bugenhagen, and Alspach-Goss, such that rather than automatically selecting the payment device, a recommendation is output for the optimized purchasing option generated, wherein the transaction output is an embodiment, by an output module, of the optimized purchasing option through an output hardware such as a display as disclosed by Loomis.
The rationale for doing so it that it merely requires the use of known techniques to improve similar devices or methods in the same way. Taylor, Bugenhagen, and Alspach-Goss discloses the base method where the selection of the payment device is automatic. Loomis discloses an improved method wherein the optimal payment device is recommended, but the user is given the choice of whether or not to use the optimal payment device. One or ordinary skill in the art would have recognized the adaption of providing the user a choice of using the optimal payment device (disclosed by Loomis) to the invention of Taylor, Bugenhagen, and Alspach-Goss for the predicted result of ensuring that the consumer want to obtain the greatest reward value for a purchase, rather than just assuming this to be the case.
Possible Allowable Subject Matter
Claims 3 and 13 contain subject matter that would be allowable over the prior art if the applicant were to be able to overcome the Claim Objections and the 35 USC 101 rejections above.
The following is a statement of reasons for the indication of allowable subject matter: While the prior art of Taylor, Bugenhagen, and Alspach-Goss disclose the computer-implemented method of claim 1 and the system of claim 11, including using databases in one or more data lake to store any and all obtained data, wherein said data can be arranged in lookup table organized in any manner desired, the do not specifically state that:
the obtained merchant data comprises:
merchant category code dynamic rewards,
merchant category code static rewards,
retailer dynamic rewards,
user-specific retailer dynamic rewards,
retailer static rewards, and
holistic rewards, and/or
the merchant database is configured to organize the merchant data based on:
the merchant category code dynamic rewards,
the merchant category code static rewards,
the retailer dynamic rewards,
the user-specific retailer dynamic rewards,
the retailer static rewards, and
the holistic rewards.
The examiner has determined that it would not have been obvious to one or ordinary skill in the art to modify the invention of Taylor, Bugenhagen, and Alspach-Goss to obtain each and every type of required rewards, and/or to organize the merchant database based on each and every type of required rewards without the use of impermissible hindsight by using the applicant’s claims as a roadmap.
As such, claims 3 and 13 recite subject matter that would be allowable over the prior art if the applicant were to be able to overcome the Claim Objections and the 35 USC 101 rejections above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pawelkiewicz et al. (PGPUB 2023/0086251) which discloses storing a lookup table that includes a list of mobile applications, such as payment device applications, eligible for loyalty point redemption and a corresponding conversion rate for the loyalty point redemption; identify payment device applications stored on the computing device eligible for loyalty point redemption; performing a lookup of each payment device application installed on the computing device to determine if the application is eligible for loyalty point redemption, wherein the lookup table may only include payment device applications that are eligible for loyalty point redemption and as such if a particular application is not found in the lookup table it is assumed that the application is not eligible for loyalty point redemption.
Novis (PGPUB: 2020/0074449) which discloses optimizing transactions for a user by receiving, from the merchant system, merchant information for the transaction, retrieving, based on the account number, a database record from a database, the database record comprising the plurality of financial accounts associated with the user and user preferences, determining financial account data associated with each of the plurality of financial accounts, determining, using an optimization algorithm, a preferred financial account from the plurality of financial accounts based on the financial account data, the user preferences, and the merchant information, and selecting, based on the determination, the preferred financial account to complete the transaction, wherein the preferred financial account provides the greatest reward value.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN W VAN BRAMER whose telephone number is (571)272-8198. The examiner can normally be reached Monday-Thursday 5:30 am - 4 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Spar Ilana can be reached at 571-270-7537. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John Van Bramer/Primary Examiner, Art Unit 3622