DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/20/2026 has been entered.
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 .
Status of Claims
Claims X are canceled.
Claims X are new.
Claims 1-20 are pending and have been examined.
This action is in reply to the papers filed on 07/20/2026 (effective filing date 04/21/2023).
Information Disclosure Statement
No Information Disclosure Statement has been filed.
The information disclosure statement(s) submitted: xxxxxxxx, has/have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on 04/21/2023 as modified by the amendments filed on 03/11/2026 and 07/20/2026.
Reasons For Allowance
Prior-Art Rejection withdrawn
Claims 1-20 are allowable over the prior-art, however, these claims remain rejected under 35 USC §101 subject matter eligibility. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed: 1. (Currently amended) A method of managing artificial intelligence (Al) model rollouts, comprising: training, by a cloud environment, a second Al model, wherein the second Al model outputs a same Al feature as a first Al model in the cloud environment; specifying, by a model registry service in the cloud environment, a window of time in which the second Al model is to be rolled out to a plurality of tenant applications; concurrently generating, by a prediction service in the cloud environment during the window of time, a first model value for the Al feature with the first Al model in the cloud environment and a second model value for the Al feature with the second Al model in the cloud environment; transforming, by an Al feature combiner of the prediction service in the cloud environment, the first model value and the second model value into an output value for the Al feature for each of the plurality of tenant applications based on a timestamp associated with each of the plurality of tenant applications, wherein transformation of the first model value and the second model value into the output value for the Al feature for a respective tenant application of the plurality of tenant applications includes determining a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp associated with the respective tenant application to the window of time in which the second Al model is to be rolled out to the plurality of tenant applications; and displaying, by the cloud environment, the output value for the Al feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output of the first Al model, an output value of the second Al model, or a combined output value of the first Al model and the second Al model.
The closest prior-art (Odibat et al. 2024/0273396, Miller et al. 2023/0037733, Andersh et al. 2003/0100972, Zhang et al. 2019/0243753, Ma et al. 2015/0120244, Ruiz et al. 2024/0047052, XU et al. 2021/0201128, Narita 2022/0215297, NarasimhaMurthy et al. 2024/0371141, Woodford et al. 2019/0260794, Sawaf et al. 2022/0318887, Ma et al. 2019/0347113, Chen et al. 2019/0370603, Latapie et al. 2020/0364466, Alon et al. 2022/0156524) teach the features as disclosed in Non-final Rejection (12/11/2025), however, these cited references do not teach and the prior-art does not teach at least the following combination of features and/or elements:
training, by a cloud environment, a second Al model, wherein the second Al model outputs a same Al feature as a first Al model in the cloud environment; specifying, by a model registry service in the cloud environment, a window of time in which the second Al model is to be rolled out to a plurality of tenant applications; concurrently generating, by a prediction service in the cloud environment during the window of time, a first model value for the Al feature with the first Al model in the cloud environment and a second model value for the Al feature with the second Al model in the cloud environment; transforming, by an Al feature combiner of the prediction service in the cloud environment, the first model value and the second model value into an output value for the Al feature for each of the plurality of tenant applications based on a timestamp associated with each of the plurality of tenant applications, wherein transformation of the first model value and the second model value into the output value for the Al feature for a respective tenant application of the plurality of tenant applications includes determining a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp associated with the respective tenant application to the window of time in which the second Al model is to be rolled out to the plurality of tenant applications; and displaying, by the cloud environment, the output value for the Al feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output of the first Al model, an output value of the second Al model, or a combined output value of the first Al model and the second Al model.
Claim Rejections - 35 USC §101 - Withdrawn
Per Applicant’s amendments and arguments and considering new guidance in the MPEP, the rejections are withdrawn. Specifically, in Applicant’s Remarks (dated 03/14/2017, pgs. 8-11), Applicant traverses the 35 USC §101 rejections arguing that the amended claims recite new limitations that are not abstract, amount to significantly more, are directed to a practical application, etc… For example, Applicant argues….
In support of their arguments, Applicant cites to the following recent Fed. Cir. court cases (i.e., Alice Corp. v. CLS Bank Int’l, SRI Int’l, Inc. v. Cisco Systems, Inc., Ultramercial, Inc. v. Hulu, LLC, Berkheimer, Core Wireless, McRO, Enfish, Bascom, DDR, etc…).
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more and therefore is not eligible for patent protection.
A. Legal Standard
Under the Supreme Court's decisions in Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014), and Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66 (2012), a patent claim is not eligible if (1) it is aimed at an abstract idea — such as a mathematical calculation, a task a person could do mentally, or a well-known way of doing business — and (2) the rest of the claim does not add anything beyond ordinary, generic computer technology. The Patent Office (MPEP § 2106) applies this test by asking: is the claim a process, machine, or manufacture at all (Step 1)? Is the claim actually aimed at an abstract idea (Step 2A)? And if so, does the claim add something beyond that idea amounting to a real, specific technical improvement (the rest of Step 2A, and Step 2B)?
An invention is patent-eligible under 35 U.S.C. § 101 if it is a new and useful process, machine, manufacture, or composition of matter (or a new and useful improvement thereof) and is not directed to a judicial exception — a law of nature, a natural phenomenon, or an abstract idea — unless the claim as a whole includes additional elements amounting to significantly more than the exception. Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 216-18 (2014); Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66, 77-80 (2012). The Office applies the analysis set out in MPEP § 2106 (9th ed., Rev. 01.2024) — the "Alice/Mayo" or two-step framework — comprising: Step 1 (is the claim to a process, machine, manufacture, or composition of matter, MPEP § 2106(I)?); Step 2A, Prong One (does the claim recite a judicial exception — an abstract idea enumerated in MPEP § 2106.04(a)(2) as a mathematical concept, a mental process, or a certain method of organizing human activity, a law of nature, or a natural phenomenon?); Step 2A, Prong Two (if so, do the additional elements integrate the exception into a practical application, MPEP § 2106.04(d)?); and, if not, Step 2B (do the additional elements, considered individually and as an ordered combination, amount to significantly more than the judicial exception, MPEP § 2106.05?).
See also USPTO, 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50 (Jan. 7, 2019); USPTO, October 2019 Update; USPTO, 2024 Guidance Update on Patent Subject Matter Eligibility, Including on Artificial Intelligence, 89 Fed. Reg. 58128 (July 17, 2024) ("2024 AI SME Update"), and its accompanying Subject Matter Eligibility Examples 47-49; and USPTO Memorandum, Guidance on Use of Judicial Exception Groupings and Recent Subject Matter Eligibility Decisions (Aug. 4, 2025). The 2024 AI SME Update confirms that claims reciting the training, updating, or application of a machine-learning or artificial-intelligence model are analyzed under this same framework, and that generic, result-oriented recitation of AI/ML model training or application — without a specific, disclosed technical improvement — remains within the mathematical-concept and/or mental-process groupings of abstract ideas. See also Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205 (Fed. Cir. 2025) (machine-learning training and model-based prediction claims held ineligible where the claims did no more than apply "generic machine learning to new data environments, without disclosing improvements to the [machine learning] models" themselves).
B. Step 1 — Statutory Category (Claims 1-20)
Step 1: Claims 1-10 are a "method," claims 11-19 are a "system," and claim 20 is a "non-transitory computer-readable medium." Each is an allowed category of invention, so Step 1 is satisfied for all claims.
Claims 1-10 are directed to a "method," claims 11-19 are directed to a "data processing system" comprising "a processor; and a memory coupled to the processor," and claim 20 is directed to "a non-transitory computer-readable medium." Each of claims 1-20 therefore falls within one of the four statutory categories of invention (process, machine, or manufacture) under 35 U.S.C. § 101, and Step 1 is satisfied for all claims. MPEP § 2106(I). The claims must nonetheless be further analyzed under Step 2A and Step 2B, below.
C. Step 2A, Prong One — Independent Claim 1 Recites an Abstract Idea
Claim 1 recites, in relevant part:
"training, by a cloud environment, a second AI model, wherein the second AI model outputs a same AI feature as a first AI model in the cloud environment; specifying, by a model registry service in the cloud environment, a window of time in which the second AI model is to be rolled out to a plurality of tenant applications; concurrently generating, by a prediction service in the cloud environment during the window of time, a first model value for the AI feature with the first AI model in the cloud environment and a second model value for the AI feature with the second AI model in the cloud environment; transforming, by an AI feature combiner of the prediction service in the cloud environment, the first model value and the second model value into an output value for the AI feature for each of the plurality of tenant applications based on a timestamp associated with each of the plurality of tenant applications, wherein transformation of the first model value and the second model value into the output value for the AI feature for a respective tenant application of the plurality of tenant applications includes determining a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp associated with the respective tenant application to the window of time in which the second AI model is to be rolled out to the plurality of tenant applications; and displaying, by the cloud environment, the output value for the AI feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model."
Considered as a whole, claim 1 recites a scheme for phasing in a new predictive value (from a "second AI model") in place of an old predictive value (from a "first AI model") over a defined transition period, by mathematically blending the two values in proportion to how far a given point in time has progressed through that period, and then outputting the blended value. This scheme falls within at least two of the abstract-idea groupings identified in MPEP § 2106.04(a)(2):
1. Mathematical Concepts
The claimed step of "determining a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp ... to the window of time" recites a mathematical calculation or relationship — deriving numeric weighting factors as a function of where a timestamp falls within a time interval — and "transforming ... the first model value and the second model value into an output value" by application of those weights recites a mathematical formula for combining two numeric inputs into a single numeric output (confirmed further by dependent claims 3-4, which recite that this transformation is "a smoothing algorithm" that "takes a weighted average"). Mathematical relationships, formulas, and calculations — including weighted averaging and time-based interpolation of values — fall within the "Mathematical Concepts" grouping. MPEP § 2106.04(a)(2)(I). See Parker v. Flook, 437 U.S. 584, 594-95 (1978) (updating an alarm-limit value using a mathematical formula is not patent-eligible merely because tied to a particular application); SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163, 1167-68 (Fed. Cir. 2018) (claims to selecting information, analyzing it with mathematical/statistical techniques, and reporting the results are directed to an abstract idea, even where the statistical method is allegedly novel); Digitech Image Techs., LLC v. Elecs. for Imaging, Inc., 758 F.3d 1344, 1350-51 (Fed. Cir. 2014) (claims to organizing information through mathematical correlations are directed to an abstract idea).
2. Mental Processes and Certain Methods of Organizing Human Activity
Determining how much weight to give an old value versus a new value based on where the current time falls within a transition window, and blending the two accordingly, is also a form of evaluation and judgment that — apart from the generic "cloud," "model," and "AI" labels — could be performed mentally or with pen and paper by a human analyst who is told a rollout window and observes today's date. MPEP § 2106.04(a)(2)(III); CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372-73 (Fed. Cir. 2011). Independently, staging or "rolling out" a replacement version of a data-generating tool to a customer base over a defined transition window, during which reliance progressively shifts from the old tool to the new one, is a longstanding organizational/commercial practice (a phased rollout or transition plan) and is thus a certain method of organizing human activity. MPEP § 2106.04(a)(2)(II). See Recentive, 134 F.4th at 1215-19 (introducing machine learning to a new field does not render an otherwise-abstract concept non-abstract; the sequence of training a model and generating outputs from it, without more, remains abstract); Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353-54 (Fed. Cir. 2016) ("[C]ollecting information, analyzing it, and displaying certain results of the collection and analysis" are "a familiar class of claims 'directed to' a patent-ineligible concept.").
Because claim 1 recites limitations falling within the mathematical-concept and mental-process/certain-method-of-organizing-human-activity groupings, claim 1 recites an abstract idea, and the analysis proceeds to Step 2A, Prong Two.
D. Step 2A, Prong Two — The Additional Elements of Claim 1 Do Not Integrate the Judicial Exception Into a Practical Application
Claim 1's additional elements — beyond the abstract idea itself — are: a "cloud environment"; a "model registry service"; a "prediction service"; an "AI feature combiner"; "tenant applications"; the "first AI model" and "second AI model" as data sources; and the acts of "training" a model and "displaying" an output value. None of these, alone or in combination, integrates the judicial exception into a practical application. MPEP § 2106.04(d).
The Specification confirms that the problem addressed is a business/customer-experience problem, not a technical one. The published Specification (US 2024/0354600 A1) explains, in the Background, that "[t]he release of the updated AI model may often result in undesirable user experience due to a sudden gap in the values of the AI feature," such that "tenants ... often may require explanations for the disruptions from service providers, which is time-consuming[; t]herefore, there is a need to smooth the disruptive user experiences caused by AI model rollouts." (Specification, Background) [0002]. The Specification further defines "tenants" as "also referred to as users or customers or organization in this disclosure" (Specification, Background) [0002], confirming that the claimed "plurality of tenant applications" represents a business's customers. The problem identified and purportedly solved — avoiding the need to give customers a time-consuming explanation when a service's output value changes abruptly upon a version update — is a business/customer-relations problem, not a technical problem of computer or network functionality, and reinforces that claim 1 is directed to a certain method of organizing human activity (managing customer experience/relations during a product transition) rather than to any technological improvement. See MPEP § 2106.04(a)(2)(II); Alice, 573 U.S. at 225 (an abstract idea does not become patent-eligible merely by "limiting the use of [the idea] to a particular technological environment").
No improvement to a computer or other technology is recited. Claim 1 does not specify how the "second AI model" is trained, what architecture either model uses, or how the "AI feature combiner" technically performs the transformation beyond the mathematical weighting scheme itself; it recites only the result to be achieved ("outputs a same AI feature," "transforming ... into an output value"). Indeed, the Specification confirms that the specific model architecture and training technique are interchangeable and unclaimed: it states that "[e]ach of the first AI model and the second AI model can be a neural network model," and that the second AI model may be a "major version" implementing "a different algorithm" or a "minor version" that is merely "retrained on a new segment of data." (Specification, description of Fig. 5) [0078]. As in Recentive, where the claims recited "training a machine learning model" and "dynamically generat[ing]" outputs without disclosing any improvement to how the models themselves work, claim 1's recitation of "training ... a second AI model" and blending its output with that of a "first AI model" does no more than claim the application of generic machine learning to a new data environment, without disclosing improvements to the machine-learning models themselves. Recentive, 134 F.4th at 1218-19; MPEP § 2106.05(a). No improvement to cloud computing, network transmission, or data storage is recited either; "cloud environment," "model registry service," and "prediction service" are used at a high level of generality as generic labels for where conventional computing operations occur, consistent with the Specification's own generic description of the model registry service as a set of APIs used to "read AI model related data from and write AI model related [data] to the model registry store" (Specification, description of Fig. 1) [0031-0038] MPEP § 2106.05(f); In re TLI Commc'ns LLC Patent Litig., 823 F.3d 607, 611, 615 (Fed. Cir. 2016) (generic recitation of a "server" and "telephone unit" performing basic functions does not integrate an abstract idea into a practical application).
No particular machine, and no particular transformation. The "cloud environment," "model registry service," "prediction service," and "AI feature combiner" are not tied to any specific hardware and do not amount to a "particular machine." MPEP § 2106.05(b); Bilski v. Kappos, 561 U.S. 593, 606 (2010); Alice, 573 U.S. at 226 (use of a computer to obtain, adjust, and reconcile data does not, without more, transform an abstract idea into a patentable invention). Nor does the claim effect a "particular transformation": it transforms numeric model-output values into another numeric value via a weighting/averaging calculation, which is a transformation of data, not of an article to a different state or thing. MPEP § 2106.05(c); Digitech, 758 F.3d at 1350-51 (combining two data sets to generate a third data set does not amount to a particular transformation).
The remaining additional elements are, at most, insignificant extra-solution activity. "Displaying ... the output value ... to each of the plurality of tenant applications" merely outputs/reports the result of the abstract calculation. MPEP § 2106.05(g); Elec. Power Grp., 830 F.3d at 1354 ("[M]erely presenting the results of abstract processes of collecting and analyzing information ... is abstract as an ancillary part of such collection and analysis."). "Concurrently generating ... a first model value ... and a second model value" is, at best, necessary data-gathering feeding the abstract weighting calculation, and is likewise insignificant extra-solution activity. MPEP § 2106.05(g); In re Bilski, 545 F.3d 943, 963 (Fed. Cir. 2008) (en banc). The recitation of "a plurality of tenant applications" reflects only the technological field of use — a multi-tenant cloud/SaaS architecture — in which the abstract idea is applied. MPEP § 2106.05(h); Affinity Labs of Tex., LLC v. DIRECTV, LLC, 838 F.3d 1253, 1259 (Fed. Cir. 2016).
Because no additional element, viewed individually or in combination, integrates the recited abstract idea into a practical application, claim 1 is directed to the abstract idea, and the analysis proceeds to Step 2B.
E. Step 2B — Claim 1 Does Not Recite Significantly More Than the Abstract Idea
Considered individually, the additional elements identified above — a generic "cloud environment," a "model registry service," a "prediction service," an "AI feature combiner," and generic AI "models" communicating with "tenant applications" over a network and "displaying" a result — are well-understood, routine, and conventional computer functions as of the effective filing date. Alice, 573 U.S. at 225-26 (using a computer to perform generic functions such as obtaining, storing/retrieving, and adjusting/reconciling data is well-understood, routine, and conventional); MPEP § 2106.05(d)(II) (citing, e.g., buySAFE, Inc. v. Google, Inc., 765 F.3d 1350 (Fed. Cir. 2014) (receiving and sending information over a network); Versata Dev. Grp., Inc. v. SAP Am., Inc., 793 F.3d 1306 (Fed. Cir. 2015) (storing and retrieving information in memory); In re TLI Commc'ns, 823 F.3d 607 (generic recitation of a server performing generic computer functions)). Training a machine-learning model on a cloud platform, generating an inference/prediction with a model, and delivering that prediction to client (tenant) applications over a network are themselves well-understood, routine, and conventional cloud-computing and machine-learning operations; indeed, the Federal Circuit in Recentive held that the use of machine learning to optimize a task, without a claimed improvement to how the machine learning is implemented, does not supply the inventive concept necessary at step two. Recentive, 134 F.4th at 1220-21.
[ If the Specification (e.g., at ¶ ___) describes the "cloud environment," "model registry service," "prediction service," or "AI feature combiner" generically, or states that they may be implemented using any commercially available/general-purpose cloud infrastructure, cite that passage as an admission under MPEP § 2106.05(d) and Berkheimer v. HP Inc., 881 F.3d 1360, 1369 (Fed. Cir. 2018) (whether an additional element is well-understood, routine, and conventional is a question of fact that must be supported by evidence, which may include an applicant's own specification).]
Considered as an ordered combination, the additional elements add nothing beyond what they contribute individually: they simply automate, on a generic multi-tenant cloud platform, the abstract mental/mathematical process of phasing a new model's output in for an old model's output over a defined window. Mere automation of a process previously performed (or performable) by a human, using generic computer components performing their basic functions, does not supply an inventive concept. BSG Tech LLC v. Buyseasons, Inc., 899 F.3d 1281, 1290-91 (Fed. Cir. 2018); Bancorp Servs., L.L.C. v. Sun Life Assurance Co. of Can. (U.S.), 687 F.3d 1266, 1278 (Fed. Cir. 2012); Recentive, 134 F.4th at 1220-21 (ordered combination of generic machine-learning training and application steps does not transform an abstract idea into significantly more). Accordingly, claim 1 does not recite significantly more than the identified abstract idea and is not patent-eligible under 35 U.S.C. § 101.
F. Independent Claims 11 and 20 Are Rejected for the Same Reasons as Claim 1
Claim 11 recites, in relevant part:
"a processor; and a memory coupled to the processor to store instructions therein for managing artificial intelligence (AI) model rollouts, wherein the instructions, when executed by the processor, cause the processor to: train a second AI model in a cloud environment, wherein the second AI model outputs a same AI feature as a first AI model in the cloud environment; specify a window of time in which the second AI model is to be rolled out to a plurality of tenant applications; concurrently generate, during the window of time, a first model value for the AI feature with the first AI model in the cloud environment; and a second model value for the AI feature with the second AI model in the cloud environment; transform the first model value and the second model value into an output value for the AI feature for each of the plurality of tenant applications based on a timestamp associated with each of the plurality of tenant applications, wherein transformation of the first model value and the second model value into the output value for the AI feature for a respective tenant application of the plurality of tenant applications includes determination of a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp associated with the respective tenant application to the window of time in which the second AI model is to be rolled out to the plurality of tenant applications; and display the output value for the AI feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output value of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model."
Claim 20 recites, in relevant part:
"instructions for managing artificial intelligence (AI) model rollouts, which instructions, when executed by a data processing system comprising at least one hardware processor, cause the data processing system to: train a second AI model in a cloud environment, wherein the second AI model outputs a same AI feature as a first AI model in the cloud environment; specify a window of time in which a second AI model is to be rolled out to a plurality of tenant applications; concurrently generate, during the window of time, a first model value for the AI feature with the first AI model in the cloud environment; and a second model value for the AI feature with the second AI model in the cloud environment; transform the first model value and the second model value into an output value for the AI feature for each of the plurality of tenant applications based on a timestamp associated with each of the plurality of tenant applications, wherein transformation of the first model value and the second model value into the output value for the AI feature for a respective tenant application of the plurality of tenant applications includes determination of a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp associated with the respective tenant application to the window of time in which the second AI model is to be rolled out to the plurality of tenant applications; and display the output value for the AI feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output value of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model."
Claims 11 and 20 recite substantively the same steps as claim 1 — training a second AI model, specifying a rollout window, concurrently generating first and second model values, transforming those values into an output value based on a first weight and a second weight derived from comparing a timestamp to the window, and displaying/causing display of the resulting output value — merely reciting them as functions performed by "a processor" and "a memory" (claim 11) or by "a data processing system comprising at least one hardware processor" pursuant to instructions stored on a "non-transitory computer-readable medium" (claim 20), rather than as method steps. The generic recitation of "a processor" and "memory" (claim 11) and of a "hardware processor" executing stored instructions (claim 20) reflects the same level of generality condemned in Alice, 573 U.S. at 226, and does not integrate the abstract idea into a practical application, nor add significantly more, for the same reasons discussed above for claim 1. MPEP § 2106.05(a)-(f); Recentive, 134 F.4th at 1218-21. Claims 11 and 20 are therefore rejected under 35 U.S.C. § 101 for the same reasons as claim 1.
G. Dependent Claims 2-10 and 12-19 Do Not Cure the Deficiencies of Their Base Claims
Claims 2-10 depend, directly or indirectly, from claim 1, and claims 12-19 depend, directly or indirectly, from claim 11 in parallel fashion (claim 2 ~ claim 12; claim 3 ~ claim 13; claim 4 ~ claim 14; claim 5 ~ claim 15; claim 6 ~ claim 16; claim 7 ~ claim 17; claim 8 ~ claim 18; claim 9 ~ claim 19). Each dependent claim recites the same abstract idea as its base claim, with an additional limitation that either further narrows the abstract idea itself, without integrating it into a practical application or adding significantly more or adds further insignificant extra-solution activity. The discussion below of each claim of the "claim 1" family applies equally to its parallel counterpart in the "claim 11" family.
Claims 2 and 12
"wherein the timestamp represents a time when the tenant application is signed up for receiving the output value from the cloud environment."
This limitation merely defines the abstract "timestamp" input in terms of a business/administrative fact (a customer's sign-up date) and reflects, at most, a mental observation of when an event occurred. It adds no technological element and remains within the mental-process/certain-method-of-organizing-human-activity groupings. MPEP § 2106.04(a)(2).
Claims 3 and 13
"wherein the combined output value is generated using a smoothing algorithm running in the cloud environment."
Reciting that the mathematical combination is performed by "a smoothing algorithm" makes explicit that the transformation is a mathematical calculation, reinforcing rather than curing the Step 2A, Prong One determination, and "running in the cloud environment" is generic computer implementation that adds nothing at Step 2A, Prong Two or Step 2B. SAP Am., 898 F.3d at 1167-68 (selecting a mathematical/statistical technique to analyze data does not confer eligibility).
Claims 4 and 14
"wherein the smoothing algorithm takes a weighted average of the first model value from the first AI model and the second model value from the second AI model to generate the combined output value."
A weighted average is a textbook mathematical calculation; reciting it does not integrate the abstract idea into a practical application or add significantly more. SAP Am., 898 F.3d at 1163, 1167-68; Digitech, 758 F.3d at 1350-51.
Claims 5-7 and 15-17
"wherein the first weight of the first model value of the first AI model gradually decreases from a start of the window of time to an end of the window of time, and the second weight of the second model value of the second AI model proportionally decreases" (claims 5, 15); "wherein the first weight ... is 100% and the second weight ... is 0 at the start of the window of time" (claims 6, 16); "wherein the first weight ... is 0 and the second weight ... is 100% at the end of the window of time" (claims 7, 17).
These limitations recite nothing more than the mathematical formula for a linear (straight-line) interpolation function tied to elapsed time within the window — a mathematical relationship expressed with greater numerical specificity. Reciting a mathematical relationship more specifically does not transform an otherwise-abstract mathematical concept into patent-eligible subject matter. Parker v. Flook, 437 U.S. at 594-95; SAP Am., 898 F.3d at 1163. (The Office separately notes an internal inconsistency in this claim set bearing on definiteness under 35 U.S.C. § 112(b); see Section III.B, below.)
Claims 8 and 18
"wherein the output value displayed to each of the plurality of tenant applications is accompanied by a plurality of explanatory factors."
Displaying additional data alongside the output value is further insignificant post-solution/output activity. MPEP § 2106.05(g); Elec. Power Grp., 830 F.3d at 1354.
Claims 9 and 19
"wherein when the output value is the combined output value of the first AI model and the second AI model, the plurality of explanatory factors include more explanatory factors from one of the first AI model or the second AI model with a greater weight given in generating the combined output value."
This is a further mental evaluation/comparison (which of the two models was weighted more heavily and preferentially reporting that model's explanatory factors) that adds no technological element; it remains within the mental-process grouping and constitutes, at most, additional insignificant post-solution activity in how the display step is populated. MPEP §§ 2106.04(a)(2)(III), 2106.05(g).
Claim 10
"wherein the output value displayed by the cloud environment to each of the plurality of tenant applications is a prediction score representing a probability that a task is to be successfully closed."
This limitation confirms that the "AI feature" at issue is a business-forecasting metric (e.g., a sales-opportunity or task-closure probability), placing the claim within the "certain methods of organizing human activity" grouping (a fundamental business practice of forecasting the likely success of a commercial task) in addition to the mathematical-concept and mental-process groupings already identified, without adding any technological element. MPEP § 2106.04(a)(2)(II); buySAFE, 765 F.3d at 1355 (claims to a fundamental business practice implemented on generic computer components are not patent-eligible).
For at least these reasons, none of dependent claims 2-10 or 12-19 integrates the abstract idea into a practical application or supplies an inventive concept, and each remains ineligible under 35 U.S.C. § 101 for the same reasons as its respective base claim.
H. Conclusion — 35 U.S.C. § 101
For the foregoing reasons, claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
II. Additional Consideration — "Electromagnetic Signal Per Se" and "Software Per Se" Eligibility (MPEP § 2106.03)
Apart from the substantive abstract-idea rejection above, the Office has also considered whether any claim is directed to a signal or data structure per se, or to software per se untethered to any statutory category, under MPEP § 2106.03; In re Nuijten, 500 F.3d 1346, 1353-57 (Fed. Cir. 2007) (a transitory, propagating electromagnetic signal, without more, is not a "process, machine, manufacture, or composition of matter" and is therefore ineligible under § 101); and In re Warmerdam, 33 F.3d 1354, 1361 (Fed. Cir. 1994) (a computer program per se, unclaimed in combination with any physical structure or process, does not fall within a statutory category).
Claims 1-10 are directed to a "method" and are not implicated by the signal-per-se or software-per-se concern, as method claims are evaluated under the process category. Claims 11-19 are directed to a "data processing system" comprising physical structure ("a processor; and a memory coupled to the processor") and are likewise not implicated.
Claim 20 recites "a non-transitory computer-readable medium." Under MPEP § 2106.03(I), when the broadest reasonable interpretation of a claimed "computer-readable medium" or "machine-readable medium," in light of the specification, would encompass transitory forms of signal transmission (e.g., a propagating electrical or electromagnetic signal per se), the claim is directed to non-statutory subject matter and should be rejected under 35 U.S.C. § 101 as covering both a signal per se and a statutory embodiment. See Ex parte Mewherter, 107 USPQ2d 1857 (PTAB 2013) (precedential). Because claim 20 expressly recites that the computer-readable medium is "non-transitory," this claim language forecloses a reading that would encompass a transitory propagating signal and claim 20 therefore does not present a signal-per-se eligibility problem under MPEP § 2106.03(I)/Nuijten, provided the term "non-transitory" is not elsewhere redefined by the Specification to include transitory media.
The published Specification's only statement on this point is the generic, unqualified sentence: "A computer program is stored in a non-transitory computer readable medium." (Specification, concluding paragraph(s)) [Examiner: insert ¶ no.]. This sentence does not define "non-transitory computer-readable medium" to include transitory signals or carrier waves, and the Office has not located any definition elsewhere in the Specification that would broaden the term to encompass transitory media.
[The Office was not able to review the complete, paginated Specification (with paragraph numbers) in preparing this draft; please confirm, using the as-filed Specification, that no other passage defines "non-transitory computer-readable medium" (or "computer-readable medium") to encompass signals, carrier waves, or other transitory media. If one is found, claim 20 should instead be rejected under § 101 as directed to a signal per se, and Applicant should be required to amend the Specification's definition and/or the claim to expressly exclude transitory media, consistent with MPEP § 2106.03(I).]
None of claims 1-20 recites "software" or a "computer program" untethered from a process, machine, or manufacture (i.e., no claim recites source code, object code, or a computer program listing per se); each claim is drafted as a method, a system comprising physical processor/memory structure, or a non-transitory storage medium storing instructions. Accordingly, no claim presents a "software per se" eligibility problem under MPEP § 2106.03 / In re Warmerdam on the present record.
II. Claim Rejections — 35 U.S.C. § 112
35 U.S.C. § 112(a) — Written Description
35 U.S.C. § 112(a) requires that the specification contain a written description of the invention that conveys, to a person of ordinary skill in the art, that the inventor(s) had possession of the claimed invention as of the filing date. Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). For a claim reciting a genus, this requirement is satisfied only by disclosure of either a representative number of species falling within the scope of the genus, or structural (or, for a computer-implemented invention, algorithmic) features common to the genus, sufficient to show possession of the full scope claimed. Id.; MPEP § 2163(II)(A)(3)(a). Without access to the complete Specification, the following potential issues are identified for the Examiner's review against the actual disclosure; pincites should be added by the Examiner upon review.
1. Genus/species mismatch — the "transformation"/"smoothing algorithm" limitations
Independent claims 1, 11, and 20 broadly recite "transforming ... the first model value and the second model value into an output value ... includes determining a first weight ... and a second weight ..." without reciting any particular algorithm for performing the transformation — i.e., the claims cover any algorithm or technique (a genus) that derives an output value from two weighted inputs. Claims 3 and 13 narrow this to "a smoothing algorithm," and claims 4 and 14 narrow it further to the single species of "a weighted average."
The published Specification discloses an "AI feature combination component 301" that implements a "weighted average algorithm 302," under which "a different weight can be given to the value of the AI feature 211 and the value of the AI feature 230 on a different date within a rollout window," with the weight given to the old model "decreas[ing] by a predetermined percentage for each subsequen[t] date" and the weight given to the new model "increas[ing] by the same percentage." (Specification, description of Fig. 3) [Examiner: insert ¶ no.]. The Specification discloses two variants for deriving the weight coefficients themselves: (i) a linear/uniform variant, illustrated in Table 1, in which the weight given to the old model "gradually decreases from 100% to 0% uniformly over the rollout window"; and (ii) a logarithmic variant, in which "a weight of the new model 236 on a particular[] date in the rollout window can be calculated using the formula: weight a = log(days since start)/log(total rollout days)[,] and a weight for the old model 215 on the particular date can be calculated using the formula: weight b = 1 − weight a." (Specification, description of Fig. 3, Table 1) [Examiner: insert ¶ no.]. Both disclosed variants, however, are properly characterized as species within the single "weighted average" combination technique recited in dependent claims 4 and 14 — they differ only in how the weight coefficients are derived (uniform/linear versus logarithmic), not in the overall combination technique (multiplying each model's output value by a weight and summing the results, e.g., "Output Value of AI feature 1 60% + Output Value of AI feature 2 40%," Specification, description of Fig. 3, Table 1 [Examiner: insert ¶ no.]). The Office has not identified any disclosed embodiment of a "smoothing algorithm" falling outside this weighted-average framework (e.g., an exponential moving average, a Kalman filter, or another smoothing technique not based on a weighted combination of the two model values) that would be representative of the full genus recited in claims 3 and 13. Accordingly, claims 3 and 13 (and, to the extent claims 1, 11, and 20 are construed to cover transformation techniques broader than a weighted average, claims 1, 11, and 20 as well) may not be supported by a written description demonstrating possession of the full scope claimed. Ariad, 598 F.3d at 1351; LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005) (claiming more broadly than one has invented or described is not permitted).
[ confirm the foregoing against the as-filed Specification's full disclosure (including any additional embodiments in the Detailed Description not captured in this draft) and insert paragraph numbers.]
2. "AI feature combiner" structure/algorithm — terminology mismatch with the Specification
Claim 1 (and, by dependency, claims 2-10) recites an "AI feature combiner" that performs the claimed transformation. The Office notes that the exact phrase "AI feature combiner" does not appear to be used anywhere in the Specification; rather, the Specification consistently refers to this element as an "AI feature combination component 301" that implements a "weighted average algorithm 302" (Specification, description of Fig. 3) [Examiner: insert ¶ no.]. While an applicant is not required to use identical claim and specification terminology, the Examiner should confirm (i) that "AI feature combiner" is reasonably understood by a person of ordinary skill in the art to correspond to the disclosed "AI feature combination component 301," and (ii) whether the Specification anywhere discloses an embodiment of the "AI feature combiner"/"AI feature combination component" that performs a transformation other than the disclosed weighted-average algorithm 302 (with its two weight-derivation variants discussed in Section III.A.1, above). If the Specification discloses corresponding structure only for the weighted-average embodiment, then claim 1's broader, unqualified recitation of "an AI feature combiner" performing an unspecified "transform[ation]" may not be supported by a written description demonstrating possession of the full scope claimed, for the same reasons discussed in Section III.A.1. This issue is related to, but distinct from, the means-plus-function/corresponding-structure issue discussed in Section IV, below, and should be considered under both provisions.
[ confirm against Spec ¶ ___ (description of Fig. 3) and note any additional disclosed embodiments of the combination component not captured in this draft.]
3. Training a second AI model to output "a same AI feature"
Claims 1, 11, and 20 recite training a second AI model "wherein the second AI model outputs a same AI feature as a first AI model," without reciting any particular model architecture, training data, loss function, or training procedure by which the second model is caused to output the same feature as the first model. The Specification's disclosure on this point is itself at a high level of generality: it states that "[e]ach of the first AI model and the second AI model can be a neural network model," and that the second AI model may be released as either "a major version indicating a major update, e.g., implementing a different algorithm," or "a minor version indicating a minor update, e.g., being retrained on a new segment of data." (Specification, description of Fig. 5) [Examiner: insert ¶ no.]. This passage confirms that the Specification treats the first and second AI models' specific architecture and training methodology as interchangeable and largely unspecified — a "major version" may "implement[] a different algorithm" altogether, with no example given of what that different algorithm might be or how it would be trained to reproduce "a same AI feature." Given the well-recognized unpredictability of the machine-learning arts — i.e., that a change in model architecture, training data, or training procedure can produce materially different outputs — this generic, result-oriented disclosure ("can be a neural network model," "implementing a different algorithm") does not demonstrate possession of the full genus of "AI models" and training approaches encompassed by claims 1, 11, and 20, and a written description rejection is warranted unless a more specific disclosure is identified elsewhere in the Specification. Ariad, 598 F.3d at 1351; cf. Amgen Inc. v. Sanofi, 598 U.S. 594, 610, 615 (2023) (discussing the bearing of genus/field unpredictability on the specificity of disclosure required, in the analogous enablement context).
[ confirm against Spec ¶ ___ (description of Fig. 5) and identify any additional disclosure of model architecture/training elsewhere in the Detailed Description.]
Applicant is advised that these potential issues must be resolved by comparison of the claim language to the actual Specification as filed; if, upon review, the Specification discloses a sufficiently broad range of species/algorithms and model architectures corresponding to the full scope of claims 1, 3, 11, 13, and 20, this rejection should not be maintained as to the corresponding claims.
35 U.S.C. § 112(b) — Indefiniteness (Lack of Antecedent Basis / Unclear Claim Scope)
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.
Claims 1-20 are rejected under 35 U.S.C. §112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention. A claim is indefinite under 35 U.S.C. § 112(b) if a person reading it cannot tell, with reasonable certainty, what it covers. MPEP § 2173.02. The following claims contain language whose meaning or reference back to an earlier term is unclear:
A claim is indefinite under 35 U.S.C. § 112(b) when it is amenable to two or more plausible constructions such that a person of ordinary skill in the art could not determine its scope with reasonable certainty. Ex parte Miyazaki, 89 USPQ2d 1207, 1211 (BPAI 2008) (precedential); MPEP § 2173.02 (citing In re Packard, 751 F.3d 1307, 1310, 1314 (Fed. Cir. 2014) (per curiam)). The following claims are rejected under 35 U.S.C. § 112(b) as indefinite:
1. Claims 1, 2, 11, 12, and 20 — "the tenant application" lacks clear antecedent basis
Claim 1 (and 11, 20) first refers to "a plurality of tenant applications" and then to "a respective tenant application," but later says "based on a timestamp associated with the tenant application" — a phrase that does not clearly point back to either earlier phrase. It is unclear whether this means each of the tenant applications, the respective one already mentioned, or something else. Claims 2 and 12 repeat this same unclear phrase. Amending to "the respective tenant application" (or similar) would fix this.
Each of claims 1, 11, and 20 recites, earlier in the claim, "a plurality of tenant applications" and, separately, "a respective tenant application of the plurality of tenant applications" (in the transforming/transform clause), but then recites in the displaying/display clause "based on a timestamp associated with the tenant application" (singular, definite article, without "respective" or "each"). It is unclear whether "the tenant application" refers back to "a respective tenant application" introduced earlier, is intended to refer individually to each of "the plurality of tenant applications," or refers to some other, unclaimed tenant application — rendering the metes and bounds of the displaying/display step unclear. Claims 2 and 12, which depend from claims 1 and 11 respectively, compound this ambiguity by further reciting "the tenant application is signed up for receiving the output value," inheriting the same unclear antecedent. Appropriate correction — e.g., amending to "... based on a timestamp associated with the respective tenant application" or "... to each of the plurality of tenant applications based on a timestamp associated with each of the plurality of tenant applications" — would overcome this rejection as to claims 1, 2, 11, 12, and 20.
2. Claims 1, 2, 11, 12, and 20 — repeated, inconsistent references to "a timestamp"
Claim 1 (and its counterparts in claims 11 and 20) mentions "a timestamp" three separate times, with slightly different wording each time, and each time uses the indefinite article "a" rather than clearly referring back to an earlier one. It is unclear whether all three refer to the same timestamp or to different ones. Claims 2 and 12 add yet another reference to "the timestamp" without making clear which one it means.
Claim 1 (and its counterparts in claims 11 and 20) recites "a timestamp" no fewer than three times, with differing modifiers: (i) "based on a timestamp associated with each of the plurality of tenant applications" (transforming clause); (ii) "based on comparison of a respective timestamp associated with the respective tenant application to the window of time" (weight-determination clause); and (iii) "based on a timestamp associated with the tenant application" (displaying clause). Because each recitation uses the indefinite article "a" rather than referring back to a previously established "the timestamp" or "the respective timestamp," it is unclear whether all three recitations refer to one and the same timestamp for a given tenant application, or whether the claim contemplates multiple, potentially different, timestamps per tenant application. This ambiguity is compounded in claims 2 and 12, which recite "wherein the timestamp represents a time when the tenant application is signed up ..." — using yet another unclear antecedent ("the timestamp") that does not identify which of the three timestamp recitations in the base claim it modifies. Clarifying amendment (e.g., consistently reciting, and thereafter referring back to, "the timestamp associated with the respective tenant application") would overcome this rejection.
3. Claim 1 — "an output" vs. "an output value"
Claim 1 uses the phrase "an output value" throughout, but then, near the end, switches to "an output of the first AI model" (dropping the word "value") without apparent reason — while claims 11 and 20 consistently say "an output value" in the same spot. This inconsistency makes it unclear whether claim 1 means the same thing as "output value" or something broader. Amending claim 1 to say "an output value of the first AI model" would fix this and match claims 11 and 20.
Claim 1 recites, in the displaying clause, that "... the output value is one of an output of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model" (emphasis added). The first alternative uses the term "an output," whereas the term claimed throughout the remainder of claim 1 is "output value" (e.g., "an output value for the AI feature," "the output value for the AI feature," "an output value of the second AI model"), and whereas parallel claims 11 and 20 consistently recite "an output value of the first AI model" for this same limitation. The Specification's own Summary confirms that "output value" is the consistently-intended term, reciting that "the output value is one of an output value of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model" (Specification, Summary) [0015; 0017; 0019; 0080] — with "value" included in every alternative, unlike claim 1 as presented. This inconsistent terminology renders it unclear whether "an output" in claim 1 is intended to be synonymous with "output value," or is intended to claim something broader or different, such that the scope of claim 1 cannot be determined with reasonable certainty. Amending claim 1 to recite "an output value of the first AI model" (consistent with the Specification and with claims 11 and 20) would overcome this rejection.
4. Claims 5-7 and 15-17 — internal contradiction regarding the direction of the "second weight"
Claims 5 and 15 state that the second weight "proportionally decreases" over the rollout window. But claims 6/16 and 7/17 state that the second weight starts at 0% and ends at 100% — which is an increase, not a decrease. These claims contradict each other and cannot both be correct as written; this should be corrected (for example, by changing "decreases" to "increases" in claims 5 and 15).
Claims 5 and 15 recite that "the first weight of the first model value of the first AI model gradually decreases from a start of the window of time to an end of the window of time, and the second weight of the second model value of the second AI model proportionally decreases" (emphasis added). However, claims 6 and 16 (each depending from claims 5 and 15, respectively) recite that the second weight "is 0 ... at the start of the window of time," and claims 7 and 17 recite that the second weight "is 100% ... at the end of the window of time." A weight that is 0% at the start of the window and 100% at the end of the window has increased, not decreased, over the window — directly contradicting the recitation in claims 5 and 15 that the second weight "proportionally decreases." This internal inconsistency renders claims 5-7 and 15-17 indefinite, because a person of ordinary skill could not determine with reasonable certainty whether the second weight is claimed to decrease (per claims 5/15) or to increase from 0% to 100% (per claims 6-7/16-17). See MPEP § 2173.02. The Office additionally notes that this inconsistency raises a question, for the Examiner's consideration, as to whether claims 6-7 and 16-17 in fact further limit claims 5 and 15, respectively, as required by 35 U.S.C. § 112(d), or instead contradict them. Amending claim 5 (and claim 15) to recite that the second weight "proportionally increases" (or otherwise conforming the direction of change to that recited in claims 6-7/16-17) would overcome this rejection.
5. Claims 9 and 19 — "a greater weight" is unclear
These claims refer to whichever model has "a greater weight," but it is not clear whether this refers back to "the first weight" and "the second weight" established in the earlier claims or introduces something new.
Claims 9 and 19 recite that certain explanatory factors are included "from one of the first AI model or the second AI model with a greater weight given in generating the combined output value." It is unclear whether "a greater weight" refers back to a comparison between "the first weight" and "the second weight" recited in base claims 1/11 (i.e., whichever of the two models was assigned the numerically greater of the two established weights), or instead introduces a new, unclaimed weighting concept. Amending to expressly tie "a greater weight" back to "the first weight" and "the second weight" of the base claim (e.g., "... from whichever of the first AI model or the second AI model was assigned the greater of the first weight and the second weight ...") would overcome this rejection.
Applicant's response should amend the claims to resolve each ambiguity identified above; the Examiner reserves the right to apply further prior art and/or 35 U.S.C. §§ 101/112 rejections once claim scope has been clarified.
IV. Note Regarding 35 U.S.C. § 112(f) — Means-Plus-Function Claiming ("AI Feature Combiner," Claim 1 and Dependent Claims 2-10)
Claim limitations are presumed not to invoke 35 U.S.C. § 112(f) when they do not recite the term "means" (or "step"); however, that presumption is overcome, and § 112(f) applies, where the claim term fails to recite sufficiently definite structure and is instead a generic, function-defined placeholder — a "nonce" term — used as a substitute for "means," coupled with functional language, without reciting structure adequate to perform the recited function. Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1348-49 (Fed. Cir. 2015) (en banc); MPEP § 2181(I). Nonce terms recognized by the Office as functioning as generic substitutes for "means" include, e.g., "mechanism for," "module for," "device for," "unit for," "component for," "element for," "member for," "apparatus for," "machine for," and "system for." MPEP § 2181(I)(A).
Claim 1 recites "transforming, by an AI feature combiner of the prediction service in the cloud environment, the first model value and the second model value into an output value ..., wherein transformation ... includes determining a first weight ... and a second weight ...." The term "combiner," like "module," "unit," "component," and "mechanism," is a generic noun that describes only that the recited element performs a function (combining/transforming values) and, standing alone, does not connote any specific structure to a person of ordinary skill in the art. The term is prefaced only by the non-structural modifier "AI feature" and is coupled entirely with functional claim language ("transforming ... into an output value," "determining a first weight ... and a second weight"), without reciting any circuitry, algorithm, or other structure for performing that function. Under the Williamson standard, this combination of a generic, function-connoting placeholder term with purely functional claim language, unaccompanied by structural modifiers, is the kind of limitation that may properly be construed under 35 U.S.C. § 112(f) notwithstanding the absence of the word "means," because it operates as a "black box" recitation of structure that is simply a generic description of hardware or software configured to perform a specified function. Williamson, 792 F.3d at 1350; MPEP § 2181(I)(B)-(C).
[Note: Claim 1 is drafted as a method claim reciting "by an AI feature combiner ..." rather than in explicit means-plus-function or step-plus-function ("step for") format; this term is nonetheless flagged for means-plus-function-style scrutiny because it is used purely as a functionally-defined actor performing the transforming step. To the extent the Examiner determines, upon claim construction, that § 112(f) is not formally invoked because the term identifies an actor performing a method step rather than a means/step-plus-function limitation, the term "AI feature combiner" independently raises definiteness concerns under § 112(b) (Section III.B) and written-description/possession concerns under § 112(a) (Section III.A), because it is purely functionally claimed without any accompanying structural or algorithmic definition.]
If claim 1 is construed under 35 U.S.C. § 112(f), the "AI feature combiner" limitation must be construed to cover the corresponding structure described in the Specification as performing the recited transforming function, and equivalents thereof. For a computer-implemented function, the corresponding structure is not a general-purpose computer or generic hardware alone, but that general-purpose hardware together with the specific algorithm disclosed in the Specification (e.g., a mathematical formula, a prose description of the steps, or a flowchart) for performing the claimed function. WMS Gaming, Inc. v. Int'l Game Tech., 184 F.3d 1339, 1349 (Fed. Cir. 1999); In re Aoyama, 656 F.3d 1293, 1297 (Fed. Cir. 2011); Aristocrat Techs. Austl. Pty Ltd. v. Int'l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008); MPEP § 2181(II)(B).
Here, the Specification does disclose an algorithm corresponding to the "AI feature combination component 301" — the "weighted average algorithm 302" and its two weight-derivation variants (a linear/uniform variant and a logarithmic variant, weight a = log(days since start)/log(total rollout days)) discussed in Section III.A.1, above (Specification, description of Fig. 3, Table 1) [Examiner: insert ¶ no.]. Accordingly, if § 112(f) is invoked, claim 1's "AI feature combiner" limitation would properly be construed as limited to a processor configured to perform the disclosed weighted-average algorithm (in either disclosed variant), and equivalents thereof — not to the full, unbounded genus of "transformation" algorithms that the claim's plain language might otherwise be read to cover. Two consequences follow. First, because corresponding structure is disclosed, § 112(f) construction would generally avoid an indefiniteness rejection under Function Media / Ergo Licensing for total absence of corresponding structure — subject to confirming that the Specification does not use the unclaimed phrase "AI feature combiner" anywhere and that "AI feature combination component 301" is the only reasonable candidate corresponding structure (see Section III.A.2, above). Second, this construction creates a claim-differentiation tension with dependent claims 3-4 and 13-14: if claim 1's "AI feature combiner" is already limited by § 112(f) to (essentially) the weighted-average algorithm disclosed in the Specification, then claim 3/13's further recitation of "a smoothing algorithm" and claim 4/14's further recitation of "a weighted average" would add little or no additional limitation beyond what § 112(f) already imports into claim 1, in tension with the presumption that each dependent claim is of narrower scope than the claim from which it depends. See MPEP § 2181(II)(B); cf. MPEP § 2144.04. The Examiner should weigh this tension in deciding whether, and how, to apply § 112(f) construction to claim 1.
[ confirm the foregoing against Spec ¶ ___ (description of Fig. 3, Table 1) and against the full Detailed Description for any additional disclosed embodiments of the combination component's algorithm not captured in this draft.]
The Office additionally notes, for completeness, that the terms "model registry service" and "prediction service" (claim 1) are similarly generic, function-associated labels ("service" performing a specified function) that the Examiner may wish to evaluate under the same Williamson framework, although "service" may be understood in the cloud-computing art to connote a specific class of software architecture (e.g., a microservice) and therefore presents a comparatively weaker case for invoking § 112(f) than "AI feature combiner." Claims 11 and 20 do not use comparable nonce terminology — they recite the transforming/generating/displaying functions as performed by "the processor" (claim 11) or by "the data processing system" pursuant to stored "instructions" executed by "at least one hardware processor" (claim 20), and "processor" is generally recognized as reciting sufficient structure such that § 112(f) is not invoked for those claims. MPEP § 2181(I).
V. Summary
Claims 1-20 stand rejected under 35 U.S.C. § 101 as being directed to a judicial exception (an abstract idea) without significantly more, reinforced by the Specification's own characterization of the problem solved as a customer-experience/business problem rather than a technical one. Claims 3 and 13 stand rejected, and claims 1, 11, and 20 are identified for potential rejection, under 35 U.S.C. § 112(a) (written description), because the Specification's disclosed weighted-average algorithm (in its linear and logarithmic variants) does not appear representative of the full "smoothing algorithm" genus of claims 3/13, and its generic "neural network model"/"different algorithm" disclosure does not appear representative of the full genus of AI models and training approaches encompassed by claims 1, 11, and 20. Claims 1, 2, 5, 6, 7, 9, 11, 12, 15, 16, 17, 19, and 20 stand rejected under 35 U.S.C. § 112(b) as indefinite. The "AI feature combiner" limitation of claim 1 (and dependent claims 2-10) is identified for means-plus-function claim construction under 35 U.S.C. § 112(f); the Specification discloses corresponding structure (the weighted-average algorithm of Fig. 3) under the label "AI feature combination component 301" rather than "AI feature combiner," which the Examiner should reconcile, and which — if construed under § 112(f) — creates a claim-differentiation tension with dependent claims 3-4/13-14. Claim 20 does not present a signal-per-se eligibility issue under MPEP § 2106.03 by virtue of its express "non-transitory" limitation and the Specification's generic, non-broadening reference to "a non-transitory computer readable medium." All Specification citations above should be finalized with pinpoint paragraph numbers from the as-filed/as-published Specification before this draft is entered into the record.
Examiner’s Response to Arguments
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC § 103
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping prior-art rejection including Applicant’s amendments and arguments and unique combination of features and elements not taught by the prior-art without hindsight reasoning.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claim X, on page(s) 8-9 of Applicant’s Remarks / After Final Amendments (dated 07/15/2011), Applicant(s) argues that the cited reference(s) (Ellis and Vandermolen) fails to teach, describe, or suggest the amended features. Specifically, Applicant(s) argues that cited reference(s) do not teach, describe, or suggest the following: . With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
Examiner’s Response: Claim Rejections – 35 USC §112
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §101
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping 35 USC 101 rejection including Applicant’s amendments, arguments, lack of abstract idea, and practical integration.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claims 1-20, on page(s) 7-11 of Applicant’s Remarks (dated 07/20/2026), Applicants traverse the 35 USC §101 rejections. Applicant’s Remarks have been fully considered but are not persuasive. The rejection of claims 1-20 under 35 U.S.C. § 101 is maintained for the reasons set forth below, in addition to the reasons of record.
As a preliminary matter, the Remarks refer to independent claim 1 "as amended." The claim language reproduced and relied upon throughout the Remarks, however, is identical in substance to claim 1 as previously presented and considered in the rejection of record; no limitation has been identified in the Remarks that was not already addressed therein. To the extent any non-substantive amendment has been entered, it has been fully considered and does not alter the analysis below.
A. Applicant's Argument That the Claims Recite "a Specific Application of AI to a Particular Technological Field" Under the 2024 AI SME Update Is Not Persuasive
Applicant argues the claims recite a specific technical architecture — a model registry service, a prediction service, and an "AI feature combiner" — rather than just an abstract idea, citing the USPTO's 2024 AI guidance. This is not persuasive. That guidance asks whether a claim recites the actual technical means of achieving a result, not just the result itself. Claim 1 does not explain how the second AI model is trained, how the model registry service or prediction service technically works, or how the "AI feature combiner" performs its calculation beyond a generic "weighted average." Simply giving names to generic computer parts that each perform an ordinary function does not make an abstract idea eligible. Two-Way Media Ltd. v. Comcast Cable Commc'ns, LLC, 874 F.3d 1329, 1337 (Fed. Cir. 2017). And unlike the eligible example given in the 2024 guidance (which added a specific real-world action — blocking harmful network traffic in real time), claim 1's only additional step is displaying a number to customers, which is not a technical improvement. Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1354 (Fed. Cir. 2016).
Applicant argues that the claims recite "a specific technical architecture for managing concurrent AI model execution during a rollout window" — comprising a model registry service, a prediction service, and an "AI feature combiner" — and that this architecture reflects "a particular way to achieve a desired outcome" of the kind the USPTO's 2024 AI SME Update recognizes as patent-eligible, rather than "merely claiming the idea of a solution or outcome." Remarks at pg. 8. This argument is not persuasive.
The very language Applicant quotes from the 2024 AI SME Update draws the relevant distinction: a claim improves technology and thus integrates a judicial exception into a practical application, only where it recites the means of accomplishing a desired outcome — not merely the outcome itself. See MPEP § 2106.04(d)(1) ("[A] claim does not improve technology if it merely claims the idea of a solution or outcome and not the means of accomplishing it."); 2024 AI SME Update at 8-9. Claim 1 does not recite any specific technical means for training the second AI model, for generating a model value with either model, or for transforming two model values into an output value; it recites only the results to be achieved, at each step, using purely functional language: "training ... a second AI model, wherein the second AI model outputs a same AI feature," "concurrently generating ... a first model value ... and a second model value," and "transforming ... into an output value ... includes determining a first weight ... and a second weight ... based on comparison." No algorithm, data structure, network protocol, memory-management technique, or other technical implementation detail is recited for any of these steps; the only algorithmic detail appearing anywhere in the claim set is the generic "weighted average" of dependent claims 4 and 14 — itself a textbook mathematical calculation, not a technical means. SAP Am., 898 F.3d at 1163, 1167-68.
Naming the components that perform each generic function — a "model registry service," a "prediction service," an "AI feature combiner" — does not itself supply the missing technical means. The Federal Circuit has repeatedly held that breaking an abstract process into a sequence of steps performed by separately-labeled functional components does not render the process any less abstract where, as here, each named component is defined solely by the generic function it performs. Two-Way Media Ltd. v. Comcast Cable Commc'ns, LLC, 874 F.3d 1329, 1337 (Fed. Cir. 2017) (breaking a process into discrete steps performed by differently-named functional components does not confer eligibility where the claim is still "directed to the abstract idea ... merely restated in different language"); In re TLI Commc'ns LLC Patent Litig., 823 F.3d 607, 611, 615 (Fed. Cir. 2016) (generic "server" and "telephone unit" performing their basic, expected functions do not integrate an abstract idea into a practical application, regardless of how many components are named); Affinity Labs of Tex., LLC v. DIRECTV, LLC, 838 F.3d 1253, 1258-59 (Fed. Cir. 2016). "Cloud environment," "model registry service," and "prediction service" are used at the same high level of generality condemned in these decisions: nothing in the claims, and nothing the Examiner has identified in the Specification, describes a specific database schema, indexing scheme, message-passing protocol, or other implementation detail for the model registry service or prediction service that would distinguish them from any generic distributed software service performing the recited generic functions.
Applicant's reliance on the 2024 AI SME Update is further undermined by the guidance's own worked examples. In Example 47 (Anomaly Detection in Network Traffic), the claim found eligible added a specific, technologically concrete remedial action — detecting malicious data packets in real time and blocking the associated network traffic — that changed how the underlying network operated, going beyond the training/detection steps themselves. 2024 AI SME Update, Example 47, Claim 2. Claim 1 here recites no comparable technical end-use: its only post-transformation step is "displaying ... the output value ... to each of the plurality of tenant applications," which does not change how any computer, network, or the AI models themselves function, and is insignificant post-solution activity. MPEP § 2106.05(g); Elec. Power Grp., 830 F.3d at 1354. Claim 1 is accordingly distinguishable from Example 47's eligible claim, and is instead analogous to Recentive, where the Federal Circuit held that machine-learning claims reciting training and applying models to generate an output, without more, are ineligible because they "do no more than claim the application of generic machine learning to new data environments, without disclosing improvements to the [machine learning] models" themselves. Recentive, 134 F.4th at 1218-19.
B. Applicant's Argument That the Claims Cannot Be Directed to a Mental Process Is Not Persuasive, and Does Not Address the Independent Mathematical-Concept and Certain-Method-of-Organizing-Human-Activity Grounds of the Rejection
Applicant argues the claims cannot recite a "mental process" because a human cannot run two AI models at once, citing Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138 (Fed. Cir. 2016). This is not persuasive, for a few reasons.
First, Synopsys does not actually support this point. In that case, the court found that the claims at issue were mental processes that a person could perform with pencil and paper and rejected a similar complexity-based argument. Second, and more importantly, the rejection is not based on running two AI models being a mental process — that step was treated as ordinary data-gathering. The abstract idea is the weighting/blending calculation that happens after the two values are already generated — something a person given two numbers, a date, and a time window could work out by hand, as confirmed by the "weighted average" language in claims 3-4. Third, even if the "concurrently generating" step really could not be done mentally, that would only affect the "mental process" label — it would not change the fact that the claim also recites a mathematical formula, which is its own, separate category of abstract idea that does not depend on whether a human could do the math by hand. Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205, 1215-21 (Fed. Cir. 2025), confirms this: those claims also clearly could not be performed in a human mind, yet the court still found them ineligible, because applying machine learning generically, without a real technical improvement, is not enough.
Applicant argues that the claims cannot recite a mental process because "the human mind is not equipped to concurrently run two AI models to generate inference values in real-time for multiple tenant applications," citing Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1147-49, 120 USPQ2d 1473, 1480-81 (Fed. Cir. 2016). This argument is not persuasive, for at least three independent reasons.
First, Applicant's reliance on Synopsys is misplaced. In Synopsys, the Federal Circuit affirmed that all of the claims before it — which required multi-step, several-variable translation of complex functional circuit descriptions into hardware component descriptions — recited an unpatentable abstract mental process, expressly holding that the claimed steps "read on an individual performing the claimed steps mentally or with pencil and paper," and rejecting the patentee's argument that the complexity of the claimed data manipulation removed the claims from the mental-process category, noting that the named inventors had themselves performed the claimed process mentally. Synopsys, 839 F.3d at 1139, 1146-47; see MPEP § 2106.04(a)(2)(III) (citing Synopsys as an example of a claim that recites a mental process). The Examiner is unable to identify a holding in Synopsys for the proposition Applicant attributes to it — that claims requiring several-step data manipulation beyond practical human capability are, for that reason, not mental processes. Applicant is invited to identify, with specificity, the portion of the decision supporting that reading if it believes this characterization is in error. To the extent Applicant instead intends to invoke the general principle — recognized in other decisions, e.g., SRI Int'l, Inc. v. Cisco Sys., Inc., 930 F.3d 1295, 1304 (Fed. Cir. 2019) ("the human mind is not equipped to detect suspicious activity by using network monitors and analyzing network packets") — that a claim does not recite a mental process where the claimed steps cannot practically be performed in the human mind, that principle is addressed below.
Second, even accepting that "concurrently generating ... a first model value ... and a second model value" with two executing AI models cannot practically be performed in the human mind, this does not overcome the rejection, because that limitation is not the basis on which the rejection identifies the abstract idea. As explained in the rejection of record, "concurrently generating" the two model values is, at most, necessary data-gathering that precedes and feeds the abstract calculation, and was identified as insignificant extra-solution activity under MPEP § 2106.05(g) — not as the recited abstract idea itself. The abstract idea identified in the rejection is the mathematical/mental operation of "determining a first weight of the first model value and a second weight of the second model value based on comparison of a respective timestamp ... to the window of time" and "transforming ... the first model value and the second model value into an output value" using those weights — an operation that a human analyst, given the two already-generated numeric model values, a timestamp, and the rollout window, could perform by comparing the timestamp to the window and calculating a proportional (weighted-average) blend of the two values, exactly as confirmed by dependent claims 3-4 and 13-14 ("a smoothing algorithm," "a weighted average"). The Remarks do not address this weight-determination and value-transformation limitation or explain why it — as distinct from the model-execution steps — cannot practically be performed mentally or with pen and paper.
Third, and independently, the "practically be performed in the human mind" inquiry that Applicant invokes applies only to the mental-process abstract-idea grouping; it does not apply to, and does not exempt the claims from, the mathematical-concept grouping under MPEP § 2106.04(a)(2)(I) or the certain-methods-of-organizing-human-activity grouping under MPEP § 2106.04(a)(2)(II), both of which independently support the rejection, as set forth in the rejection of record. A mathematical formula or calculation remains a "mathematical concept" abstract idea regardless of whether it is computationally intensive or requires a computer to execute at scale; the mathematical-concept category is not limited to calculations performable entirely by hand. Parker v. Flook, 437 U.S. at 594-95; SAP Am., 898 F.3d at 1163, 1167-68. Nor do the Remarks address the Office's independent finding that the claims recite a certain method of organizing human activity — a phased rollout/transition of a business service and, per claim 10, a business-forecasting metric — a ground that likewise does not depend on whether the claimed steps can be performed mentally. The Federal Circuit's decision in Recentive confirms that this distinction is dispositive: the machine-learning training and application claims at issue there plainly could not be performed by an unaided human mind at the scale and speed of a computer, yet the Federal Circuit still held them ineligible, because the mere application of generic machine learning to a new data environment — without a disclosed improvement to the models or to computer functionality — does not confer eligibility, irrespective of whether the underlying computation could be performed mentally. Recentive, 134 F.4th at 1215-21. Applicant's mental-process argument, even if fully credited, therefore does not overcome the independent mathematical-concept and certain-method-of-organizing-human-activity grounds of the rejection, which remain unaddressed by the Remarks.
C. Applicant's Practical-Application Argument, Relying on Specification ¶¶ [0002] and [0022], Is Not Persuasive
Applicant points to benefits listed in the Specification at ¶ [0022] — less need to explain disruptions to customers, and faster work for data science teams — and to ¶ [0002]'s explanation that model updates can cause "a sudden gap" in values. These passages actually support the rejection rather than undermine it: they describe a business/customer-service problem (fewer support calls, smoother customer experience, easier internal workflows), not a technical problem with how a computer or network operates. A claim must describe the specific technical means of achieving an improvement, not just assert the improvement as a byproduct of performing the underlying calculation. SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163 (Fed. Cir. 2018). Here, the "improvement" Applicant identifies is simply the natural result of performing the blending calculation itself, which is not enough to show eligibility.
Applicant argues that the claims integrate any alleged abstract idea into a practical application that "improves the functioning of a computer," citing the Specification's statement, at paragraph [0022], of purported benefits — "less communication overhead to tenants, user level customized rollout of new models, less tenant support resulting from a gap between output values of the different versions of AI models, and faster and more flexible innovation by data science teams by abstracting ML pipelines and deployment management per tenant" — and the Specification's statement, at paragraph [0002], that "the release of the updated AI model may often result in undesirable user experience due to a sudden gap in the values of the AI feature." This argument is not persuasive.
As an initial matter, the very passage Applicant cites from paragraph [0002] confirms, rather than rebuts, the Office's characterization of the problem addressed as a business/customer-experience problem: a "sudden gap" that causes "undesirable user experience" and requires tenants to seek "explanations for the disruptions from service providers" is, on its face, a customer-relations concern, not a deficiency in the technical operation of a computer or network. See rejection of record (citing Specification, Background). Paragraph [0022]'s recited benefits confirm this characterization: "less communication overhead to tenants" and "less tenant support" describe a reduced customer-service burden — a business/administrative advantage — and "faster and more flexible innovation by data science teams," achieved "by abstracting ML pipelines and deployment management," describes a workflow benefit to human engineers, not a technical improvement in how any computer executes, stores, or transmits data. None of the paragraph [0022] benefits describes a change in a computer's or network's technical operation, such as reduced processing time, reduced memory or bandwidth consumption, or increased throughput or reliability.
More fundamentally, MPEP § 2106.05(a) requires that a claim recite the specific means or technical steps by which an improvement is achieved, not merely assert or achieve the improvement as an incidental result of applying the abstract idea itself. Reciting a result or benefit, without reciting how the claimed steps technically achieve it, is insufficient. Trading Techs. Int'l, Inc. v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019) (claims "directed to the presentation of information, without any technical explanation as to how to achieve the manner of display," are not eligible); SAP Am., 898 F.3d at 1163 ("claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not confer eligibility); Customedia Techs., LLC v. Dish Network Corp., 951 F.3d 1359, 1364 (Fed. Cir. 2020) (a touted benefit, without a specific recited means of achieving it, does not confer eligibility). Here, the "improvement" Applicant identifies — fewer customer complaints and less need for customer-service explanations — is achieved entirely by performing the abstract idea itself (mathematically smoothing the customer-visible output value across the rollout window); it is not a separate technical benefit flowing from any additional technical element. Where, as here, the asserted benefit is coextensive with the abstract idea itself, "a claimed invention's use of the [abstract idea], no matter how groundbreaking, would not be sufficient" to supply an inventive concept or a practical application. BSG Tech LLC v. Buyseasons, Inc., 899 F.3d 1281, 1287-88 (Fed. Cir. 2018); Intellectual Ventures I LLC v. Erie Indem. Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017).
D. Applicant's Argument That the Claims Are Not "Generic A/B Testing or Feature Gating" Does Not Overcome the Rejection
Whether or not the claims can be compared to "A/B testing" or "feature gating" does not change the analysis. The relevant question is whether the claim recites a specific technical way of achieving its result, not what industry label might apply. As explained above, each named component in the claim performs only a generic function, and naming more components does not, by itself, make the claim eligible. Two-Way Media, 874 F.3d at 1337.
Applicant argues that the claims recite “a specific arrangement of components … performing specific functions,” and are therefore distinguishable from “generic A/B testing or feature gating.” Regardless of the descriptive label used for the underlying real-world analogy, the eligibility of the claims is assessed under the two-step Alice/Mayo framework applied in the rejection of record, not by reference to whether the claims can be analogized to any particular named industry practice. As explained in Sections A and B, above, the components Applicant identifies — the “cloud environment,” “model registry service,” “prediction service,” and “AI feature combiner” — are each recited solely in terms of the generic function each performs, without any specific technical implementation detail, and the number of separately-named functional components recited does not, by itself, confer eligibility. Two-Way Media, 874 F.3d at 1337; In re TLI Commc’ns, 823 F.3d at 611, 615. The underlying concept remains what it was identified to be in the rejection of record: phasing in a new predictive value for an old one over a defined transition window by mathematically blending the two in proportion to elapsed time, and displaying the result — a scheme falling within the mathematical-concept and certain-method-of-organizing-human-activity groupings of MPEP § 2106.04(a)(2), whatever industry shorthand might be used to describe it.
E. Conclusion
For the foregoing reasons, Applicant's arguments have been fully considered but are not persuasive, and the rejection of claims 1-20 under 35 U.S.C. § 101 is maintained. Applicant has not addressed the independent mathematical-concept and certain-method-of-organizing-human-activity grounds identified in the rejection, nor has Applicant identified any additional element, considered individually or in ordered combination, that integrates the identified abstract idea into a practical application or that amounts to significantly more than the abstract idea under Step 2B.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
PERTINENT PRIOR ART – Patent Literature
The prior-art made of record and considered pertinent to applicant's disclosure.
Narita 2022/0215297 [0011 - the process includes specifying first distribution of a feature of data calculated by a second machine learning model…]
NarasimhaMurthy et al. 2024/0371141 [0065 - second AI model 130B is trained using at least some of the data used to train the first AI model 130A so the second AI model 130B is capable of characterizing images on which the first AI model 130A is trained. … stored in the memory 124B, the cloud]
Woodford et al. 2019/0260794 [0017 - one or more machine learning models such as a first Artificial Intelligence model trained on cloud events, administration, and related data, a second Artificial Intelligence model trained on SaaS events for a specific SaaS application, a third Artificial Intelligence model trained on potential cyber threats]
Sawaf et al. 2022/0318887 [0023 - an efficient way to train AI models in a hybrid cloud environment by providing a high-level API for training and automated tuning of AI models by efficiently running training jobs in the cloud]
Ma et al. 2019/0347113 [0037 - applications launched within the time-window with the preset length from the time point at which the sample usage information is collected as the start time point are monitored, and the preset number of applications launched first in the applications launched within the time-window are set as the sample labels for the sample usage information. Then the predetermined machine learning model is trained based on the sample usage information and the sample labels for the sample usage information, to obtain the application prediction model]
Chen et al. 2019/0370603 [0117 - determines a first application running in foreground at a sampling time in a preset sampling period, determines whether the first application is newly installed within a time window having a preset time length and ending with the sampling time, and uses the result of the determining as identity information of the first application and then trains a preset machine learning model based on sample data corresponding to the first application]
Latapie et al. 2020/0364466 [0046 - machine learning systems discussed below can be used to determine which timescales have commonalities and allow clustering and grouping timestamps in timescales which display periodicity]
Alon et al. 2022/0156524 [0004 - combining the first model output and the second model output to generate a combined output]
PERTINENT PRIOR ART – Non-Patent Literature (NPL)
The NPL prior-art made of record and considered pertinent to applicant's disclosure.
Domenico Cotroneo, Luigi De Simone, Pietro Liguori, Roberto Natella, Run-time failure detection via non-intrusive event analysis in a large-scale cloud computing platform, Journal of Systems and Software, Volume 198, 2023.
Ning, Zhen-Hu, Shen, Chang-Xiang, Zhao, Yong, Liang, Peng, Trusted Measurement Model Based on Multitenant Behaviors, The Scientific World Journal, 2014, 384967, 12 pages, 2014.
THIS ACTION IS MADE FINAL
Applicant’s amendment necessitated new grounds of rejection and FINAL Rejection.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b
Claims 1, 11, 20 are rejected under 35 U.S.C. 103 as being unpatentable over: Odibat et al. 2024/0273396; in view of Miller et al. 2023/0037733; in further view of Andersh et al. 2003/0100972.
18/304,710 – Claim 1. Odibat et al. 2024/0273396 A method of managing artificial intelligence (AI) model rollouts (Odibat et al. 2024/0273396 [0001 - management of machine learning (ML) models in a multi-tenant cloud computing environment … managing core capabilities of continuous integration and continuous deployment (CI/CD) in artificial intelligence (AI) model development environments] Aspects of the present invention relate generally to lifecycle management of machine learning (ML) models in a multi-tenant cloud computing environment, and, more particularly, to a system and method for managing core capabilities of continuous integration and continuous deployment (CI/CD) in artificial intelligence (AI) model development environments, champion-challenger testing, model versioning, and storage/rollback of AI/ML models.), comprising: training, by a cloud environment (Odibat et al. 2024/0273396 [0001 - multi-tenant cloud computing environment] Aspects of the present invention relate generally to lifecycle management of machine learning (ML) models in a multi-tenant cloud computing environment, and, more particularly, to a system and method for managing core capabilities of continuous integration and continuous deployment (CI/CD) in artificial intelligence (AI) model development environments, champion-challenger testing, model versioning, and storage/rollback of AI/ML models.), a second AI model, wherein the second AI model outputs a same AI feature as a first AI model in the cloud environment (Odibat et al. 2024/0273396 [0025 - multi-tenancy cloud environments] Implementations of various embodiments may provide an improvement in the technical field of multi-tenancy cloud environments. In particular, the cloud environment includes operational ML models that may be used for multiple tenants in the course of their business practice to forecast cloud usage. Reusing an operational ML model and/or generating multiple versions of the same base model improves efficiency of the cloud environment in terms of storage and speed. An ML model, also referred to herein as “model Ops,” or “MLOps,” may be used to monitor and refresh the operational models that a tenant uses to forecast cloud usage in the conduct of their business. As elements of the tenant's business evolve over time, operational ML models may become inaccurate and/or obsolete. The MLOps framework, as described herein, enables the cloud environments and cloud servers to act more efficiently for multiple tenants. Accordingly, the MLOps provides an improvement to cloud server processor throughput/load, storage requirements for each model, etc. Further, the MLOps may keep the tenants' models up-to-date and accurate for business purposes. [0027 – training and using a machine learning model… using the trained model to generate an output in real time] Implementations of the present invention are necessarily rooted in computer technology. For example, the operations of the claims that recite use of the ML models for DMS and DCMM are computer-based and cannot be performed in the human mind. Training and using a machine learning model are, by definition, performed by a computer and cannot practically be performed as a mental process (or with pen and paper) due to the complexity and massive amounts of calculations involved. For example, an artificial neural network (ANN) may have millions or even billions of weights that represent connections among nodes in one or more layers of the model. Values of these weights are adjusted, e.g., via backpropagation and stochastic gradient descent, when training the model and are utilized in calculations when using the trained model to generate an output in real time (or near real time). Given this scale and complexity, it is simply not possible for the human mind, or for a person using pen and paper, to perform the number of calculations involved in training and/or using a machine learning model. For purpose of brevity, the term “neural network” may be used herein as an equivalent to the more accurate term of “artificial neural network” to indicate a computer-based artificial intelligence methodology. [0063 - communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24, etc.; one or more devices that enable a user to interact with computer system/server 12; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 12 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces] Computer system/server 12 may also communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24, etc.; one or more devices that enable a user to interact with computer system/server 12; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 12 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 22. Still yet, computer system/server 12 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 20. As depicted, network adapter 20 communicates with the other components of computer system/server 12 via bus 18. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server 12. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.[0097 - Outputs of the deep learning neural network 1021 include a model performance threshold … ] In an embodiment, service level agreement (SLA) 1011 may include time constraints in units of seconds. Resource constraints may include data for scalability, regulatory, maintainability, serviceability, security, and cost. Cost data may contain AssetId, asset type, unit cost, total cost, region, data center, period, and description. Outputs of the deep learning neural network 1021 include a model performance threshold 1030 and model refresh frequency 1040. Two different loss functions may be used to learn the outputs. As discussed above, softmax is used to determine the model refresh frequency 1040, and linear regression is used to identify the model performance threshold 1030. In particular, softmax is a generalization of the logistic function to multiple dimensions, and used in multinomial logistic regression, and may be used to normalize output of the neural network 1021. The deep learning neural network uses a Leaky Rectified Linear Unit (Leaky ReLU) function across the hidden layers. Leaky ReLU is a type of activation function based on a ReLU, but it has a small slope for negative values instead of a flat slope. The slope coefficient may be determined before training, i.e., the slope coefficient may not be learned during training. Input is passed to deep hidden layers where weights have been shared among each other for both outputs. After backpropagation and forward propagation models are used to reduce the loss and return the model refresh frequency 1040 and model performance threshold 1030 for the tenant.); specifying, by the cloud environment, a window of time in which the second AI model is to be rolled out to a plurality of tenant applications (Odibat et al. 2024/0273396 [0026 - cloud environment ML model variants, and deployment of the ML model variants to tenants] Implementations of various embodiments may provide an improvement in the technical field of identifying and refreshing ML models used by customers of a cloud environment. In particular, implementations use machine learning to train an AI-based dynamic model selector (DMS) to automatically identify the best model for each tenant at runtime, with either minimal or no human intervention. Implementations may transform an article to a different state or thing, for instance, modifying/updating tenant profiles and cloud environment ML model variants, and deployment of the ML model variants to tenants. In particular, implementations may cause a secondary device to perform a requested action and update stored context and state information related to the machine learning functions. Historical information may be dynamically updated along with configuration profiles for the tenants. In the present disclosure, by automating the machine learning cost forecasting models for cloud usage, time and cost savings may be provided to tenants. In known systems, a data scientist was needed to update the tenants' forecasting models. In contrast, in embodiments, by automating this step using machine learning, the tenant may perform cost optimization, determine whether to switch cloud service providers, or switch a usage plan with the same provider. For example, a tenant may spend $1 million per month on their cloud services. A quick cost forecast that identifies a near future increase to $2 million per month may allow the tenant to avoid future increases earlier. Accordingly, the tenant may save money.); and displaying, by the cloud environment, an output value for the AI feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application (Odibat et al. 2024/0273396 [0063] Computer system/server 12 may also communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24, etc.; one or more devices that enable a user to interact with computer system/server 12; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 12 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 22. Still yet, computer system/server 12 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 20. As depicted, network adapter 20 communicates with the other components of computer system/server 12 via bus 18. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server 12. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc. [0097] In an embodiment, service level agreement (SLA) 1011 may include time constraints in units of seconds. Resource constraints may include data for scalability, regulatory, maintainability, serviceability, security, and cost. Cost data may contain AssetId, asset type, unit cost, total cost, region, data center, period, and description. Outputs of the deep learning neural network 1021 include a model performance threshold 1030 and model refresh frequency 1040. Two different loss functions may be used to learn the outputs. As discussed above, softmax is used to determine the model refresh frequency 1040, and linear regression is used to identify the model performance threshold 1030. In particular, softmax is a generalization of the logistic function to multiple dimensions, and used in multinomial logistic regression, and may be used to normalize output of the neural network 1021. The deep learning neural network uses a Leaky Rectified Linear Unit (Leaky ReLU) function across the hidden layers. Leaky ReLU is a type of activation function based on a ReLU, but it has a small slope for negative values instead of a flat slope. The slope coefficient may be determined before training, i.e., the slope coefficient may not be learned during training. Input is passed to deep hidden layers where weights have been shared among each other for both outputs. After backpropagation and forward propagation models are used to reduce the loss and return the model refresh frequency 1040 and model performance threshold 1030 for the tenant.), wherein the output value is one of an output of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model (Odibat et al. 2024/0273396 [0020] In embodiments, an operation or MLOps framework is established that can store models and model versions with the following details: target, prediction, accuracy, tenant/overall champions, categoric features list, numeric features list, etc. The tenant metadata, e.g., profiles and usage history, may be stored. The MLOps framework orchestrates the deployment of models using an AI Model dynamic model selector (DMS) to pick the best base model.).
Odibat et al. 2024/0273396 may not expressly disclose the “window of time” features, however, Miller et al. 2023/0037733 teaches a deployment period for deploying an algorithm which is interpreted as the claimed “window of time” (Miller et al. 2023/0037733 [claim 1] 1. A system associated with a live environment executing a current algorithm, comprising: at least one memory; instructions; and processor circuitry to execute the instructions to: manage execution of the current algorithm in the live environment, the live environment associated with a deployment platform; and manage, based on receipt of at least one potential replacement algorithm, a shadow environment to cause execution of the at least one potential replacement algorithm in the shadow environment, the shadow environment instantiated separately from the live environment, the shadow environment to utilize data from the live environment during execution of the at least one potential replacement algorithm in the shadow environment, wherein the deployment platform is to form a hybridized algorithm, the hybridized algorithm including the current algorithm and the at least one potential replacement algorithm, the at least one potential replacement algorithm deployed during a first deployment period and the current algorithm deployed during a second deployment period, the first deployment period different from the second deployment period.).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Odibat et al. 2024/0273396 to include the features as taught by Miller et al. 2023/0037733. One of ordinary skill in the art would have been motivated to do so to implement well known tools and features useful in AI feature lifecycle management through AI model updates which should prove to improve user experience, maximize profits, and optimize revenue.
Odibat et al. 2024/0273396 may not expressly disclose the “displaying an output value” features, however, Andersh et al. 2003/0100972 teaches (Andersh et al. 2003/0100972 [0006 - receive the output values from the model aggregator and to display the output values] In another embodiment, the invention is directed to a computer-readable medium containing instructions. The instructions cause a processor to instantiate a set of objects that encapsulate computational models and that include generic interfaces for invoking the computational models. The instructions further cause the processor to instantiate a model aggregator to distribute input values to the objects and to receive predicted output values from the objects. The instructions cause the processor to instantiate a control module to receive the output values from the model aggregator and to display the output values.).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Odibat et al. 2024/0273396 to include the features as taught by Andersh et al. 2003/0100972. One of ordinary skill in the art would have been motivated to do so to implement well known tools and features useful in AI feature lifecycle management through AI model updates which should prove to improve user experience, maximize profits, and optimize revenue.
18/304,710 – Claim 11. A data processing system, comprising: a processor; and a memory coupled to the processor to store instructions therein for managing artificial intelligence (AI) model rollouts, wherein the instructions, when executed by the processor, cause the processor to perform operations, the operations comprising: training a second AI model in a cloud environment, wherein the second AI model outputs a same AI feature as a first AI model in the cloud environment; specifying a window of time in which the second AI model is to be rolled out to a plurality of tenant applications; and displaying an output value for the AI feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output value of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model.
Claim 11, has similar limitations as of Claim(s) 1, therefore it is REJECTED under the same rationale as Claim(s) 1.
18/304,710 – Claim 20. A non-transitory computer-readable medium that stores instructions for managing artificial intelligence (AI) model rollouts, which instructions, when executed by a data processing system comprising at least one hardware processor, cause the data processing system to perform operation comprising: training a second AI model in a cloud environment, wherein the second AI model outputs a same AI feature as a first AI model in the cloud environment; specifying a window of time in which a second AI model is to be rolled out to a plurality of tenant applications; and displaying an output value for the AI feature to each of the plurality of tenant applications based on a timestamp associated with the tenant application, wherein the output value is one of an output value of the first AI model, an output value of the second AI model, or a combined output value of the first AI model and the second AI model.
Claim 20, has similar limitations as of Claim(s) 1, therefore it is REJECTED under the same rationale as Claim(s) 1.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over: Odibat et al. 2024/0273396; in view of Miller et al. 2023/0037733; in further view of Andersh et al. 2003/0100972; in view of Zhang et al. 2019/0243753.
18/304,710 – Claim 2. Odibat et al. 2024/0273396 further teaches The method of claim 1, wherein the timestamp represents a time when the tenant application is signed up for receiving the output value from the cloud environment (Odibat et al. 2024/0273396 [0088] Referring again to FIG. 8, the flow of operations 1-10 are indicated by a circle with the number 1-10. Operations 1-10 are also described in detail below in conjunction with FIG. 11, and referred to as operation (1), operation (2), . . . , and operation (10), for simplicity. In this example, a model repository includes a model registry 801 for base models model 1 (803A), model 2 (803B), and model 3 (803C). Initially, a model is deployed at model deployment 820 for tenant A (841A) and tenant B (841B). A dynamic model selector 822, as discussed in more detail in conjunction with FIG. 9, may be used to select the appropriate model for deployment. As illustrated, model 1 (803A) is initially deployed to both tenant A (841A) and tenant B (841B). Model 1 (803A) may be considered a default “champion” model that has gone thru champion/challenger testing, and is the default for tenants A (841A) and B (841B). Model 2 (803B), model 3 (803C), and model 1.2 (803D) may be champion models for at least one specific tenant. In this illustration the models used by tenant A (841A) and tenant B (841B) are monitored by tenant model monitoring 830. The tenant model monitoring receives a configuration profile from dynamic configuration 832. Tenant model monitoring 830 may be triggered based on time, tenant profiles, data/concept drift and tenant usage, as indicated in the tenant configuration.) .
Odibat et al. 2024/0273396 may not expressly disclose the “timestamp” features, however, Zhang et al. 2019/0243753 teaches (Zhang et al. 2019/0243753 [0309 - a first timestamp registering a receipt of the availability information at the cloud services 1552 or at the sub-service of the cloud application 1554 and receiving a second-time stamp registering the cloud services 1552 or the sub-service of the cloud application 1554 sending the availability information back to the cloud check control engine] The system 1550 may further be utilized for testing the subject system 1550 in a latency testing process utilizing one or more digital computers, according to an embodiment. The cloud check control engine may further measure the amount of elapsed time (e.g., latency) by receiving a first timestamp registering a receipt of the availability information at the cloud services 1552 or at the sub-service of the cloud application 1554 and receiving a second-time stamp registering the cloud services 1552 or the sub-service of the cloud application 1554 sending the availability information back to the cloud check control engine. The cloud check control engine may generate a measure of latency by subtracting first stamp from the second-time stamp. The intermittency metric 1141 and the severity metric 1170 may be applied as meta-metrics for the cloud service 1552 or the sub-services of the cloud application 1554 (e.g. latency). For example, if the industry average latency is 1 millisecond for the cloud services 1552 and the measurement unit is hourly, service latency >1 millisecond may be defined as an intermittent failure with value=0 (E.G., FAIL).).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Odibat et al. 2024/0273396 to include the features as taught by Zhang et al. 2019/0243753. One of ordinary skill in the art would have been motivated to do so to implement well known tools and features useful in AI feature lifecycle management through AI model updates which should prove to improve user experience, maximize profits, and optimize revenue.
18/304,710 – Claim 12. The data processing system of claim 11, wherein the timestamp represents a time when the tenant application is signed up for receiving the output value from the cloud environment.
Claim 12, has similar limitations as of Claim(s) 2, therefore it is REJECTED under the same rationale as Claim(s) 2.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over: Odibat et al. 2024/0273396; in view of Miller et al. 2023/0037733; in further view of Andersh et al. 2003/0100972; in view of Ma et al. 2015/0120244.
18/304,710 – Claim 3. Odibat et al. 2024/0273396 further teaches The method of claim 1, wherein the combined output value is generated using a smoothing algorithm running in the cloud environment (Odibat et al. 2024/0273396 [0046-0047 – cloud environment][0085 - algorithms] In known systems, there may be 100 different algorithms that may be used for a tenant for their cloud usage forecasting. A data scientist may need to make educated guesses to determine which subset of those 100 algorithms to test for use with the tenant before selecting one to deploy. For instance, the data scientist may guess that linear regression or logistical regression many be viable candidates, but the testing and validation of these algorithms is time intensive. Further, as the tenant's data changes, the whole process may need to be manually repeated. In the examples discussed herein, the term Model 1 may refer to a particular machine learning (ML) algorithm that may be used or customized for the tenant. The term Model 1.2 may refer to the same algorithm that is trained with different data, or another variant of Model 1. Model 2 may refer to a different algorithm than Model 1 or Model 1.2. In known systems, manually selecting the best model for a tenant is time-consuming, expensive and may be error prone, requiring empirical trial and error tests. Further, refreshing the models when the tenant's data or business changes and degrades the accuracy of the initial model selected may require a full manual refresh. In contrast, embodiments as described herein provide an automated system for selecting, deploying, and refreshing machine learning models for multiple tenants. [0102 – multi-tenant cloud environment running various algorithmic models] FIG. 11 is a flow diagram depicting an exemplary method 1100 for managing model operations (MLOps), in accordance with aspects of the invention. In a multi-tenant cloud environment, multiple tenants will subscribe to machine learning (ML) models from one or more providers to make forecasts, predictions, or to help manage their business' cloud and resource usage. A tenant corresponds to a configuration file, also referred to as a configuration profile, and will be identified as a specific category based on their business type, size, location, cost, and resource constraints, etc. A cloud model provider may develop their own models using in-house data scientists 1101 and/or use third party models developed by outside data scientists or organizations 1103. Each model may correspond to a different ML algorithm such as random forest, decision trees, gradient boosting trees, support vector machine (SVM), Naïve Bayes, KNN, linear regression, logical regression, deep learning, and other algorithms now known or to be developed in the future. It will be understood that different algorithms work better for different data sets (both size and type), and resource constraints. Therefore, some models will be better suited for a tenant based on its configuration profile. The cloud model provider receives the models from the data scientists and/or third party in block 1110. The cloud model provider stores the various models in a model registry in block 1120. The model registry may be a local storage media or be accessed across a network remotely. The model registry may be distributed between or among more than one physical storage media, such as the storage system 34 of FIG. 1. The ML models are stored with a corresponding identifier for model version, and criteria for use as a default model based on a tenant's configuration profile. Some models may be designated as champion models for one or more tenant category.).
Odibat et al. 2024/0273396 may not expressly disclose the “smoothing algorithm” features, however, Ma et al. 2015/0120244 teaches (Ma et al. 2015/0120244 [0055 - smoothing algorithm…] Finally, in operation 208, apparatus 100 may optionally include means, such as processor 102 or the like, for applying a smoothing algorithm to adjust the road width of at least one section. In some embodiments, the smoothing algorithm is based on an arbitrary number N of neighbors, in which case the road width is adjusted to be either the mean value or median value of road widths of the N sections of the point cloud centered on the section being evaluated. In some embodiments, the smoothing algorithm may be applied only in situations where there are occlusions in the section of the point cloud being evaluated. Additionally or alternatively, the smoothing algorithm may be applied if the calculated road width of the section being evaluated differs from its neighbors by more than a predetermined amount or percentage. Accordingly, by preventing sudden changes of road width between sections, the smoothing algorithm is likely to reduce the impact of "noise" in the point cloud data, and concomitantly to increase the accuracy of the overall road width estimation.).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Odibat et al. 2024/0273396 to include the features as taught by Ma et al. 2015/0120244. One of ordinary skill in the art would have been motivated to do so to implement well known tools and features useful in AI feature lifecycle management through AI model updates which should prove to improve user experience, maximize profits, and optimize revenue.
18/304,710 – Claim 13. The data processing system of claim 11, wherein the combined output value is generated using a smoothing algorithm running in the cloud environment.
Claim 13, has similar limitations as of Claim(s) 3, therefore it is REJECTED under the same rationale as Claim(s) 3.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over: Odibat et al. 2024/0273396; in view of Miller et al. 2023/0037733; in further view of Andersh et al. 2003/0100972; in view of Ruiz et al. 2024/0047052.
18/304,710 – Claim 4. Odibat et al. 2024/0273396 further teaches The method of claim 1, wherein the smoothing algorithm takes an weighted average of the output value from the first AI model and the output value from the second AI model to generate the combined output value (Odibat et al. 2024/0273396 [0087 – AI models] In embodiments, a framework for multi-tenant MLOps, where each tenant is provided their own customized version of the operational ML model is discussed herein. A model version for a specific project is dynamically selected using an artificial intelligence-based (AI-based) machine learning model operations (MLOps). The MLOps AI-based model is dynamically tuned over time based on service level agreements (SLA), resource constraints, and cost using a new AI model. The model refresh for tenants is triggered based on tenant usage, cost thresholds, and tenant profile along with other approaches, such as data and target drifts. The number of operational ML models needed may depend on similarity across tenants rather than number of tenants. For example, N similar tenants may utilize one operational ML model. [0097] In an embodiment, service level agreement (SLA) 1011 may include time constraints in units of seconds. Resource constraints may include data for scalability, regulatory, maintainability, serviceability, security, and cost. Cost data may contain AssetId, asset type, unit cost, total cost, region, data center, period, and description. Outputs of the deep learning neural network 1021 include a model performance threshold 1030 and model refresh frequency 1040. Two different loss functions may be used to learn the outputs. As discussed above, softmax is used to determine the model refresh frequency 1040, and linear regression is used to identify the model performance threshold 1030. In particular, softmax is a generalization of the logistic function to multiple dimensions, and used in multinomial logistic regression, and may be used to normalize output of the neural network 1021. The deep learning neural network uses a Leaky Rectified Linear Unit (Leaky ReLU) function across the hidden layers. Leaky ReLU is a type of activation function based on a ReLU, but it has a small slope for negative values instead of a flat slope. The slope coefficient may be determined before training, i.e., the slope coefficient may not be learned during training. Input is passed to deep hidden layers where weights have been shared among each other for both outputs. After backpropagation and forward propagation models are used to reduce the loss and return the model refresh frequency 1040 and model performance threshold 1030 for the tenant.).
Odibat et al. 2024/0273396 may not expressly disclose the “weighted average” features, however, Ruiz et al. 2024/0047052 teaches (Ruiz et al. 2024/0047052 [0075 - forecasting machine learning models include autoregressive models that use past observations of a target variable as an input to predict future values (e.g., ARIMA (AutoRegressive Integrated Moving Average)); seasonal autoregressive integrated moving-average (SARIMA) models extend ARIMA by considering seasonal patterns in addition to the regular autoregressive, integrated, and moving average components; exponential smoothing models that use weighted averages…] The present invention can employ one or more machine learning models, such as a forecasting model. The forecasting models can be employed to address or handle different types of forecasting tasks. Some of the main types of forecasting machine learning models include autoregressive models that use past observations of a target variable as an input to predict future values (e.g., ARIMA (AutoRegressive Integrated Moving Average)); seasonal autoregressive integrated moving-average (SARIMA) models extend ARIMA by considering seasonal patterns in addition to the regular autoregressive, integrated, and moving average components; exponential smoothing models that use weighted averages of past observations to predict future values and are useful for time series data with no clear trend or seasonality (e.g., Simple Exponential Smoothing, Double Exponential Smoothing (Holt's method), and Triple Exponential Smoothing (Holt-Winters' method)); long short-term memory (LSTM) networks which is a type of recurrent neural network (RNN) capable of learning long-term dependencies in time series data and are particularly effective for processing sequential data with complex temporal patterns; gradient boosting machines (GBM) which is an ensemble learning technique that builds multiple decision trees to make predictions (e.g., XGBoost and LightGBM for time series forecasting); prophet or Facebook Prophet incorporates time series components such as seasonality and holidays and can effectively handle missing data and outliers; neural prophet is an extension of the Facebook Prophet model that utilizes neural networks to capture complex temporal patterns and relationships in the data; DeepAR which is a probabilistic forecasting model based on recurrent neural networks that can handle uncertainty in time series data; VAR (Vector Autoregression) models which can be used for multivariate time series forecasting, where multiple related variables are forecasted simultaneously; and CNN (Convolutional Neural Networks) for Time Series models which can be adapted for time series forecasting, especially when dealing with 1D sequences. The choice or selection of the proper forecasting model depends on the specific characteristics of the time series data, the presence of trends and seasonality, the amount of data available, and the desired level of interpretability and complexity.).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Odibat et al. 2024/0273396 to include the features as taught by Ruiz et al. 2024/0047052. One of ordinary skill in the art would have been motivated to do so to implement well known tools and features useful in AI feature lifecycle management through AI model updates which should prove to improve user experience, maximize profits, and optimize revenue.
18/304,710 – Claim 14. The data processing system of claim 11, wherein the smoothing algorithm takes an weighted average of the output value from the first AI model and the output value from the second AI model to generate the combined output value.
Claim 14, has similar limitations as of Claim(s) 4, therefore it is REJECTED under the same rationale as Claim(s) 4.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over: Odibat et al. 2024/0273396; in view of Miller et al. 2023/0037733; in further view of Andersh et al. 2003/0100972; in view of XU et al. 2021/0201128.
18/304,710 – Claim 10. Odibat et al. 2024/0273396 further teaches The method of claim 1, wherein the output value displayed by the cloud environment to each of the plurality of tenant applications is a prediction score representing a probability that a task is to be successfully closed (Odibat et al. 2024/0273396 [0020 - prediction] In embodiments, an operation or MLOps framework is established that can store models and model versions with the following details: target, prediction, accuracy, tenant/overall champions, categoric features list, numeric features list, etc. The tenant metadata, e.g., profiles and usage history, may be stored. The MLOps framework orchestrates the deployment of models using an AI Model dynamic model selector (DMS) to pick the best base model. [0084 - predictive model] FIG. 8 illustrates a hybrid flow diagram and block diagram 800 depicting a method for managing Model Ops (MLOps), in accordance with aspects of the invention. Typically, a model deployed for client use has a base version. In embodiments, to automatically trigger model refresh, the operational ML models in use by tenants are monitored. In model monitoring, the predictive model performance needs to be regularly monitored to invoke a new iteration in the ML process. Data drift and concept drift also need to be monitored. An ML model may have dozens or hundreds of features or variables in the model. For example, a supervised model may have 70-80 or more variables. Data drift is the change in distribution for each feature over time. Concept drift is change in model performance due to changes in the underlying concept of the business. For example, a mortgage loan business may expand their region and change their approval algorithms. These changes might increase their use of the cloud, for instance for customer service or application interfaces. Thus, if the tenant adds a new region to their business, the model concept may drift and require a refresh. Once a drift is detected, a model refresh may be automatically triggered. By automatically triggering a model refresh, unnecessary delay may be avoided. For example, unnecessary delay in known systems may include waiting for the data scientists to become involved in the monitor/refresh cycle. A model may be refreshed based on certain metrics and pre-defined guidelines in order to keep it relevant and accurate. Providing accurate and relevant models may involve model validation. Refreshed models may need to be verified that they are fit for deployment. In order to verify refreshed models, the model's predictive performance is tested against a specific baseline model. This process for model verification may be more challenging in a multi-tenant environment where each tenant has unique business models, requirements, and desired outcomes from the models. [0099 - probabilities] The model management 1020 considers the tenant type and tenant resources, e.g., bronze, sliver, gold, or entry, standard, enterprise, etc., so that the trained deep learning model 1021 is able to execute on the data 1010 of the tenant successfully within the resource constraints 1015, cost 1013 and performance 1011 constraints for the tenant. In an example, the deep learning 1021 is a neural network that may use a softmax function 1022 to assign decimal probabilities to each class in a multi-class problem. Softmax function 1022 may be used to determine a best model refresh frequency. Linear regression 1024 may be used to identify a best model performance threshold. Linear regression may be a supervised learning technique that involves learning the relationship between the features and the target. Alternatively, other algorithms and techniques may be used with the neural network 1021 to help determine model refresh frequency and model performance or accuracy thresholds.).
Odibat et al. 2024/0273396 may not expressly disclose the “prediction scoring” features, however, XU et al. 2021/0201128 teaches (XU et al. 2021/0201128 [0022 - a scoring system can predict the probability that a task can be closed or not based on historical data and the current status of the task] According to another embodiment, a scoring system can predict the probability that a task can be closed or not based on historical data and the current status of the task. The scoring system is highly configurable and can incorporate data from a variety of data sources, and can easily be extended to other machine learning tasks by changing a number of modules/configuration in the scoring system. The scoring system can use real-time data from a task database system, and therefore can provide accurate, timely prediction results to users. An explanation for each prediction score can be generated to help users identify reasons for high/low scores, so that the users can take immediate actions accordingly. Feature importance information for all tasks can be collected and provided to users to help them understand fields that are deterministic. [0066 - prediction scores] In one embodiment, the ML pipeline can be used to generate a number of types of prediction scores, including time-agnostic scores, scores by end of time period (ETP), and scores by a close date. A time-agnostic score, which is not tied to any specific time, measures the probability that a task can be closed as a won deal without considering the close date. A score by ETP measures the probability that a task can be closed by the end of a particular period (e.g., a quarter or a year). A score by a close date measures the probability that a task can be close by a specified close date. Depending on the type of score that the ML pipeline is configured to generate, different set of features can be used to train an ML model.).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Odibat et al. 2024/0273396 to include the features as taught by XU et al. 2021/0201128. One of ordinary skill in the art would have been motivated to do so to implement well known tools and features useful in AI feature lifecycle management through AI model updates which should prove to improve user experience, maximize profits, and optimize revenue.
No Prior-art Rejection / Potentially Allowable
Claims 5-9 and 15-19 cannot be rejected with prior-art. Individual claimed features are taught in the prior-art, however, the unique combination of features and elements are not taught by the prior-art without hindsight reasoning. These claims are further rejected to as being dependent upon a rejected base claim but might possibly be allowable if rewritten in independent form including all the limitations of the base claim and any intervening claims.
18/304,710 – Claim 5. The method of claim 4, wherein an weight of the output value of the first AI model gradually decreases from a start of the rollout window to and an end of the rollout window, and an weight of the output value of the second AI model proportionally decreases ().
18/304,710 – Claim 6. The method of claim 5, wherein the weight of the output value of the first AI model is 100% and the weight of the output value of the second AI model is 0 at the start of the rollout window.
18/304,710 – Claim 7. The method of claim 5, wherein the weight of the output value of the first AI model is 0 and the weight of the output value of the second AI model is 100% at the end of the rollout window.
18/304,710 – Claim 8. The method of claim 4, wherein the output value displayed to each of the plurality of tenant applications is accompanied by a plurality of explanatory factors.
18/304,710 – Claim 9. The method of claim 8, wherein when the output value is the combined output value of the first AI model and the second AI model, the plurality of explanatory factors include more explanatory factors from one of the first AI model or the second AI model with a greater weight given in generating the combined output value.
18/304,710 – Claim 15. The data processing system of claim 14, wherein an weight of the output value of the first AI model gradually decreases from a start of the rollout window to and an end of the rollout window, and an weight of the output value of the second AI model proportionally decreases.
18/304,710 – Claim 16. The data processing system of claim 15, wherein the weight of the output value of the first AI model is 100% and the weight of the output value of the second AI model is 0 at the start of the rollout window.
18/304,710 – Claim 17. The data processing system of claim 15, wherein the weight of the output value of the first AI model is 0 and the weight of the output value of the second AI model is 100% at the end of the rollout window.
18/304,710 – Claim 18. The data processing system of claim 14, wherein the output value displayed to each of the plurality of tenant applications is accompanied by a plurality of explanatory factors.
18/304,710 – Claim 19. The data processing system of claim 18, wherein when the output value is the combined output value of the first AI model and the second AI model, the plurality of explanatory factors include more explanatory factors from one of the first AI model or the second AI model with a greater weight given in generating the combined output value.
Prosecution Insights