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 .
Continuation Application
This Application is a continuation of US Application No. 18/397,331, which is a continuation of Application 16/418,430, now Abandoned, filed on 12/27/2023. US Application No. 18/397,331 is now patent US 12,481,979 B2 (“Parent Application”). See MPEP § 201.07. In accordance with MPEP § 609.02 (II)(A)(2) and MPEP § 2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also, in accordance with MPEP § 2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) is/are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desires the information to be printed on a patent issuing from this application. See MPEP § 609.02 (II)(A)(2).
Acknowledgements
This Office Action is in response to the claims filed on 12/03/2025.
Claims 1-20 were newly introduced.
Claims 1-20 are pending.
Claims 1-20 were examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 1-7 are directed to a method, claims 8-14 are directed to a system, and claims 15-20 are directed to a medium. Therefore, these claims fall within the four statutory categories of invention.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claims 1, 8 and 15 recite “wherein the identity-based recommendation comprises a proposed transaction between a first financial subsystem and a second financial subsystem”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claims 1, 8 and 15 recite “performing a balancing and control operation to confirm a measure of accuracy of the interconnected transaction ledger”, a statement of intended use or field use. See MPEP 2114 II. With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 1-7 are directed to a method, claims 8-14 are directed to a system, and claims 15-20 are directed to a medium. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
a. accessing an interconnected transaction ledger containing historical transaction data associated with a user account;b. performing a balancing and control operation to confirm a measure of accuracy of the interconnected transaction ledger;c. processing the historical transaction data via a knowledge system comprising a machine learning model;d. generating an identity-based recommendation, wherein the identity-based recommendation comprises a proposed transaction between a first financial subsystem and a second financial subsystem; ande. sending the identity-based recommendation to a user-device associated with the user account.
Therefore, the portions highlighted in bold above recite providing a recommendation, which is an abstract idea grouped within the and mental processes grouping of abstract ideas in prong one of step 2A. The claims are grouped within mental processes because the steps recited describe collecting information, analyzing it, and displaying certain results of the collection and analysis, which is a concept that can be performed in the human mind or by pen and paper. Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using a computing device comprising a processor and a memory, non-transitory computer-readable medium to perform the recited steps/functions, these additional elements performs the steps or functions such as: “accessing… ledger…”, “performing… operation…”, “processing… data…”, “generating… recommendation…”, “sending… recommendation…”. These additional elements are recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, these elements do not integrate the abstract idea into a practical application because they require no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of a machine learning model amount to generally linking the use of the judicial exception to a particular technological environment or field of use.. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer elements, such as a computing device comprising a processor and a memory, non-transitory computer-readable medium, and a machine learning model. The a computing device comprising a processor and a memory, non-transitory computer-readable medium perform the steps/functions of “accessing… ledger…”, “performing… operation…”, “processing… data…”, “generating… recommendation…”, “sending… recommendation…”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of providing a recommendation. The additional element(s) of a machine learning model amount to generally linking the use of the judicial exception to a particular technological environment or field of use. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of providing a recommendation. Therefore, the independent claims are not eligible.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. a computing device comprising a processor and a memory, non-transitory computer-readable medium), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Dependent claims 2-7, 9-14 and 16-20 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
f) further comprising: determining a set of input data based at least in part on the historical transaction data; training the machine learning model on the set of input data; receiving an output from the machine learning model; and generating the identity-based recommendation based at least in part on the output of from the machine learning model. g) further comprising: identifying a data transfer in the interconnected transaction ledger; confirming the data transfer is completed, on time, and accurate; and adjusting the measure of accuracy of the interconnected transaction ledger. h) further comprising: monitoring transactions associated with the user account; determining a payment was not made; and suspending access of the user account to the first financial subsystem and to the second financial subsystem based at least in part on the payment not being made. i) further comprising: retrieving the historical transaction data associated with a user account, wherein the historical transaction data describes the user account applying reward points from the first financial subsystem to the second financial subsystem; and generating the identity-based recommendation, wherein the identity-based recommendation comprises a transfer of reward points from the first financial subsystem to the second financial subsystem. j) wherein the identity-based recommendation is based at least in part on a frequency of a transaction and a type of the transaction in the historical transaction data. k) wherein the set of input data includes third-party data received from a third-party data service.
With respect to the eligibility analysis of claims 3, 10 and 17, Item g) above introduces the additional elements/functions of identifying a transfer, confirming details and adjusting a score. This language further elaborates the abstract idea of providing a recommendation identified in the analysis of independent claims 1, 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1, 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claims 4, 11 and 18, Item h) above introduces the additional elements/functions of monitoring transactions, making a determination and suspending access. This language further elaborates the abstract idea of providing a recommendation identified in the analysis of independent claims 1, 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1, 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to claims 5, 12 and 19, the claims recite item i) above, language directed to non-functional descriptive material by describing what the historical transaction data describes and what the identity-based recommendation comprises (i.e. data descriptions). Those statements are insufficient to significantly alter the eligibility analysis. Item i) above introduces the additional elements/functions of retrieving data and generating a recommendation. This language further elaborates the abstract idea of providing a recommendation identified in the analysis of independent claims 1, 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1, 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to claims 6, 13 and 20, the claims recite item j) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the recommendation is (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of providing a recommendation identified in the analysis of independent claims 1, 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1, 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to claims 7 and 14, the claims recite item k) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the data includes (i.e. other type of data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of providing a recommendation identified in the analysis of independent claims 1, 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1, 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
Therefore, while the additional language g) - k) of dependent claims 3- 7, 10-14 and 17-20 slightly modify the analysis provided with respect to independent claims 1, 8 and 15, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
With respect to claims 2, 9 and 16, the claims are directed to item f) above, which represents the additional elements/functions of training a machine learning model, receiving an output and generating a recommendation based on the output. This language further elaborates the abstract idea of providing a recommendation identified in the analysis of independent claims 1, 8 and 15. The additional elements/functions integrate the abstract idea into a practical application by applying the judicial exception in some other meaningful way. Therefore, claims 2, 9 and 16 are eligible under step 2A of the analysis.
Therefore, the additional language f) of dependent claims 2, 9, 16 significantly alter the analysis provided with respect to independent claims 1, 8 and 15. These additional elements/functions are sufficient to render the dependent claims eligible, as detailed above. Therefore, dependent claims 2, 9, 16 are 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.
Claims 1-3, 5, 7-10, 12, 14-17 and 19 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Deshpande et al. (US 2019/0180255 A1), hereinafter Deshpande in view of Kamijoh et al. (US 2020/0110813 A1), hereinafter Kamijoh.
With respect to claims 1, 8 and 15, Deshpande teaches a system, comprising: a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory; a non-transitory computer-readable medium comprising machine-readable instructions executable by a processor of a computing device; and a method (Utilizing machine learning to generate recommendations for a transaction based on loyalty credits and stored-value cards) comprising:
accessing an interconnected transaction ledger containing historical transaction data associated with a user account (see Fig. 4, step 410, paragraph [0062]: “As shown in FIG. 4, process 400 may include receiving account information, loyalty credits information, and stored-value card information associated with users (block 410). For example, transaction platform 220 may receive account information, loyalty credits information, and stored-value card information associated with users. In some implementations, transaction platform 220 may receive prior transaction information of other users. In some implementations, the prior transaction information may be received from other users of transaction platform 220, from third party resources (e.g., devices associated with banks, credit unions, financing companies, sellers of products, sellers of services, and/or the like), and/or the like.”);
performing a balancing and control operation (see paragraph [0064]: “…Transaction platform 220 may store the prior transaction information so that transaction platform 220 may perform further processing on the prior transaction information. In some implementations, transaction platform 220 may provide security features so that prior transaction information is maintained in confidence. For example, transaction platform 220 may apply one or more types of encryption, tokenization, authentication, and/or other security techniques to protect the prior transaction information while the prior transaction information is stored (e.g., in a database) and/or when the prior transaction information is transmitted (e.g., over a network).” See also Fig. 1C, paragraph [0021]: “As shown in FIG. 1C, and by reference number 140, the transaction platform may validate the transaction information (e.g., the account information associated with the user, the stored-value card information associated with the user, the loyalty information associated with the user, and/or the like). In some implementations, the transaction platform may validate the quantities of cash in the accounts (e.g., Account 1) of the user by querying devices associated with the accounts (e.g., devices associated with banks, credit card companies, debit card companies, and/or the like) of the user, and verifying that the quantities of cash in the accounts are correct. In some implementations, the transaction platform may validate the quantities of cash on the stored-value cards (e.g., Card 1) of the user by querying devices associated with the stored-value cards (e.g., devices associated with gift cards, calling cards, and/or the like) of the user, and verifying that the quantities of cash on the stored-value cards are correct. In some implementations, the transaction platform may validate cash values of the loyalty credits (e.g., Loyalty 1) of the user by querying devices associated with the loyalty credits (e.g., devices associated with loyalty cards, rewards cards, points cards, advantage cards, club cards, and/or the like) of the user, and verifying that the cash values of the loyalty credits are correct. In some implementations, if any of the transaction information is incorrect, the transaction platform may automatically adjust the transaction information to a verified value, may automatically disregard the incorrect transaction information, may provide the incorrect transaction information to the client device (e.g., and may ask the user to provide correct transaction information), and/or the like.”);
processing the historical transaction data via a knowledge system comprising a machine learning model (see Fig. 4, steps 420 and 430, paragraph [0065]: “As further shown in FIG. 4, process 400 may include training a model based on the account information, the loyalty credits information, and the stored-value card information (block 420). For example, transaction platform 220 may train a model based on the account information, the loyalty credits information, and the stored-value card information. In some implementations, transaction platform 220 may train the model to determine patterns associated with prior transactions, stored-value cards, and loyalty credits associated with other users. In some implementations, the model may include a collaborative filtering model, an artificial intelligence model, a machine learning model, a naïve Bayes biased classifier model, a deep learning neural network model, a neural network model, a support vector machine model, and/or the like.”; collaborative filtering model , paragraph [0067]; paragraph [0068]: “As further shown in FIG. 4, process 400 may include utilizing the trained model to generate and provide recommendations to a client device of a user that requests a transaction (block 430)...”);
generating an identity-based recommendation, wherein the identity-based recommendation comprises a proposed transaction between a first financial subsystem and a second financial subsystem (see Fig. 4, collaborative filtering model, step 430, paragraph [0067]: “In some implementations, transaction platform 220 may utilize a collaborative filtering model. In some implementations, the collaborative filtering model may filter for information or patterns using techniques involving collaboration among multiple agents, viewpoints, data sources, and/or the like. For example, the collaborative filtering model may make automatic predictions (e.g., filtering) about interests of a user by collecting preferences or taste information from many users (e.g., collaborating). In this case, the collaborative filtering model may determine that if a first user has a preference that is the same as a preference of a second user with respect to a particular choice (e.g., to select a particular type of vehicle for purchase), then the first user is more likely to have a preference that is the same as a preference of a second user with respect to a different particular choice (e.g., to use a particular stored-value card to be applied to a down payment for a vehicle loan).”; paragraph [0068]: “...For example, transaction platform 220 may utilize the trained model to generate and provide recommendations to client device 210 of a user that requests a transaction....”); and
sending the identity-based recommendation to a user-device associated with the user account (see Fig. 4, provide recommendations, step 430, paragraph [0068]: “...For example, transaction platform 220 may utilize the trained model to generate and provide recommendations to client device 210 of a user that requests a transaction....”).
Deshpande does not explicitly disclose a method, system and medium comprising: the balancing and control operation is to confirm a measure of accuracy of the interconnected transaction ledger.
While this language represents the intended use of the balancing and control operation, therefore not given patentable weight, this difference is insufficient to distinguish the claims over Deshpande. However, in the interest of compact prosecution and assuming weight was to be given to the intended use recitations above, Kamijoh discloses a method, system and medium (Blockchain implementing reliability database) comprising:
the balancing and control operation is to confirm a measure of accuracy of the interconnected transaction ledger (see Reliability value, paragraph [0077]: "...For example, the reliability value may represent a level of trust associated with one or more of the off-chain data source and a data element provided from the off-chain data source. The value may simply state “TRUST” or “DO NOT TRUST.” As another example, the reliability value may be a rating that is somewhere in between a range of values (e.g., between 0 to 1.0, −1.0 to 1.0, 0 to 100, etc.) In some embodiments, the reliability value may be received from a trusted service that is agreed upon by the blockchain nodes in advance..."; Fig. 6D, API for storing and retrieving reliability data from a reliability database and/or a trusted service, paragraphs [0098] and [0099]: paragraph [0099]: “...For example, the smart contract 630 may include an API that can receive a request from a client for reliability of an external data source, retrieve a reliability value of the external data source for a particular category, and output the reliability. As another example, the smart contract 630 may include an API that can request a reliability value from a trusted service when it determines that a reliability value for the external data source is not stored in the reliability database. As another example, the smart contract 630 may include an API that agrees on a consensus of newly coming trusted data of the external data source prior to storing the trusted data in the reliability database.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the mechanism for keeping and updating a reliability of an external data source as disclosed by Kamijoh in the method, system and medium of Deshpande, the motivation being to verify that the external source or the data provided from an external source is reliable, for example when an external source becomes unreliable due to being compromised by a hacker or other malicious party (see Kamijoh, paragraph [0005]).
With respect to the BRI of the claims, Examiner notes that claims 1, 8 and 15 recite “wherein the identity-based recommendation comprises a proposed transaction between a first financial subsystem and a second financial subsystem”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claims 1, 8 and 15 recite “performing a balancing and control operation to confirm a measure of accuracy of the interconnected transaction ledger” , a statement of intended use or field use. See MPEP 2114 II.
With respect to claims 2, 9 and 16, the combination of Deshpande and Kamijoh teaches all the subject matter of the method, system and medium as described above with respect to claims 1, 8 and 15. Furthermore, Deshpande discloses a method, system and medium further comprising:
determining a set of input data based at least in part on the historical transaction data (see Fig. 4, step 420, paragraph [0065]: “As further shown in FIG. 4, process 400 may include training a model based on the account information, the loyalty credits information, and the stored-value card information (block 420).”);
training the machine learning model on the set of input data (see paragraph [0065]: “...For example, transaction platform 220 may train a model based on the account information, the loyalty credits information, and the stored-value card information. In some implementations, transaction platform 220 may train the model to determine patterns associated with prior transactions, stored-value cards, and loyalty credits associated with other users. In some implementations, the model may include a collaborative filtering model, an artificial intelligence model, a machine learning model, a naïve Bayes biased classifier model, a deep learning neural network model, a neural network model, a support vector machine model, and/or the like.”; paragraph [0066]: “In some implementations, transaction platform 220 may train the model by using a machine learning algorithm or a similar technique”);
receiving an output from the machine learning model (see Fig. 4, step 430, paragraph [0068]: “As further shown in FIG. 4, process 400 may include utilizing the trained model to generate and provide recommendations to a client device of a user that requests a transaction (block 430). For example, transaction platform 220 may utilize the trained model to generate and provide recommendations to client device 210 of a user that requests a transaction."); and
generating the identity-based recommendation based at least in part on the output of from the machine learning model (see paragraph [0069]: “In some implementations, transaction platform 220 may utilize the trained model to generate recommendations for the transaction. In some implementations, transaction platform 220 may utilize the information included the request with the trained model in order to determine similarities between the prior transaction information and the request for the transaction, and to generate the recommendations based on the similarities. Transaction platform 220 may provide the recommendations to client device 210, and client device 210 may provide the recommendations for display to the user.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 3, 10 and 17, the combination of Deshpande and Kamijoh teaches all the subject matter of the method, system and medium as described above with respect to claims 1, 8 and 15. Furthermore, Kamijoh discloses a method, system and medium further comprising: identifying a data transfer in the interconnected transaction ledger; confirming the data transfer is completed, on time, and accurate; and adjusting the measure of accuracy of the interconnected transaction ledger (see paragraph [0075]: “According to various embodiments, a client can get the reliability value of the data or data source that they want to evaluate, even if it's not in the reliability DB. Here, a peer node may recursively determine the reliability value based on external sources (e.g., organizations) that have some sort of relationship with the data source. The reliability data within the reliability DB may include the reliability value with (source, data category, timestamp, reliability value, etc.) format, where “source” may be a name of a company or a group...."; Fig. 5E, paragraph [0090]: “FIG. 5E illustrates a method 550 of determining reliability of an external data source based on recursively retrieved data, according to example embodiments. Referring to FIG. 5E, in 551, the method may include receiving a request for trust information of an off-chain data source from a client. The request may include a request from a client that is about to conduct a transaction on a blockchain based on data from the off-chain data source. In 552, the method may include detecting that the trust information of the off-chain data source is not stored in a distributed ledger shared among a plurality of peer nodes. For example, the peer node may determine whether a reliability value of the off-chain data source is stored within a reliability database stored on the distributed ledger.”; paragraph [0091]: “In 553, the method may include retrieving reliability data recursively identified and retrieved from a plurality of external sources having different reliability information of the off-chain data source. In some embodiments, the reliability data may be recursively identified from among the plurality of external sources until a threshold number of external sources has been reached. In 554, the method may include determining a reliability value based on a combination of the recursively retrieved reliability data from the plurality of external sources, and in 555, transmitting the determined reliability value to the client.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 5, 12 and 19, the combination of Deshpande and Kamijoh teaches all the subject matter of the method, system and medium as described above with respect to claims 1, 8 and 15. Furthermore, Deshpande discloses a method, system and medium further comprising:
retrieving the historical transaction data associated with a user account, wherein the historical transaction data describes the user account applying reward points from the first financial subsystem to the second financial subsystem (see loyalty information associated with the user, paragraph [0071]); and
generating the identity-based recommendation, wherein the identity-based recommendation comprises a transfer of reward points from the first financial subsystem to the second financial subsystem (see paragraph [0080]: “In some implementations, transaction platform 220 may determine and validate a quantity of loyalty credits on the particular loyalty card, and may determine and validate a quantity of cash on the particular stored-value card. In some implementations, transaction platform 220 may provide information indicating the quantity of loyalty credits on the particular loyalty card and the quantity of cash on the particular stored-value card to client device 210. Client device 210 may enable the user to indicate how many loyalty credits on the particular loyalty card to apply to the down payment for the transaction, and an amount of the quantity of cash on the particular stored-value card to apply to the down payment. Client device 210 may provide, to transaction platform 220, information indicating how many loyalty credits on the particular loyalty card to apply to the down payment, and the amount of the quantity of cash on the particular stored-value card to apply to the down payment. Transaction platform 220 may receive the information indicating how many loyalty credits on the particular loyalty card to apply to the down payment, and the amount of the quantity of cash on the particular stored-value card to apply to the down payment.”).
Regarding the BRI of the claims, Examiner notes that claims 5, 12 and 19 recite “wherein the historical transaction data describes the user account applying reward points from the first financial subsystem to the second financial subsystem”; “wherein the identity-based recommendation comprises a transfer of reward points from the first financial subsystem to the second financial subsystem”, language directed to non-functional descriptive material. See MPEP 2111.05. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 7 and 14, the combination of Deshpande and Kamijoh teaches all the subject matter of the method and system as described above with respect to claims 2 and 9. Furthermore, Deshpande discloses a method and system wherein the set of input data includes third-party data received from a third-party data service. (see paragraph [0062]: “...In some implementations, the prior transaction information may be received from other users of transaction platform 220, from third party resources (e.g., devices associated with banks, credit unions, financing companies, sellers of products, sellers of services, and/or the like), and/or the like.”); Regarding the BRI of the claims, Examiner notes that claims 7 and 14 recite “wherein the set of input data includes third-party data received from a third-party data service”, language directed to non-functional descriptive material.
Claims 4,6, 11, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Deshpande (US 2019/0180255 A1), in view of Kamijoh (US 2020/0110813 A1), and in view of Allen (US 2010/0010930 A1).
With respect to claims 4, 11 and 18, the combination of Deshpande and Kamijoh teaches all the subject matter of the method, system and medium as described above with respect to claims 1, 8 and 15. The combination of Deshpande and Kamijoh does not explicitly teach a method, system and medium further comprising: monitoring transactions associated with the user account; determining a payment was not made; and suspending access of the user account to the first financial subsystem and to the second financial subsystem based at least in part on the payment not being made.
However, Allen discloses a method, system and medium (Providing a real time credit score as part of a transaction request) further comprising:
monitoring transactions associated with the user account; determining a payment was not made; and suspending access of the user account to the first financial subsystem and to the second financial subsystem based at least in part on the payment not being made (see paragraph [0067]: ..."Credit risk may be assessed using transaction amounts, frequency, merchant type, etc. A credit score is calculated using up to date information reflecting a customer's creditworthiness and probability of default (Step 210).”; paragraph [0069]: “In one embodiment, PPS 150 accesses credit bureau information directly and RTSE 155 calculates a credit score by performing a forecast that considers factors such as, for example, transaction amount, recent transaction activity or frequency, accounts receivable data, payment history, customer profile information, demographic data, economic trends etc. These factors are assessed based upon data that may be provided by the TXA issuer (via AIS 180) or by a third party. For example, in one embodiment, the AIS 180 provides payment history, customer profile information and accounts receivable data to while PPS 150 receives other information regarding the customer's spending and payment habits, economic trends and demographic data from other external data sources 197. In one embodiment, RTSE 155 uses information related to the current transaction (i.e. the transaction that is requested for approval) such as the transaction amount, transaction location, transaction method (e.g. online, phone or in store) and merchant type to calculate the real time credit score.”; paragraph [0070]: “...the TXA history of one or more TXAs includes information regarding transaction amounts, TXA balance, transaction frequency, transaction locations, transaction dates and times, type of merchant, type of product, transaction approvals and denials and the like. Such TXA history provides up to date data for use in risk assessment and prediction methods.”; paragraph [0072]: “PPS 150 transmits the transaction authorization request to AIS 180 (Step 220). In one embodiment, AIS 180 may request additional data from PPS 150 such as, for example, the data that was used to calculate the real-time credit score, to enable the TXA issuer to make an even more informed credit decision. AIS 180 returns an authorization reply to PPS 150 (Step 225). The authorization reply may include an approval, a denial, a partial approval, a contingent approval or a request for additional data. PPS 150 transmits the authorization reply to MS 115 (Step 230) and MS 115 informs user 105 of the authorization decision (Step 235)”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the calculating a real time credit score each time a transaction request is received as disclosed by Allen in the method, system and medium of Deshpande and Kamijoh, the motivation being to enhancing the credit risk assessment process (see Allen, paragraph [0004]).
With respect to claims 6, 13 and 20, the combination of Deshpande and Kamijoh teaches all the subject matter of the method, system and medium as described above with respect to claims 1, 8 and 15. Furthermore, Deshpande discloses a method, system and medium wherein the identity-based recommendation is based at least in part on a [credit score] (see paragraph [0076]: “In some implementations, transaction platform 220 may determine transaction terms for the user based on the validation of the transaction information (e.g., the account information associated with the user, the stored-value card information associated with the user, the loyalty information associated with the user, and/or the like). In some implementations, transaction platform 220 may calculate a credit score for the user based on the transaction information, and may determine the transaction terms based on the credit score for the user. In some implementations, transaction platform 220 may provide the transaction information to a device associated with an entity (e.g., a bank, a credit union, a vehicle financing company, and/or the like) that is financing the transaction, and the device may calculate the credit score for the user and determine the transaction terms based on the credit score. In some implementations, the transaction terms may include information indicating a quantity of cash needed for a down payment, a rate of interest for a loan, a term for a loan, and/or the like.”).
The combination of Deshpande and Kamijoh does not explicitly teach a method, system and medium further comprising: [the credit score comprises] a frequency of a transaction and a type of the transaction in the historical transaction data.
However, Allen discloses a method, system and medium (Providing a real time credit score as part of a transaction request) further comprising:
[the credit score comprises] a frequency of a transaction and a type of the transaction in the historical transaction data (see paragraph [0067]: ..."Credit risk may be assessed using transaction amounts, frequency, merchant type, etc. A credit score is calculated using up to date information reflecting a customer's creditworthiness and probability of default (Step 210).”; paragraph [0069]: “In one embodiment, PPS 150 accesses credit bureau information directly and RTSE 155 calculates a credit score by performing a forecast that considers factors such as, for example, transaction amount, recent transaction activity or frequency, accounts receivable data, payment history, customer profile information, demographic data, economic trends etc. These factors are assessed based upon data that may be provided by the TXA issuer (via AIS 180) or by a third party. For example, in one embodiment, the AIS 180 provides payment history, customer profile information and accounts receivable data to while PPS 150 receives other information regarding the customer's spending and payment habits, economic trends and demographic data from other external data sources 197. In one embodiment, RTSE 155 uses information related to the current transaction (i.e. the transaction that is requested for approval) such as the transaction amount, transaction location, transaction method (e.g. online, phone or in store) and merchant type to calculate the real time credit score.”). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the calculating a real time credit score each time a transaction request is received as disclosed by Allen in the method, system and medium of Deshpande and Kamijoh, the motivation being to enhancing the credit risk assessment process (see Allen, paragraph [0004]).
Regarding the BRI of the claims, Examiner notes that claims 6, 13 and 20 recite “wherein the identity-based recommendation is based at least in part on a frequency of a transaction and a type of the transaction in the historical transaction data”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ladds et al. (US 2019/0197575 A1) disclose generating recommendations to maximize loyalty earnings, including analyzing loyalty data account data and transaction data to generate accurate recommendations for maximizing loyalty point earnings focused on the associated user.
Chalakudi et al. (US 2019/0057379 A1) disclose systems and methods for data file transfer balancing and control on blockchain, including an audit of past data file transfers to determine the data file transfers were accurate.
Lahrichi et al. (US 2020/0134716 A1) disclose systems and methods for determining credit worthiness of a borrower, including the output of a recommendation and/or approval or denial of a loan application based on results of a machine learning algorithm and various rules.
Chen (US 2021/0264459 A1) discloses a method of loyalty exchange transaction by using blockchain for reward point exchange, including monitor and discover interesting arbitrage and other trading opportunities that could be offered also own platform users.
Benson et al. (US 2005/0065839 A1) disclose methods, systems and computer program products for generating an aggregate report to provide a certification of controls associated with a data set, including identifying sources based on satisfying one or both of a dollar criterion and a risk criterion.
Hariramani et al. (US 2013/0024371 A1) disclose electronic offer optimization and redemption apparatuses, methods and systems, including generating recommendations for a user based on the user's prior aggregate purchase transaction behavior.
Lessin et al. (US 2019/0310888 A1) disclose allocating resources in response to estimated completion times for requests, including using a machine learning model to estimate an amount of time to complete the request based on the category and the actions associated with completing the request, wherein the machine learning model was trained using features characterizing a previous request that was completed by an agent and the time it took the agent to complete the previous request; and rating an agent's performance based in part on a comparison of an amount of time it takes an agent to complete the request and the estimated amount of time to complete the request generated by the machine learning model.
Anton et al. (US 2016/0344737 A1) disclose uniqueness and auditing of a data resource through an immutable record of transactions in a hash history, including maintaining uniqueness of a “data organism” within a datastore during a transaction.
Barinov et al. (US 2018/0025181 A1) disclose system and method for verifying data integrity using a blockchain network, including storing high volumes of data and ensuring integrity and authenticity of the data using blockchain technology.
Olson et al. (US 2022/0215418 A1) disclose decentralized computer systems and methods for loyalty points payments using distributed ledgers, including conducting payment processing with loyalty points using distributed ledgers across an intermediary payment network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights