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 .
Applicant filed a response dated September 17, 2025 in which claims 1, 4, 6, 9, and 12 have been amended. Therefore, claims 1-16 are currently pending in the application.
Priority
The priority date for Application 18/415,530 is January 17, 2024.
Application 18/415,530 was filed on January 17, 2024 and is a CIP of 16/528,501 July 31, 2019. Applicant is advised that claims 1-16 do not get the priority date of July 31, 2019 because the parent application 16/528,501 does not support the limitations of at least claims 1 and 9, e.g.,
“receive, by a loan management system, a plurality of data comprising borrower information, revolving credit account information, and lender risk score threshold;
initiate a data imputation process that automatically supplements missing or inconsistent data elements by cross-referencing at least one external credit bureau database and the lender risk score threshold to generate normalized input values, thereby improving data integrity for machine processing;
for each category of the plurality of data, determining a categorization and a confidence score by applying a machine learning model for the category with the plurality of data as input wherein each confidence score is stored with metadata identifying a corresponding data category to enable model transparency and auditability;
determine a weighted decision that combines the categorization and the confidence score for each category of the plurality of data wherein the lender risk score threshold is dynamically incorporated as a boundary condition in the weighted decision, such that outputs falling outside the threshold trigger adjustment or rejection of the weighted decision; and
providing a graphical user interface (GUI) comprising a display element, wherein the display element represents the weighted decision and corresponding confidence scores using a visual indicator selected from a color gradient, slider, or progress bar that updates in real time responsive to changes in the plurality of data, thereby improving interaction between the loan management system and a borrower or lender user.”
Therefore, the parent applications do not satisfy the written description requirement of 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, under 35 U.S.C. 120 for the invention claimed in the present application and the present application is not entitled to the benefit of the earlier filing dates.
As such, the priority date for the present application is January 17, 2024.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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-16 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method and system which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A system for determining an interest rate for a loan program, the system comprising: one or more processors configured by machine-readable instructions to: receive, by a loan management system, a plurality of data comprising borrower information, revolving credit account information, and
lender risk score threshold;
initiate a data imputation process that automatically supplements missing or inconsistent data elements by cross-referencing at least one external credit bureau database and the lender risk score threshold to generate normalized input values, thereby improving data integrity for machine processing;
for each category of the plurality of data, determining a categorization and a confidence score by applying a machine learning model for the category with the plurality of data as input,
wherein each confidence score is stored with metadata identifying a corresponding data category to enable model transparency and auditability;
determine a weighted decision that combines the categorization and the confidence score for each category of the plurality of data,
wherein the lender risk score threshold is dynamically incorporated as a boundary condition in the weighted decision, such that outputs falling outside the threshold trigger adjustment or rejection of the weighted decision; and
providing a graphical user interface (GUI) comprising a display element, wherein the display element represents the weighted decision and
corresponding confidence scores using a visual indicator selected from a color gradient, slider, or progress bar that updates in real time responsive to changes in the plurality of data, thereby improving interaction between the loan management system and a borrower or lender user.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate risk and loan management. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Finally, the claims also recite the use of a machine learning model to determine a weighted decision. This is a mathematical calculation.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “A system for determining an interest rate for a loan program, the system comprising: one or more processors configured by machine-readable instructions to:”, “a loan management system”, “a credit bureau database”, “and “graphical user interface (GUI) comprising a display element”, to perform the steps of “initiating”, “determining”, and “providing”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity or mathematical calculation. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate risk and loan management in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0044] In some embodiments, as alluded to above, a borrower may access unsecured lending platform 120 via a client computing devices 104 via a user interface (not shown). For example, client computing device 104 may be a desktop computer or a mobile device (e.g., a tablet computing device a cellular phone). The interface may be used to receive and transmit information to unsecured lending platform 120 via a communication network 103, as explained above.”
Additionally, the claimed “initiate a data imputation process that automatically supplements missing or inconsistent data elements by cross-referencing at least one external credit bureau database and the lender risk score threshold to generate normalized input values, thereby improving data integrity for machine processing”, is merely applying the generic computer technology to the underlying abstract idea. Further, the clause “thereby improving data integrity for machine processing” is interpreted as a statement of intended use and is therefore given limited patentable weight.
Furthermore, the Specification discloses “[0054] Various machine learning models may be used. For example, the machine learning models and techniques may include classifiers, decision trees, neural networks, gradient boosting, and similar machine learning models and techniques. The machine learning models may be trained previously according to historical correspondences between input parameters and corresponding interest rates and lender risk score. The input parameters may include those described above, for example such as borrower's employment information, FICO score, home ownership, additionally, lender's risk data, such as repayment success, and other such similar data may be used. Once the machine learning models have been trained, new input parameters may be applied to the trained machine learning model as inputs. In response, the machine learning models may provide the interest rate and risk score as outputs. [0055] Some embodiments include the training of the machine learning models. The training may be supervised, unsupervised, or a combination thereof, and may continue between operations for the lifetime of the system. The training may include creating a training set that includes the input parameters and corresponding interest rate determinations described above.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. 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. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “A system for determining an interest rate for a loan program, the system comprising: one or more processors configured by machine-readable instructions to:”, “a loan management system”, “a credit bureau database”, “and “graphical user interface (GUI) comprising a display element”, to perform the steps of “initiating”, “determining”, and “providing”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate risk and loan management in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claim 9 is substantially similar to claim 1, thus, it is rejected on similar grounds.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 2-8 and 10-16 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-16 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 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-4 and 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over So, U.S. Patent Application Publication Number 2018/0357714; in view of Hunter, U.S. Patent Application Publication Number 2021/0073287; in view of Zeller, U.S. Patent Application Publication Number 2007/0050289; in view of Nienstedt, U.S. Patent Application Publication Number 2023/0268070.
As per claim 1,
So explicitly teaches:
A system for determining an interest rate for a loan program, the system comprising: one or more processors configured by machine-readable instructions to: receive, by a loan management system, a plurality of data comprising borrower information, revolving credit account information, and
(So US20180357714 at paras. 6-8, 58-60, 63-65) ("[0007] In an embodiment, a computer-implemented method is provided. The method includes accessing, by a processor, a behavioral data of an entity. The behavioral data comprises at least one of a primary data and a secondary data. The primary data associated with one or more assets of the entity comprises historical transaction data of the entity with one or more financial institutions. The secondary data accessed from an external system comprises at least a credit information and a business transactions information of the entity. The method also includes generating, by the processor, a unified model for the entity based on the behavioral data of the entity. Further, the method includes determining, by the processor, a credit rating for the one or more assets of the entity based on the unified model by performing at least predicting, by the processor, using one or more machine learning models a plurality of risk metrics based on the unified model and computing, by the processor, the credit rating for the entity based on the plurality of risk metrics and the confidence measure. Each risk metric associated with a risk score and a confidence measure." "[0063] The risk engine 208 performs risk assessment for the borrower based on the behavioral data associated with the borrower. The risk engine 208 includes a model data module 210 and a pattern repository 212. The model data module 210 ingests behavioral data from the data fusion model 206 to generate a borrower model (also referred to as ‘a unified model’) corresponding to the behavioral data of the borrower. The borrower model is based on the primary data and the secondary data. In an example, the borrower model captures behavior of the borrower from the unconfirmed assets (e.g., invoices, purchase orders and inventory) provided by the borrower in the supplier portal 202 and the secondary data obtained from the data source model 204. The borrower model can be modeled using statistical modeling techniques such as Gaussian mixture model or using neural networks. Further, the anonymized ID generated by the data fusion module 206 ensures that no sensitive data such as PII are used when the primary data and the secondary data are fused to generate the unified model in the model data module 210.")
for each category of the plurality of data, determining a categorization and a confidence score by applying a machine learning model for the category with the plurality of data as input,
(So US20180357714 at paras. 53-55, 66-68) ("[0054] In some example embodiments, the risk management system 108 predicts a plurality of risk metrics based on the unified model using one or more machine learning models. In an example scenario, risk metrics such as a non-payment risk, a late payment risk, a dilution risk, a dispute risk, a fraud risk, a delivery risk and a shipment quality risk are determined for the entity based on the unified model. Accordingly, each risk metric is associated with a risk score and a confidence measure." "[0067] The risk score computation module 214 is coupled to the risk engine 208 and is configured to determine a credit rating based on a plurality of risk metrics. The plurality of risk metrics are determined based on the unified model generated by the risk engine 208. More specifically, the risk metrics are determined based on the primary data from the supplier portal 202 and the secondary data obtained from the data source module 204. The risk score computation module 214 generates the risk metrics in terms of a risk score and a confidence measure. Examples of the risk metrics include, but are not limited to, overall risk, non-payment risk, late payment risk, dilution risk, dispute risk, fraud risk, delivery and shipment quality risk. The risk score is computed for each risk metric as a numerical value ranging between 0 and 100 with 100 being the highest risk. Further, each risk metric is assigned a confidence measure of low, medium, high based on liability for the risk score. For example, if the borrower furnishes unconfirmed assets (Invoice #2, invoice #5, PO #1) for acquiring financing, the risk metrics are computed based on the unconfirmed assets, secondary information from alternate data sources and historical data of the borrower (acquired from other banks) available in the pattern repository 212 of the risk engine 208.")
determine a weighted decision that combines the categorization and the confidence score for each category of the plurality of data,
(So US20180357714 at paras. 53-55, 66-70) ("[0069] In an example scenario, the plurality of risk metrics are combined together using a weighing factor, such as a cost associated with the risk metric for determining the credit rating for the borrower. For instance, each risk metric may be associated with a different cost, such as, a non-payment risk carries a cost of 0.5 than late payment by a couple days (late payment risk) associated with a cost of 0.1. It shall be noted that the cost associated with each metric may be a pre-set value provided by a financial institution offering loan pricing or may be factory-installed, fixed value for all determining all credit ratings. Accordingly, the credit rating is a single unified risk score that can be used for decision-making by the financial institution offering a pricing for the one or more assets furnished by the borrower.")
providing a graphical user interface (GUI) comprising a display element, wherein the display element represents the weighted decision and
(So US20180357714 at paras. 79-81) ("[0080] The model explanation module 316 is configured to provide explanations for the credit rating and the plurality of risk metrics. The model explanation module 316 employs one or more algorithms that are used to interpret the behavior model of the prediction algorithm. For each prediction of a risk score associated with a risk metric, the explanations algorithm will find key drivers that caused the prediction to take on the risk value computed. For example, the explanation algorithm uses all features and generates a local model to understand which factors are most influential in causing the particular risk score. Accordingly, a list of rank ordered reasons for the risk score based on important variables, along with whether they caused the risk score to go up or go down are displayed. In a non-limiting example, the model explanation module 316 may display a text depicting confidence measure associated with each risk metric of the plurality of risk metrics. For example, a non-payment risk of 90% is displayed along with a confidence measure associated with text ‘High’. The confidence measure indicates that the non-payment risk associated with the customer 302 is high. Optionally, the model explanation module 316 may provide a brief description indicating why the prediction module 314 predicted a risk score for a risk metric, for example, “late-payment risk is 90% is high as the customer 302 has paid late for creditors (Bank 1, Bank 2) by 200-250 days”.")
So does not explicitly teach, however, Hunter teaches:
wherein each confidence score is stored with metadata identifying a corresponding data category to enable model transparency and auditability;
(Hunter US20210073287 at paras. 169-171, 244-246, 346-348, 414-416) ("[0346] The directed graph portions enclosed by the box 3220 may be converted into a set of feature values shown in table 3240. In some embodiments, one or more of the features surrounded by the box 3241 may be obtained from a list of pre-determined features. Some embodiments may be able to refer to multiple lists of pre-determine features and choose one or more of the multiple lists based on properties associated with the directed graph of a smart contract program or other elements of the smart contract program. For example, some embodiments may determine that a directed graph is associated with a metadata category “loan” and, in response, indicate that transaction scores associated with a unit of currency should be collected." "[0347] Alternatively, or in addition, some embodiments may adapt to different sets of features for specific vertices or vertex types (e.g., a vertex type defined by being a vertex associated with a specific category label) by determining one or more features based on a set of rules, decision trees, or implementations of other symbolic AI operations. For example, some embodiments may determine that one or more vertices surrounded by the box 3220 includes an expiry value and, in response, determine that “expiry” is a feature of the directed graph. Alternatively, or in addition, some embodiments may use a rule or other symbolic AI operation to determine which feature values to collect based on another feature of a vertex, such as a category label. For example, some embodiments may determine that a directed graph having the directed graph portion surrounded by the box 3220 has the category label “obligation” and, in response, obtain features from data that is associated with the vertex and indicated as being present in “obligation” vertices. Such features may include a “conditions,” feature, where a corresponding feature value may include an array of conditional statement identifiers, a “condition threshold” feature, where a corresponding feature value may include one or threshold values or ranges, or the like. Some embodiments may increase visualization and analytical capabilities by including one or more operations to adapt to different vertex data." "[0415] In some embodiments, the process 4200 may include obtaining an outcome score type based on data associated with the log of states, as indicated by block 4206. As further discussed below, some embodiments may select different learning models or different model parameters based on an outcome score type. In some embodiments, a user may select one or more outcome score types in a UI and send the selected outcome score type in a message. For example, some embodiments may obtain a first outcome score type, where the corresponding first outcome score of the first outcome score type may indicate whether a program modeled by the directed graph is likely to satisfy a condition of a prohibition vertex, where the prohibition vertex may include a. Alternatively, or in addition, some embodiments may obtain a second outcome score type that indicates whether a program modeled by the directed graph is likely to result in an entity triggering a “rights” vertex such that a condition of the “rights” vertex is activated. Alternatively, or in addition, some embodiments may obtain a third outcome score type, where the outcome score having that third type that indicates whether a program modeled by the directed graph is likely to result in a program triggering an external activity, such as a security audit. Alternatively, or in addition, some embodiments may obtain a fourth outcome score type that indicates whether a program modeled by the directed graph is likely to result in malicious behavior, where behaviors observed for an entity may indicate false or malicious activity of the entity.")
wherein the lender risk score threshold is dynamically incorporated as a boundary condition in the weighted decision, such that outputs falling outside the threshold trigger adjustment or rejection of the weighted decision; and
(Hunter US20210073287 at paras. 169-171, 242-245) ("[0170] In some embodiments, each of the smart contracts represented by the directed graphs 610, 650, 710, and 1010 may be analyzed using a symbolic AI system to determine one or more multi-protocol scores. For example, each of the smart contracts represented by the directed graphs 610, 650, 710, and 1010 may be analyzed to produce multi-iteration scores such as average scores for each smart contract and a kurtosis value of expected scores. In some embodiments, the analysis may use the same rules to govern the behavior entities in the smart contract by basing the rules on logic types and vertex statuses instead of the contexts of specific agreements. For example, each smart contract simulation may be simulated with a set of rules that include a rule that the probability that a rights norm to cure is triggered instead of a rights norm to accelerate being triggered is equal to 90%. The multi-iteration scores may then be further analyzed to determine a multi-protocol score. For example, based on a multi-iteration score representing a risk score associated with each of the smart contracts, the total exposed risk of a first entity with respect to a second entity may be determined, where the total exposed risk may be a multi-protocol score." "[0244] In some embodiments, the intelligent agent may use the results of the initial set of self-play operations to train a plurality of neural networks in combination with additional MCTS operation. The intelligent agent may begin at a first vertex of a directed graph and traverse the directed graph by proceeding to an adjacent vertex determined by the set of directed edges connected to the first vertex. Each configuration of the directed graph may be of a different program state or be otherwise associated with a different program state. For example, the intelligent agent may traverse to a first child vertex of an initial directed graph from a starting vertex. The intelligent agent may proceed to expand the directed graph to simulate evolution of its associated program state until arriving at a terminal child vertex and ending at a terminal program state. In some embodiments, performing an MCTS operation may include determining a maximum upper confidence bound (UCB) score, where the UCB score may be based on an exploration weight and a total weight score, where the exploration weight is correlated with exploring less-visited nodes and the total weight score is correlated with following the vertices associated with the greatest total reward values.")
corresponding confidence scores using a visual indicator selected from a color gradient, slider, or progress bar that updates in real time responsive to changes in the plurality of data, thereby improving interaction between the loan management system and a borrower or lender user.
(Hunter US20210073287 at paras. 68-69,193, 244-246, 272-274, 384-387) ("[0244] In some embodiments, the intelligent agent may use the results of the initial set of self-play operations to train a plurality of neural networks in combination with additional MCTS operation. The intelligent agent may begin at a first vertex of a directed graph and traverse the directed graph by proceeding to an adjacent vertex determined by the set of directed edges connected to the first vertex. Each configuration of the directed graph may be of a different program state or be otherwise associated with a different program state. For example, the intelligent agent may traverse to a first child vertex of an initial directed graph from a starting vertex. The intelligent agent may proceed to expand the directed graph to simulate evolution of its associated program state until arriving at a terminal child vertex and ending at a terminal program state. In some embodiments, performing an MCTS operation may include determining a maximum upper confidence bound (UCB) score, where the UCB score may be based on an exploration weight and a total weight score, where the exploration weight is correlated with exploring less-visited nodes and the total weight score is correlated with following the vertices associated with the greatest total reward values." "[0386] Some embodiments may visually distinguish a prioritized vertex by showing a corresponding vertex visualization as having a different color, a different size, a different shape, a different animation (e.g., vibrating), or the like. Some embodiments may include a UI element that causes a visualization region to visually distinguish the prioritized vertex, where the UI element may include a button, slider, menu, or the like. For example, some embodiments may include a visualization region that was initially displaying 50 vertices of a directed graph and an arrow button. Clicking on or pressing on the arrow button may cause the visualization region to focus on a graph section showing the prioritized vertex and highlight the prioritized vertex in a different color or cause the prioritized vertex to animate (e.g., vibrate, expand or contract in size, or the like) or otherwise be distinguishable from one or more surrounding vertices." "[0273] The box 1770 shows a directed graph representing a program state that may follow the program state shown by the directed graph of box 1740. In some embodiments, one or more operations described above for the process 1500 or the process 1600 may be used to determine an outcome program state shown by the directed graph of the box 1740, where the initial program state may be represented by the directed graph of the box 1710. As indicated by the directed graph in the box 1770, the rights norm of the fourth norm vertex 1731 may be triggered, activating a new obligation norm associated with the norm vertex 1732. In some embodiments, the new obligation norm may include norm conditions to determine whether a first entity transmits a payment amount to the second entity. For example, the new obligation norm may determine whether the first entity transmitted the entirety of a principal payment of a loan to the second entity.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So and Hunter, because it allows for an improved system where applications can store program state data on a tamper-evident ledger operating on the distributed computing platform. The use of a tamper-evident ledger or some other data systems distributed over multiple computing devices may increase the security and reliability of distributed applications.. (Hunter at Abstract and paras. 3-10).
So and Hunter do not explicitly teach, however, Zeller teaches:
receive . . . lender risk score threshold;
(Zeller US20070050289 at paras. 21-24) ("[0022] Using these methods, adaptive decision engine 20 produces a score that varies depending on the perceived risk associated with a credit application. For example, if the risk score is a value between 0 (low risk) and 100 (high risk), a threshold TH1 (28) for automatically approving loans can be set to, for example, 20 (FIG. 4a). In this case, if an application has a risk score of 10, it is automatically approved. As seen in FIG. 4b, the lender can set the risk threshold for automatic approval even higher, in which case a larger portion of applications will be automatically approved.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, and Zeller, because it allows for an improved rules system that automatically approves credit applications. (Zeller at Abstract and paras. 1-10).
So, Hunter, and Zeller do not explicitly teach, however, Nienstedt teaches:
initiate a data imputation process that automatically supplements missing or inconsistent data elements by cross-referencing at least one external credit bureau database and the lender risk score threshold to generate normalized input values, thereby improving data integrity for machine processing;
(Nienstedt US20230268070 at paras. 134-136) ("[0135] As discussed above, risk can vary significantly depending on factors other than the user's general health, age, past medical issues, and so forth. Thus, it can be desirable to obtain information about the user from sources that do not provide information that is directly related to health, although some such sources can include some health information. Real estate services 710 can be used to provide information about the patient's living situation. For example, if the patient's address is known, a real estate data company may maintain a database that indicates the type of building (e.g., apartment, single family home, single-room occupancy, dormitory, and so forth), rental or mortgage rates for the building (which can be a proxy for the user's financial resources, for example), condition, age, and so forth, which can impact a user's risk. For example, a user who lives in a building with several roommates and where a kitchen is shared by the residents of multiple units may be at significantly higher risk than a similar individual (e.g., similar age, similar health history) who resides in a single-family home. Credit bureaus 712 can provide information about the user's financial history, which may be indicative of the user's ability to afford medical treatment. For example, a user with little health history (for example, as provided by health providers 702) may nonetheless suffer from significant conditions. A lack of financial resources can mean that a user is likelier to delay or forego treatment. Employment data repositories 714 can provide information about a user's employment status, pay, and so forth. The employment information can indicate, for example, that a user likely has significant contact with the public (e.g., a restaurant waiter), works in crowded conditions (e.g., a kitchen worker), works in areas with poor ventilation and/or poor sanitation practices, and so forth. Such users may be at increased risk for contracting an infectious disease and/or developing significant symptoms. Transportation services 716 can provide information that indicates the user's level of access to public transportation, taxis, car share services, ride hailing services, rental bicycles, and so forth, which can be important as users who rely on mass transit such as busses and trains may be in frequent, close contact with other individuals who may be infected, placing them at higher risk of contracting an infectious disease. On the other hand, users without access to transportation services may be less likely seek out medical care, particularly if they do not live close to a health provider's facility.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, Zeller, and Nienstedt, because it allows for an improved system where a trained model can evolve over time, which can result in, for example, improved risk evaluation over time as the model is trained on additional data. (Nienstedt at Abstract and paras. 4-12, 133).
As per claim 2,
So explicitly teaches:
wherein the borrower information comprises at least one of a name associated with a borrower, a FICO score associated with the borrower, home ownership of the borrower, and employment status associated with the borrower.
(So US20180357714 at paras. 134-136) ("[0135] The processor 1015 may also be operatively coupled to the database 1010. The database 1010 is any computer-operated hardware suitable for storing and/or retrieving data, such as, but not limited to, behavioral data of a plurality of users and a plurality of unified models corresponding to the plurality of behavioral data. Further, the database 1010 may also store primary information such as but not limited to a plurality of invoices, purchase orders uploaded by the borrower and transaction details associated with the borrower at the plurality of financial institutions. The database 1010 may also store a table comprising information related to a plurality of invoice IDs, invoice date, invoice amount, due date, amount paid, offer amount (loan pricing amount), buyer name, buyer type, status and payment method. ")
As per claim 3,
So explicitly teaches:
wherein the revolving credit account information comprises a plurality of revolving credit accounts.
(So US20180357714 at paras. 6-8, 58-60, 63-65) ("[0007] In an embodiment, a computer-implemented method is provided. The method includes accessing, by a processor, a behavioral data of an entity. The behavioral data comprises at least one of a primary data and a secondary data. The primary data associated with one or more assets of the entity comprises historical transaction data of the entity with one or more financial institutions. The secondary data accessed from an external system comprises at least a credit information and a business transactions information of the entity. The method also includes generating, by the processor, a unified model for the entity based on the behavioral data of the entity. Further, the method includes determining, by the processor, a credit rating for the one or more assets of the entity based on the unified model by performing at least predicting, by the processor, using one or more machine learning models a plurality of risk metrics based on the unified model and computing, by the processor, the credit rating for the entity based on the plurality of risk metrics and the confidence measure. Each risk metric associated with a risk score and a confidence measure." "[0063] The risk engine 208 performs risk assessment for the borrower based on the behavioral data associated with the borrower. The risk engine 208 includes a model data module 210 and a pattern repository 212. The model data module 210 ingests behavioral data from the data fusion model 206 to generate a borrower model (also referred to as ‘a unified model’) corresponding to the behavioral data of the borrower. The borrower model is based on the primary data and the secondary data. In an example, the borrower model captures behavior of the borrower from the unconfirmed assets (e.g., invoices, purchase orders and inventory) provided by the borrower in the supplier portal 202 and the secondary data obtained from the data source model 204. The borrower model can be modeled using statistical modeling techniques such as Gaussian mixture model or using neural networks. Further, the anonymized ID generated by the data fusion module 206 ensures that no sensitive data such as PII are used when the primary data and the secondary data are fused to generate the unified model in the model data module 210.")
As per claim 4,
So and Hunter do not explicitly teach, however, Zeller teaches:
wherein the lender risk score threshold is obtained from a lender participating in the loan program.
(Zeller US20070050289 at paras. 21-24) ("[0022] Using these methods, adaptive decision engine 20 produces a score that varies depending on the perceived risk associated with a credit application. For example, if the risk score is a value between 0 (low risk) and 100 (high risk), a threshold TH1 (28) for automatically approving loans can be set to, for example, 20 (FIG. 4a). In this case, if an application has a risk score of 10, it is automatically approved. As seen in FIG. 4b, the lender can set the risk threshold for automatic approval even higher, in which case a larger portion of applications will be automatically approved.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, Zeller, and Nienstedt, because it allows for an improved rules system that automatically approves credit applications. (Zeller at Abstract and paras. 1-10).
Claims 9-12 are substantially similar to claims 1-4, thus, they are rejected on similar grounds.
Claims 5-6 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over So, U.S. Patent Application Publication Number 2018/0357714; in view of Hunter, U.S. Patent Application Publication Number 2021/0073287; in view of Zeller, U.S. Patent Application Publication Number 2007/0050289; in view of Nienstedt, U.S. Patent Application Publication Number 2023/0268070; in view of Sardari, U.S. Patent Application Publication Number 2024/0362644.
As per claim 5,
So, Hunter, Zeller, and Nienstedt do not explicitly teach, however, Sardari teaches:
wherein the weighted decision comprises an interest rate of a loan the borrower will likely find favorable.
(Sardari US20240362644 at paras. 94-96) ("[0095] At 726, transaction limits are set and/or lending terms are adjusted for a user 102 based at least in part on a risk metric(s), such as a user risk metric 200 determined at block 708 and/or an entity risk metric (e.g., a merchant risk metric 202) determined at block 704 for the selected entity. In some examples, the payment service computing platform 112 (e.g., a processor(s) thereof) may set transaction limits and/or adjust lending terms at block 726. For example, if the user risk metric 200 determined at block 708 satisfies a threshold, such as a medium risk threshold and/or a high risk threshold, the payment service computing platform 112, at block 726, may allow the user 102 to conduct a number or a frequency of transactions that does not exceed a particular number of transactions with one or more entities in the list 308 (returned as a search result 124) that are associated with entity risk metrics (e.g., merchant risk metrics 202) that satisfy another threshold, such as medium risk threshold and/or a high risk threshold. Alternatively, the payment service computing platform 112, at block 726, may allow the user to conduct transactions with the one or more entities (e.g., medium risk and/or high risk entities) at a transaction amount that does not exceed a particular transaction amount. In other words, a medium risk or high risk user may be limited in terms of the transactions that the user 102 is allowed to make with entities (e.g., merchants 110) of a particular risk level (e.g., medium risk and/or high risk entities). As another example, lending terms may be adjusted for such a user 102, such as by adjusting the repayment rate and/or amount for a user 102 who is offered a loan (e.g., a buy now, pay later loan) as a payment option for purchasing an item.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, Zeller, Nienstedt, and Sardari, because it allows for, in addition to conserving computing resources, the techniques, devices, and systems disclosed herein provide an improved search experience, as compared to conventional search techniques; namely, by returning search results that increase the likelihood of the user successfully completing a transaction. (Sardari at Abstract and paras. 1-2, 21).
As per claim 6,
So, Hunter, Zeller, and Nienstedt do not explicitly teach, however, Sardari teaches:
further the interest rate identified by the weighted decision is within the lender risk score threshold.
(Sardari US20240362644 at paras. 94-96) ("[0095] At 726, transaction limits are set and/or lending terms are adjusted for a user 102 based at least in part on a risk metric(s), such as a user risk metric 200 determined at block 708 and/or an entity risk metric (e.g., a merchant risk metric 202) determined at block 704 for the selected entity. In some examples, the payment service computing platform 112 (e.g., a processor(s) thereof) may set transaction limits and/or adjust lending terms at block 726. For example, if the user risk metric 200 determined at block 708 satisfies a threshold, such as a medium risk threshold and/or a high risk threshold, the payment service computing platform 112, at block 726, may allow the user 102 to conduct a number or a frequency of transactions that does not exceed a particular number of transactions with one or more entities in the list 308 (returned as a search result 124) that are associated with entity risk metrics (e.g., merchant risk metrics 202) that satisfy another threshold, such as medium risk threshold and/or a high risk threshold. Alternatively, the payment service computing platform 112, at block 726, may allow the user to conduct transactions with the one or more entities (e.g., medium risk and/or high risk entities) at a transaction amount that does not exceed a particular transaction amount. In other words, a medium risk or high risk user may be limited in terms of the transactions that the user 102 is allowed to make with entities (e.g., merchants 110) of a particular risk level (e.g., medium risk and/or high risk entities). As another example, lending terms may be adjusted for such a user 102, such as by adjusting the repayment rate and/or amount for a user 102 who is offered a loan (e.g., a buy now, pay later loan) as a payment option for purchasing an item.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, Zeller, Nienstedt, and Sardari, because it allows for, in addition to conserving computing resources, the techniques, devices, and systems disclosed herein provide an improved search experience, as compared to conventional search techniques; namely, by returning search results that increase the likelihood of the user successfully completing a transaction. (Sardari at Abstract and paras. 1-2, 21).
Claims 13-14 are substantially similar to claims 5-6, thus, they are rejected on similar grounds.
Claims 7-8 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over So, U.S. Patent Application Publication Number 2018/0357714; in view of Hunter, U.S. Patent Application Publication Number 2021/0073287; in view of Zeller, U.S. Patent Application Publication Number 2007/0050289; in view of Nienstedt, U.S. Patent Application Publication Number 2023/0268070; in view of Gundadi, U.S. Patent Application Publication Number 2023/0141307.
As per claim 7,
So, Hunter, Zeller, and Nienstedt do not explicitly teach, however, Gundadi teaches:
further comprising determining a plurality of pre- authorization sub-hold amounts, wherein each pre-authorization sub-hold amount is associated with each revolving credit account.
(Gundadi US20230141307 at paras. 34-36, 42-46) ("[0035] The reserve EMI application 220 includes a risk AI application 222, an external factor collection application 224, and a reserve amount application 226. The reserve EMI application 220 is configured to make a determination as to whether to activate and pay a customer's installment payment. For example, the reserve EMI application 220 automatically loans the customer funds to make an installment payment(s) on time when the customer has given preauthorization to do so. Alternatively, a reserve EMI application 220 may be configured to request authorization from a customer before opening a reserve EMI account to make an installment payment." "[0043] At step 304, a customer account balance is determined. The customer account balance determination may be specific to a single customer financial account, or may be a determination across a plurality of customer financial accounts held by the financial institution. In a first example, the customer financial account balance determination is determined with reference to the account that is used to previously pay the installment payment. In another example, the customer financial account balance determination is determined based on any account held by the customer. [0044] At step 306, it is determined whether the customer account has a balance sufficient to pay the installment payment amount. As explained above, the determination may be specific to a single customer account, or may be determined based on an overall balance of a plurality of customer accounts. [0045] If the customer account has a balance sufficient to pay the installment payment amount, the method 300 moves to step 308 and the installment payment is processed to be paid from the customer account. [0046] If the customer account does not have a balance sufficient to pay the installment payment, then the method 300 moves to step 310. At step 310, the reserve EMI determination process is initiated.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, Zeller, Nienstedt, and Gundadi, because it allows for a reserve equated monthly installment (EMI) account when insufficient funds exist in a customer financial account to pay a debt at a due date, and efficiency is increased when the system is able to communicating issues, such as a possible payment shortfall to customers and/or addressing the issue automatically by opening a loan. Further, the system is able to more effectively mitigate potential overdraft and/or non-payment problems associated with missing an installment payment. (Gundadi at Abstract and paras. 1-6, 29, 33).
As per claim 8,
So, Hunter, Zeller, and Nienstedt do not explicitly teach, however, Gundadi teaches:
wherein a sum of the plurality of pre-authorization sub- hold amounts is equal to an amount of an installment payment determined to pay off a loan during a term of the loan.
(Gundadi US20230141307 at paras. 34-36, 42-46) ("[0035] The reserve EMI application 220 includes a risk AI application 222, an external factor collection application 224, and a reserve amount application 226. The reserve EMI application 220 is configured to make a determination as to whether to activate and pay a customer's installment payment. For example, the reserve EMI application 220 automatically loans the customer funds to make an installment payment(s) on time when the customer has given preauthorization to do so. Alternatively, a reserve EMI application 220 may be configured to request authorization from a customer before opening a reserve EMI account to make an installment payment." "[0043] At step 304, a customer account balance is determined. The customer account balance determination may be specific to a single customer financial account, or may be a determination across a plurality of customer financial accounts held by the financial institution. In a first example, the customer financial account balance determination is determined with reference to the account that is used to previously pay the installment payment. In another example, the customer financial account balance determination is determined based on any account held by the customer. [0044] At step 306, it is determined whether the customer account has a balance sufficient to pay the installment payment amount. As explained above, the determination may be specific to a single customer account, or may be determined based on an overall balance of a plurality of customer accounts. [0045] If the customer account has a balance sufficient to pay the installment payment amount, the method 300 moves to step 308 and the installment payment is processed to be paid from the customer account. [0046] If the customer account does not have a balance sufficient to pay the installment payment, then the method 300 moves to step 310. At step 310, the reserve EMI determination process is initiated.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of So, Hunter, Zeller, Nienstedt, and Gundadi, because it allows for a reserve equated monthly installment (EMI) account when insufficient funds exist in a customer financial account to pay a debt at a due date, and efficiency is increased when the system is able to communicating issues, such as a possible payment shortfall to customers and/or addressing the issue automatically by opening a loan. Further, the system is able to more effectively mitigate potential overdraft and/or non-payment problems associated with missing an installment payment. (Gundadi at Abstract and paras. 1-6, 29, 33).
Claims 15-16 are substantially similar to claims 7-8, thus, they are rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on September 17, 2025 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1-16, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting , analyzing, and transmitting data to facilitate risk and loan management. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Finally, the claims also recite the use of a machine learning model to determine a weighted decision. This is a mathematical calculation.
Although the specification may discuss the relevant technical tools, the claims themselves do not include limitations that implement any specific improvement to computer technology or another technical field. Rather, the claims are directed to collecting , analyzing, and transmitting data to facilitate risk and loan management, which are concepts that fall within the abstract idea grouping of certain methods of organizing human activity, mental process, and the machine learning models fall within mathematical concepts.
Thus, the claims recite an abstract idea.
Applicant next argues that the amended features would integrate the abstract idea into a practical application. In particular, the applicant argues “they integrate that concept into a practical, computer-implemented application that improves system reliability, explainability, and usability:”
Examiner notes that the stated problems of overly inefficiency, lack of reliability, and burdensome user interactions relevant to managing loan transactions is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of a more efficient, reliable, and user friendly transaction process is part of the abstract idea, as it is merely involves data manipulation and analysis and the process could be completed manually or mentally or by pen and paper.
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea.
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the various specific, discrete steps carried out by the computer system are a routine, well-understood, and conventional function of a generic computer and, thus, are not sufficient to add significantly more. Per the specification, the recited computer elements and machine learning steps and model are described only at a high level of generality, (see Spec. at paras. [0044], [0054]). In view of the specification, the application of the computer elements and machine learning is merely being applied to the abstract idea.
The other limitations which are simply supporting the abstract idea correspond to insignificant extra-solution activity which do not transform the abstract idea into a patent eligible subject matter. Also, the functionality here is already present in the recited hardware, which is merely routine and conventional. Collecting, analyzing, and transmitting data is routine and conventional. There is no technological problem or solution identified. This is merely a business solution to transfer data between devices. (MPEP 2106.05 (f))
With respect to Applicant’s arguments as to the § 112 rejections for now pending claims 1-16, Examiner notes that the rejection is withdrawn.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-16, Examiner notes that the arguments are moot in light of the new grounds for rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Tran can be reached on 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights