Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This office action is in response to an amendment received on 5/26/26 for patent application 19/043,947.
2. Claims 1, 5, 6, 15 are amended.
3. Claims 8-14 are cancelled.
4. Claims 1-7, 15-20 are pending.
RESPONSE TO ARGUMENTS
Applicant argues#1
Under Step 2A, Prong 1, even if certain aspects of merchant risk evaluation could be characterized at a high level as relating to commercial activity, the amended claims as a whole are directed to a specific machine-learning model- serving architecture and control workflow, not to a fundamental economic practice or a mental process. The claimed operations require event-driven API communication, model-registry selection, deployment of an MLT microservice module, coordination of separately deployed machine-learning models, calibration and aggregation of model outputs, and transaction control through a frontend payment processing application. These operations cannot reasonably be performed as a human mental process, nor do they merely recite a result without the specific computing arrangement for producing and applying that result.
Examiner Response
Examiner respectfully disagrees. The claims are reciting the identified abstract idea, see the section 101 rejection. Also see the Response to Applicant argues#2 below.
The rejection is maintained.
Applicant argues#2
Under Step 2A, Prong 2, the amended claims integrate any alleged abstract idea into a practical application. The specification explains that the system uses a dynamic risk assessment tool to continuously evaluate a merchant's risk profile throughout the merchant lifecycle, with significant merchant actions such as refunds, new URLs, payouts, and chargebacks triggering recalculation of the MLT score. See, e.g., paragraphs 16-18 and 22. The specification further describes the predicate module as dynamically selecting appropriate models based on the merchant profile and checkpoint, and describes the MLT framework as chaining together outputs from required models SO that different models can use outputs of each other. See paragraphs 24 and 30. The MLT microservice module includes specific components for calibration, aggregation, reporting, business-rule override, and database writing, as described in paragraphs 33-38. Thus, the claims do not merely apply a business rule using a generic computer; they recite a particular model-serving pipeline that improves computerized merchant-risk processing by selecting, deploying, coordinating, calibrating, aggregating, and applying multiple machine-learning model outputs in an event-driven payment-processing environment.
Examiner Response
Examiner respectfully disagrees.
The spec paras that application refers to, along with additional spec paras are reproduced below:
[0006] In some embodiments, the event comprises a chargeback event and/or
a refund event. In some embodiments, the method may further comprise receiving,
from a payment application executed by the frontend server and at the score
service application, a transaction request comprising the merchant and the
transaction. In some embodiments, the method may further comprise calibrating,
by a calibrator model, the raw score from each of the onboarding risk score
machine learning model and the payment behavior score machine learning model, based on the model and the merchant segment. In some embodiments, the method may further comprise aggregating, by an aggregator model, the calibrated scores using weighted average for each model, the weighted average depending on the event and the merchant segment. In some embodiments, the method may further comprise writing, by a database writing module, the final score and an index identifier to a database for training of the machine learning model after an update to the database for the index identifier is received.
[0016] A Merchant Lifetime Trust Score (MLT) may be generated by the one or more ML models by a dynamic risk assessment tool that continuously evaluates a merchant's risk profile throughout their lifecycle. The merchant's risk profile may comprise a measurement or scaled factor of a number of attributes including one or more of controller risk, age, location, industry, entity risk, and existence, funding, and/or history of demand deposit account ("DDA"). For example, a higher or lower measurement or scaled factor may indicate a more or less trustworthy risk attribute. Controller risk may include a historical risk associated with financial transactions executed by the merchant where less verified financial transactions may indicate higher risk and more verified financial transactions may indicate lower risk. Age may include an age of a merchant's account with the financial institution where less age may mean a higher risk. Location may include a city, state, country associated with a higher risk or a lower risk. Industry may include an industry associated with a higher or lower risk score. Entity risk may include a purchaser's risk based on a purchaser's identity, payment method (e.g., credit card, third-party payment processing), and/or time of day.
[0017] Each significant action a merchant takes-such as issuing a refund, adding a new URL, or processing a payout-may trigger a recalculation of their
score, ensuring that the most current and relevant data is reflected in their risk evaluation. The MLT score may benefit from a positive history, gradually improving as the merchant maintains a stable and trustworthy record. However, major negative events, like chargebacks, may result in a decrease in the score, signaling heightened risk.
[0018] The MLT score serves as a valuable resource for fraud detection within payment systems, providing a robust mechanism for identifying and mitigating potential threats. Application deployment teams can leverage the MLT score to assess the risk of merchants within a particular segment before launching a product. Similarly, lending teams can utilize the score to evaluate the risk across their merchant portfolios.
[0022] In some embodiments, score service application 104 may act as a checkpoint and/or include a system checkpoint (e.g., for onboarding, pre-capture, capture). The system checkpoint may include an application programming interface ("API") request (e.g., call) model serving layer 106 to compute a MLT score. The system checkpoint may ensure risk assessment at decision points (e.g., onboarding, payout, refund, entity update). Model serving layer 106 may respond to an API call with a MLT score. The system checkpoint may be a periodic daily checkpoint or an event-driven checkpoint (e.g., merchant onboarding to payment product, merchant onboarding to terminal payment processing, a pay-out event, a refund event, a chargeback event, an update of an attribute of a merchant). The chargeback event may be a reversal of funds to a payment account after a customer dispute.
[0024] In some embodiments, predicate module 108 may be a software module executed by one or more processors of a computer or a server of a network, for example, a computer or a server as part of model serving layer 106. Predicate module 108 may be configured to dynamically select appropriate models based on a merchant's profile and a checkpoint, thus ensuring relevant models are triggered. The checkpoint may be a system associated with an event such as onboarding, payout, a refund, a chargeback, or an update to a merchant's details.
[0030] MLT framework 118 may be a software module configured to chain together outputs from the required models, facilitating complex model interactions for comprehensive risk assessment. MLT framework 118 may be a model serving layer that is a microservice. The microservice may deploy ML models to produce model scores and make them available for decision making. This layer allows different models to use outputs of each other. Thus, MLT framework 118 may deploy a model, MLT microservice module 120, that uses outputs of the underlying models which are deployed separately.
[0031] The deployed ML models may be classification ML models that
predict whether JPMC deactivates a merchant due to its undesirable activity. Such activity may include fraud, bankruptcy or losses of a financial institution for any other reason (e.g., labor, funds). Different underlying models may assess different risks including merchant fraud, payer fraud, and credit risk. Each of the deployed ML models may take a set of variables or features as an input and produce a model score as an output. In other words, a model is a function which assesses the risk of a merchant based on its features. The model score lies between 0 and 1 and may be
loosely interpreted as the probability that merchant is risky. The objective of a
classification model is to predict a binary target variable. Therefore, the closer the
model score is to 1, the higher risk a merchant poses.
[0033] In some embodiments, MLT microservice module 120 may comprise one or more software modules including a score calibrator 122, a score aggregator 124, a report generator 126, a business rule overrider 128, and a database writer 130. MLT microservice module 120 may calibrate, aggregate, and/or override scores to redefine them into a final MLT score as will be discussed further herein.
[0034] Score calibrator 122 may be a software module configured to map the raw model outputs (which always range between 0-1) to a final MLT score range of 0-1000. One or more calibration functions of score calibrator 122 may include applying pre-defined calibration functions that are specific to each model. These calibration functions ensure that the final MLT score is meaningful across different contexts. One or more calibration functions of score calibrator 122 may include normalization or standardization of model outputs to account for different scales and distributions of risk scores across models. Score calibrator 122 may implement and execute a calibration step for each underlying ML model to ensure that its model scores can be interpreted as probabilities and then calibration maps these probabilities to 0-1000 scores. Calibration may be model-specific instead of segment specific. Segment-specific patterns may be accounted for by building separate models for merchant segments which exhibit different fraud patterns.
[0035] Score aggregator 124 may be a software module that generate aggregate scores from multiple underlying machine learning (ML) models. Aggregation functions of score aggregator 124 may include weighted averages, depending on the checkpoint (e.g., onboarding, pre-capture, payout) or merchant age, and the specific merchant segment or as otherwise discussed herein. Aggregation functions of score aggregator 124 may include dynamically adjusting one or more weights of individual model scores based on relevance and performance. For example, a large merchant might have a final MLT score computed by combining outputs from a credit-based model and a payer-fraud model, with each model's contribution weighted according to its predictive power and relevance to that merchant's profile. A feedback loop may be implemented to determine a predictive power score and/or a relevance score after each iteration.
[0036] Report generator 126 may be a software module configured to create one or more reports detailing a MLT score calculation process. The one or more reports may include a breakdown of the score, showing a contribution from each underlying model and the effect of a business rule applied. Report generator 126 may generate sub-scores for different risk categories (e.g., credit risk, fraud risk) are generated, providing stakeholders with a deeper understanding of the merchant's risk profile. It may include fine-grained information such as contribution of individual attributes to MLT score. This will allow different stakeholders to understand ML scores depending on their level of technical sophistication as well as level of abstraction required. Report generator 126 may be generated in one or more of a human-readable format or a machine-readable format.
[0037] Business rule overrider 128 may be a software module configured to apply business rules to override or adjust one or more ML-generated scores. One or more rules may include "when a merchant does not conduct a transaction for time period, the MLT score should be reduced," where reduction indicates a transaction should be blocked, not approved, or placed on hold.
[0038] Database writer 130 may be a software module configured to store MLT scores and/or associated metadata efficiently. Database writer 130 may write to a high-performance, distributed database designed for quick retrieval of historical data. Database writer 130 may employ an indexing strategy to optimize the retrieval of scores based on different criteria, such as merchant ID, timestamp, or checkpoint. Database writer 130 may manage and/or implement data retention policies. Database writer 130 may implement rules (e.g., to open more areas for storage or eliminate older files) to maintain performance (e.g., download/upload speed) over time. Database writer 130 may write to data lake/feature store 132.
[0041] Step 220 may include determining one or more calibration models of
a bottom layer and merchant features. The merchant features may be based on the merchant conducting the transaction. The determining of the one or more
calibration models may include determining a merchant segment of the merchant
and determining calibration models associated with the merchant segment. The ML model may be calibrated for the merchant segment by being trained on appropriate merchant profiles of the merchant segment. Each ML model may be generated specifically on one or more merchant segments. Calibration may be a step in making model scores easier to interpret as probabilities and then mapping them to 0-1000 scale. In other words, calibration may be model-specific rather than segment-specific.
Applicant is pointed to MPEP section:
2106.05(a) Improvements to the Functioning of a Computer or To Any Other Technology or Technical Field
During examination, the examiner should analyze the "improvements" consideration by evaluating the specification and the claims to ensure that a technical explanation of the asserted improvement is present in the specification, and that the claim reflects the asserted improvement. Generally, examiners are not expected to make a qualitative judgement on the merits of the asserted improvement.
It can be seen from the instant specification that there is no technical explanation of the asserted improvement (merchant risk processing), see page 2 of arguments, and reflected in the claims. The additional elements( microservice module comprising a score calibrator and score aggregator, calibrating by a calibrator model the raw score, aggregating by a aggregator model the calibrated scores), are recited at a high level of generality and are being used in their ordinary capacity and are being used as a tool for implementing the steps of the identified abstract idea, see MPEP 2106.05(f),
Therefore, there are no additional elements in the claims that are indicative of integration into a practical application.
The rejection is maintained.
Applicant argues#3
The amended claims also recite a concrete technical use of the final score. The score service application uses the final MLT score in communication with a payment processing application to control a transaction, including by approval, hold, block, or request for additional information. This is consistent with the specification's disclosure that the score service application may determine whether to approve, block, hold, or require further verification for a transaction based on the MLT score, and that the final MLT score may be returned to the score service application and converted into a transaction-level decision. See paragraphs 40 and 48. The claimed arrangement therefore imposes meaningful limits on the use of the alleged concept and applies the generated score in a specific payment-processing control workflow.
Examiner Response
Examiner respectfully disagrees.
The last limitation in claim 1 (controlling a transaction score based on the final score of the merchant, wherein controlling comprises an approval decision, a hold decision, a block decision or a request for more information related to the transaction) is part of the identified abstract idea.
Examiner reproduces para 40,48 below:
[0040] Step 210 may include receiving, from a score service application executed by one or more processors and by a backend server, a request for a MLT score for a merchant. The request may be a transmitted message packet in response to an event or recurring time (e.g., daily). The request may be an application programming interface ("API") call. The request may be generated based on an attempt by a merchant to conduct a transaction. The score service application may determine whether to approve, block, hold, or require further verification for, the transaction based on the MLT score. The transaction may be a pay-out, a pay-in, a request for credit, a credit approval for a pending transaction, or an onboarding of the merchant to allow the merchant to make transactions on a payment application connected to the score service application.
[0048] Step 250 may include generating a final MLT score. The final MLT score may be returned to the score service application. The score service application may convert the final MLT score into a transaction-level decision including an approval decision, a hold decision, a block decision, and/or a request for more information related to a transaction. Additionally, the MLT score may be used for merchant account-level decisions such as setting minimum reserve requirements, setting amount limits on pay-in and pay-out transactions, enabling or restricting merchant payment processing capabilities (such as being able to use terminal for card-present transactions). The score service application may determine the decision based on a context for the MLT request received from a payment transaction application (e.g., a transaction comprising an onboarding request may require a lower MLT score than a transaction comprising a pay-out request and/or a credit request).
The additional element, (score service application is executed by a processor and server) is being used as a tool to implement the steps of the identified abstract idea (whether to approve, block or hold the transaction).
The rejection is maintained.
Applicant argues#4
Under Step 2B, the amended claims recite significantly more than any alleged abstract idea. The ordered combination includes an event-triggered API request, predicate-based dynamic model selection, framework deployment of an MLT microservice module, coordination of separately deployed underlying machine-learning models, merchant-segment-based calibration, weighted aggregation dependent on event and merchant segment, business-rule-based final score generation, and transaction control through a payment processing application. The Office Action itself acknowledges that the prior art of record does not anticipate or render obvious the claimed subject matter as a whole, particularly the framework module deploying a microservice module coordinating machine- learning models, determining calibration models matching a merchant segment using onboarding and payment behavior score machine-learning models, generating a final score based on a business rule, and controlling a transaction based on that final score. These claim elements, individually and as an ordered combination, are not merely generic computer implementation of a commercial interaction.
Accordingly, when the amended claims are considered as a whole under the Alice/Mayo framework, they are directed to a specific computer-implemented merchant-risk scoring and transaction-control architecture that integrates any alleged abstract idea into a practical application and recites significantly more than generic computer implementation.
Examiner Response
Examiner respectfully disagrees.
The additional element of the API and the deployment of a number of models is recited at a high level of generalty and is being used as a tool to implement the steps of the identified abstract idea.
It is a commonly understood machine learning strategy to deploy machine learning models based on what data is received for making a prediction.
Applicant’s claims do not improve technology; the underlying technology remains unaffected by the claims. Applicant is addressing a business problem (determining a merchant trust score) with a business solution. Applicant is merely using existing technology (for its intended purpose) to implement the business solution. Any improvements lie in the abstract idea itself, not in underlying technology
Therefore there are no additional elements that amount to significantly more than the identified abstract idea.
As far as novelty is concerned, applicant is pointed to MPEP 2106.05:
Although the courts often evaluate considerations such as the conventionality of an additional element in the eligibility analysis, the search for an inventive concept should not be confused with a novelty or non-obviousness determination.
See Mayo, 566 U.S. at 91, 101 USPQ2d at 1973 (rejecting "the Government's
invitation to substitute §§ 102, 103, and 112 inquiries for the better established
inquiry under § 101 "). As made clear by the courts, the "'novelty' of any element
or steps in a process, or even of the process itself, is of no relevance in
determining whether the subject matter of a claim falls within
the § 101 categories of possibly patentable subject matter." Intellectual Ventures I
V. Symantec Corp., 838 F.3d 1307, 1315, 120 USPQ2d 1353, 1358 (Fed. Cir. 2016)
(quoting Diamond V. Diehr, 450 U.S. at 188-89, 209 USPQ at 9). See also Synopsys, Inc. V. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a claim for a new abstract idea is still an abstract idea. The search for a § 101 inventive concept is thus distinct from demonstrating § 102 novelty."). In addition, the search for an inventive concept is different from an obviousness analysis under 35 U.S.C. 103. See, e.g., BASCOM Global Internet V. AT&T Mobility LLC, 827 F.3d 1341, 1350, 119 USPQ2d 1236, 1242 (Fed. Cir. 2016) ("The inventive
concept inquiry requires more than recognizing that each claim element, by itself, was known [A]n inventive concept can be found in the non-conventional and
in the art. non-generic arrangement of known, conventional pieces."). Specifically, lack of novelty under 35 U.S.C. 102 or obviousness under 35 U.S.C. 103 of a claimed invention does not necessarily indicate that additional elements are well- understood, routine, conventional elements. Because they are separate and distinct requirements from eligibility, patentability of the claimed invention under 35 U.S.C. 102 and 103 with respect to the prior art is neither required for, nor a guarantee of, patent eligibility under 35 U.S.C. 101. The distinction between eligibility (under 35 U.S.C. 101) and patentability over the art (under 35 U.S.C. 102 and/or 103 ) is further discussed in MPEP § 2106.05(d). It appears that applicant is conflating novelty (Sections 102/103) with patent eligibility.
The rejection is maintained.
Note: Examiner had in the previous office action objected to claims 16-20. The claim language has not been corrected. The claim objection is repeated below:
Claim Objection
3. Claims 16-20 are objected to for the following:
Claims 16-20 are recited as “The method of claim 15”. However independent claim 15 is a “Non-transitory computer readable storage medium”.
This appears to be a typo.
Examiner suggests rewriting dependent claims 16-20 to recite:
“The non-transitory computer readable storage medium of claim 15.”
Claim Rejections- 35 U.S.C § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
4. Claims 1-7, 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1,15 recite, in the calibrating step: “calibrating, by a calibrator model, the raw score from each of the onboarding risk score machine learning model and the payment behavior score machine learning model, based on the model and the merchant segment”.
It is unclear to Examiner which model is being referred to. Is it the “calibrator model” or is it the “onboarding risk scoring machine model”?
Claims 2-7 & 16-19 are also rejected using the same rationale as they fail to cure the deficiency of their respective independent claims (1&15).
Claim Rejections- 35 U.S.C § 101
5. Claims 1-7, 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1, 15 are directed to a method and a computer readable medium, which are statutory categories of invention. (Step 1: YES).
Representative claim 1 recites:
A method comprising:
receiving, from a score service application executed by one or more processors and by a predicate module of a backend server, a request for a merchant lifetime trust score for a merchant via an application programming interface ("API") call in response to an event;
triggering, by the predicate module, a model of a model registry of the backend server, the model being dynamically selected by the predicate module based on the event and a merchant risk profile of the merchant;
deploying, by a framework module, a Merchant Lifetime Score (“MLT”) microservice module that coordinates a number of machine learning ("ML") models based on the triggered model, the MLT microservice module using outputs of underlying models that are deployed separately;
determining, by the MLT microservice module, one or more calibration models based on one or more merchant features of the merchant risk profile, the one or more calibration models matching a merchant segment of the merchant risk profile, the one or more calibration models being trained on more than one merchant risk profiles including one or more risky merchant risk profiles and one or more non-risky profiles;
generating, by an onboarding risk score machine learning model and a payment behavior score machine learning model, a raw score for the merchant lifetime trust score request;
calibrating, by a calibrator model, the raw score from each of the onboarding risk score machine learning model and the payment behavior score machine learning model, based on the model and the merchant segment;
aggregating, by an aggregator model, the calibrated scores using weighted average for each model, the weighted average depending on the event and the merchant segment to form aggregated scores;
generating, by the score service application, a final score based on a business rule to the aggregated scores; and
controlling, by the score service application in communication with a payment processing application executed by a frontend server, a transaction based on the final score for the merchant, wherein controlling comprises an approval decision, a hold decision, a block decision, or a request for more information related to the transaction.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity.
The claim recites elements that are in bold above, which covers performance of the limitation as a commercial interaction, steps for generating a merchant trust score and comparing it to a final score to determine whether to block a transaction (e.g., receiving, a request for a merchant lifetime trust score for a merchant; determining, one or more calibration models based on one or more merchant features of the merchant risk profile, the one or more calibration models matching a merchant segment of the merchant risk profile; generating, a raw score for the merchant lifetime trust score request; calibrating the raw score; aggregating the calibrated scores; generating, a final score based on a business rule to the aggregated scores; and controlling a transaction based on the final score for the merchant, wherein controlling comprises an approval decision, a hold decision, a block decision, or a request for more information related to the transaction)
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a Commercial Interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Claim 15 is abstract for similar reasons.
(Step 2A-Prong 1: YES. The claims are abstract).
This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05.f), (2) Adding insignificant extra solution activity to the judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05.h).
Claims 1, 15 includes the following additional elements:
-A score service application
-One or more processor
-A backend server
-A predicate module
-A microservice module using outputs of underlying models that are deployed separately
-A model of a model registry
-A framework module
-A number of machine learning models
-Training of the one or more calibration models
-An onboarding risk score machine learning model
-Calibrating by a calibrator model the raw score
-Aggregating by a aggregator model the calibrated scores using weighted average for each model.
-A frontend server
-An application programming interface (API) call
-A payment processing application
- A non-transitory computer readable medium
The score service application, one or more processors, backend server, a predicate module, a microservice model, a model of a model registry, a framework module, a number of machine learning models, training of the one or more calibration models, an onboarding risk score machine learning model, calibrating by a calibrator model the raw score, aggregating by a aggregator model the calibrated scores, a frontend server, an application programming interface (API) call, payment processing application and a non-transitory computer readable medium are recited at a high level of generality and are being used in their ordinary capacity and are being used as a tool for implementing the steps of the identified abstract idea, see MPEP 2106.05(f), where applying a computer or using a computer as a tool to perform the abstract idea is not indicative of a practical application.
The multiple models (calibration model, number of machine learning models, risk score machine learning model, payment behavior score machine learning model, calibration model, aggregator model) are operating in their ordinary capacity (to determine patterns in the merchant data to make predictions as to merchant’s risk level). Furthermore, the backend server and the frontend server are using an API (an application programming interface) to communicate with the various applications (the score service application and the payment processing application are being used as a tool to implement the steps of the identified abstract idea see spec paras 6,22, 31.
Additionally, the processor, server, and non-transitory computer readable medium disclosed in spec paras 7, 51, 54 are recited at a high level of generality, operating in their ordinary capacity, and are being used as a tool to implement the steps of the identified abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea
Therefore claims 1, 15 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, there are no additional elements recited in the claim beyond the judicial exception.
Mere instructions to implement an abstract idea, on or with the use of generic computer components, or even without any computer components, cannot provide an inventive concept - rendering the claim patent ineligible. Thus claims 1,15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Claims 5, 12 further defines the identified abstract idea recited in claims 1,8. The additional element (calibrating comprising mapping raw model outputs) is recited at a high level of generality, operating in their ordinary capacity and are being used as a tool to implement the steps of the identified abstract idea.
Claims 7, 14 further defines the identified abstract idea recited in claims 1,8.
The additional element (database writing module & database) are recited at a high level of generality, operating in their ordinary capacity and are being used as a tool to implement the steps of the identified abstract idea.
Therefore, the dependent claims do not include any 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. Therefore, the dependent claims (2-7, 16-20) are directed to an abstract idea. Thus, the claims 1-7, 15-20 are not patent-eligible.
CONCLUSION
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD Z SHAIKH whose telephone number is (571)270-3444. The examiner can normally be reached M-T, 9-600; Fri, 8-11, 3-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, BENNETT SIGMOND can be reached at 303-297-4411. 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.
/MOHAMMAD Z SHAIKH/Primary Examiner, Art Unit 3694 7/17/2026
Prosecution Insights