Prosecution Insights
Last updated: April 19, 2026
Application No. 18/459,235

System and Method Of Annotating Data Models Allowing The Factoring In Or Out Of Recurring Events To Improve The Outcome Of Predictive Systems

Non-Final OA §101§103
Filed
Aug 31, 2023
Examiner
ANYA, CHARLES E
Art Unit
2194
Tech Center
2100 — Computer Architecture & Software
Assignee
Tangoe US Inc.
OA Round
1 (Non-Final)
82%
Grant Probability
Favorable
1-2
OA Rounds
3y 2m
To Grant
99%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allow Rate
727 granted / 891 resolved
+26.6% vs TC avg
Strong +34% interview lift
Without
With
+33.5%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
41 currently pending
Career history
932
Total Applications
across all art units

Statute-Specific Performance

§101
11.2%
-28.8% vs TC avg
§103
61.1%
+21.1% vs TC avg
§102
6.8%
-33.2% vs TC avg
§112
10.4%
-29.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 891 resolved cases

Office Action

§101 §103
DETAILED ACTION Claims 1-20 are pending in this application. Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claim Objections Claims 1-20 are objected to because of the following informalities: An “and” is missing from claims 1, 9 and 17. Specifically, an “and” required by just before the last claim limitation . Appropriate correction is required. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore, subject to the conditions and requirements of this title. Claims 1-8 and 17-20 are directed to non-statutory subject matter. Claims 1 and 17 are directed to a “system”. The “system” comprises a software. The “software” as disclosed on paragraph 0114 (Software 1003) does not include a hardware. As software therefore, “system” is interpreted as software per se. Claims 2-7 and 18-20 are rejected for the same reason as claims 1 and 17 above. Appropriate corrected is required. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1, 6, 9, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. As to claim 1, Orhan teaches a system for monitoring hosted computing resource usage by applications comprising: Software (Monitoring Service 130) executing on a computer, the software receiving usage information of a software application (Applications 155/156) executing on at least one of a plurality of computing resources, the usage information indicative of usage of the at least one of the plurality of computing resources by the software application (“…In order to help manage their applications 155 and 156, application owners or administrators may request the collection and reporting of various types of metrics via programmatic interfaces of monitoring service 130 in the depicted embodiment. Such clients of the monitoring service 130 may, for example, define application-specific custom metrics and statistics to be collected for such metrics, or select pre-defined metrics (defined for example by each of the services used for their applications) and pre-defined statistics to be collected on their behalf. Monitored metrics metadata 132 may comprise records indicating such metrics, including such properties of the metrics as the frequency with which raw values are to be collected, the kinds of statistics to be computed, anomaly detection specifications for at least some of the metrics, and so on. Monitored metrics values 133 may actual raw values of the metrics obtained/collected over time, and/or values of the statistics computed from the raw values. The monitoring service may also include metrics collection and analysis managers 126B in some embodiments, responsible for acquiring and analyzing the metrics values 133….The monitoring service 130 may allow its clients to provide anomaly specifications defining for example, acceptable ranges of raw values of various metrics, the rules to be used to designate some set of metrics values as anomalous (e.g., whether a single out-of-acceptable-range value constitutes an anomaly, or whether multiple successive out-of-acceptable-range values have to be obtained before a report of an anomaly is to be generated, and so on). Such manual specification of anomalies may be quite time consuming, and may also require considerable expertise on the part of the application administrators/owners or other clients…” paragraphs 0028/0029); said software identifying usage variations based on the usage information and determining one or more anomalies in usage based on variation of usage compared to a threshold (anomalies definition/specification) (“…One or more definitions 513 of anomalous states may be indicated as part of an anomaly specification in the depicted embodiment. Each anomalous state may be defined using a comparison predicate 514 (e.g., 514A or 514B) and a corresponding threshold (e.g., 515A or 515B). For example, for a given statistic S1, one anomalous state may be defined as “greater than Value1” (with “greater than” representing the comparison predicate, and “Value1” the threshold), while a second anomalous state may be defined as “less than Value2”. In such a scenario, if S1 exceeds Value1 or is less than Value2, an anomalous state occurrence may be recorded by the analytics service or the monitoring service responsible for detecting anomalies…” paragraph 0051); wherein the one or more anomalies are each tagged based on one or more event designators (out-of-acceptable-range value) ( “…The monitoring service 130 may allow its clients to provide anomaly specifications defining for example, acceptable ranges of raw values of various metrics, the rules to be used to designate some set of metrics values as anomalous (e.g., whether a single out-of-acceptable-range value constitutes an anomaly, or whether multiple successive out-of-acceptable-range values have to be obtained before a report of an anomaly is to be generated, and so on). Such manual specification of anomalies may be quite time consuming, and may also require considerable expertise on the part of the application administrators/owners or other clients…” paragraph 0029). Orhan is silent with reference to said software accessing one or more external sources to identify an occurrence of an event associated with a predicted future anomaly in usage of the at least one of the plurality of computing resources and based on the event compared to at least one of the one or more event designators and said software modifying availability of computing resources for execution of the software application. Martin teaches said software accessing one or more external sources (Analysis Platform 360) to identify an occurrence of an event (surges (e.g., an increase in resource usage) associated with a predicted future anomaly in usage of the at least one of the plurality of computing resources and based on the event compared to at least one of the one or more event designators (“…As shown, a usage forecaster 385 may be communicatively coupled to the analysis core 376 via a communication link 387. The usage forecaster 385 may estimate future usage for a respective user (e.g., that owns or controls one or more accounts 350), a respective account 350, and/or a respective resource consuming user 352. The usage forecaster 385 may use, for example, the normal average usage pattern 392, the peak average usage pattern 394, and/or the trough average usage pattern 395 to forecast a future usage. Additionally, or alternatively, the usage forecaster 385 may analyze historical resource usage utilizing machine learning to forecast a future usage. For example, the usage forecaster 385 may analyze the usage for patterns and/or surges (e.g., an increase in resource usage). Once the future usage is forecasted, the usage forecaster 385 may also estimate a forecasted economic cost that corresponds to the forecasted usage…” Col. 24 Ln. 13-29), said software (Analysis User Interface 389) modifying availability of computing resources for execution of the software application (“…As shown, an analysis user interface 389 may communicate with the analysis core 376 via a communication link 391. The analysis user interface 389 may be configured to generate a display that presents information relating to the analysis platform 360 and/or the metric/attribute collector 302. For example, the analysis user interface 389 may be configured to display a usage forecast, the normal average usage pattern 392 (e.g., as a graph or plot), the peak average usage pattern 394 (e.g., as a graph or plot), the trough average usage pattern 395 (e.g., as a graph or plot), current contract terms, current subscriptions, active and/or inactive notifications/alerts, and/or any other data regarding the analysis platform 360. In some cases, the analysis user interface 389 may be configured to allow a user to modify various features of the analysis platform 360. For example, the analysis user interface 389 may be configured such that a user can change and/or cancel one or more subscriptions, change and/or cancel one or more contracts, change, add, and/or remove notification thresholds and/or analysis automator 384 triggers, and/or change any other feature of the analysis platform 360…As shown, the analysis user interface 389 may be remote from the analysis platform 360 (e.g., operating on a different server, in a different network, and/or on a different device). However, in some cases, the analysis user interface 389 may be local to the analysis platform 360 (e.g., operating on the same server, on the same network, and/or on the same device). Data transmitted over the communication link 391 may be encrypted to prevent unauthorized access to the data…” Col. 24 Ln. 30-58). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan with the teaching of Martin because the teaching of Martin would improve the system of Orhan by providing a technique for allowing a user to modify various features of the analysis platform 360, for example, a user can change and/or cancel one or more subscriptions, change and/or cancel one or more contracts, change, add, and/or remove notification thresholds and/or analysis automator triggers, and/or change any other feature of the analysis platform (Martin Col. 24 Ln. 30-58). As to claim 6, Orhan teaches the system of claim 1 wherein the one or more external sources includes the software application (Applications 155/156). As to claims 9 and 17, see the rejection of claim 1 above. As to claim 11, see the rejection of claim 1 above. Claims 2, 3, 14, 15, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. as applied to claims 1, 9 and 17 above, and further in view of U.S. Pat. No. 8,781,977 B1 issued to Huberman et al. As to claim 2, Orhan as modified by Martin teaches the system of claim 1 however it is silent with reference to wherein the software application is associated with a first hosting plan which relates use of the computing resources to a cost of executing said software application on the at least one of the plurality of computing resources and further comprising; a cost limitation associated with the software application such that the cost limitation limits an amount of modification of availability of computing resources as compared to the cost limitation. Huberman teaches wherein the software application is associated with a first hosting plan which relates use of the computing resources to a cost of executing said software application on the at least one of the plurality of computing resources (pricing model that parameterizes what services should cost the customer) and further comprising; a cost limitation associated with the software application such that the cost limitation limits an amount of modification of availability of computing resources as compared to the cost limitation (Pricing Algorithm 28/Churn Module 28A) (“…Embodiments of the present invention relate to a pricing model that parameterizes what services should cost the customer based on a desired profit margin for the resource provider. To account for changing usage patterns, an SOS in accordance with embodiments of the present invention can change prices to maintain a predictable and consistent profit margin. This includes determining swing option prices and usage fees in accordance with some embodiments of the present invention. For example, the SOS architecture 10 is adapted to change resource usage prices to maintain a predictable profit margin as set by the resource provider 14 in the cost-profit-risk database 24. Specifically, the pricing algorithm 28 performs a cross-validation simulation study using historical data from the historical usage database 26 and data from the cost-profit-risk database 24 to set an appropriate price for services. The historical usage database 26 includes the resource provider's database of previous customers' usage and charges…” Col. 4 Ln. 1-18, Col. 6 Ln. 12-34). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan and Martin with the teaching of Huberman because the teaching of Huberman would improve the system of Orhan and Martin by providing a pricing algorithm for set an appropriate price for services (Huberman …” Col. 4 Ln. 1-18). As to claim 3, Orhan as modified by Martin teaches the system of claim 2 however it is silent with reference to revenue information accessible by said software, the revenue information indicative of revenue associated with the software application and wherein the cost limitation adjusts based on the revenue information. Huberman teaches revenue information accessible by said software, the revenue information indicative of revenue associated with the software application and wherein the cost limitation adjusts based on the revenue information (“…In one embodiment of the present invention, SOS revenue includes four components as set forth below: revenue=average usage+swing options+penalties+churn. (Equation 2)…” Col. 6 Ln. 12-34). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan and Martin with the teaching of Huberman because the teaching of Huberman would improve the system of Orhan and Martin by providing a pricing algorithm for set an appropriate price for services (Huberman …” Col. 4 Ln. 1-18). As to claims 14 and 18, see the rejection of claim 2 above. As to claims 15 and 19, see the rejection of claim 3 above. Claims 4 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. and further in view of U.S. Pat. No. 8,781,977 B1 issued to Huberman et al. as applied to claims 2 and 19 above, and further in view of WO 2011066807 A1 to Chen. As to claim 4, Orhan as modified by Martin and Huberman teaches the system of claim 3 however it is silent with reference to wherein the cost limitation is determined based on a ratio determined from usage information relative to the revenue information. Chen teaches wherein the cost limitation is determined based on a ratio determined from usage information relative to the revenue information (revenue ratio of the resource usage object) (“…The system according to claim 19, wherein the system further comprises: a charging device, wherein the charging device is configured to send a revenue ratio of the resource usage object to the operator to the operation Pricing device, and charging adjustment based on pricing information returned by the operator pricing device;…The operator pricing device is configured to price a resource usage object according to the revenue ratio, and send the obtained pricing information to the charging device and the centralized controller…”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan, Martin and Huberman with the teaching of Chen because the teaching of Chen would improve the system of Orhan, Martin and Huberman by providing a pricing device for charging adjustment based on pricing information. As to claim 20, see the rejection of claim 4 above. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2018/0314835 A1 to Dodson et al. As to claim 5, Orhan as modified by Martin teaches the system of claim 1 however it does not explicitly teach a user interface provided by said software application allowing user access to tag the one or more anomalies. Dodson teaches a user interface (user) provided by said software application allowing user access to tag (flagged) the one or more anomalies (anomalous) (“…In some embodiments, using unsupervised machine learning, the exemplary system 105 can evaluate the data instances over time to detect anomalous behavior. In general, anomalous behavior can include any deviation in the data instances as viewed over time. For example, if the data instances are collected for a network such as a cloud, changes in resource utilization of a service within the cloud can be identified as anomalous. In another example, a brief spike in file transfer rates between a computing device and another computing device (possibly in a foreign country) can be flagged as anomalous. The present disclosure is not intended to be limited to unsupervised machine learning and in some embodiments can incorporate other machine learning methods. In one embodiment, user feedback can be incorporated into an anomaly score via supervised machine learning techniques, or at least partially supervised or a mixture that is based on how unusual the deviation/anomaly is relative to models of historical behavior of the system 105, as well as how it compares to other anomaly instances that have been indicated as important…After the input stream is received, the example method 200 includes a step 210 of generating anomaly scores for each of the data instances over continuous time intervals. That is, the data instances may be scored in a chronological manner such that anomaly scores along the timeline are calculated. The example method 200 then includes a step 215 of detecting a change in the anomaly scores over the continuous time intervals for the data instances. Stated otherwise, the example method 200 examines the scores calculated for the buckets of data instances (as described above) and locates variances in the scores that are indicative of an anomaly. In some embodiments, the user can specify how much scores can deviate over time before the deviations are flagged as an anomaly. For example, if the principle value is network traffic volume, and the network traffic volume rates change only slightly (e.g., +/−5%), these discrepancies in network traffic volume are not anomalous, whereas a change of more than 10% may be flagged as anomalous…” paragraphs 0020/0053). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan and Martin with the teaching of Dodson because the teaching of Dodson would improve the system of Orhan and Martin by providing a technique for allowing a user to control and manage resource allocation and usage. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2009/0187606 A1 to Allweil et al. As to claim 8, Orhan as modified by Martin teaches the system of claim 1 however it is silent with reference to wherein the inclusion of the at least one of the one or more anomalies in the adjusted usage increases availability of computing resources. Allweil teaches wherein the inclusion of the at least one of the one or more anomalies in the adjusted usage increases availability of computing resources (Analysis Component 530) (“…Storage 540 may store additional more complex rules to be used by analysis component 530 to determine whether a modification of database 510 is necessary. For example, a rule may include combination of different resource usages such as `if the hard disk usage is greater than 90% for more than 1 hour OR if the CPU load is greater than 95% for more than 30 minutes`…Once analysis component 530 has determined that a modification is required, the modification is carried out by modification component 532 by for example adding node 518 to database 510 in the time window determined by analysis component 530…The modification may be carried out automatically without user intervention, or alternatively, a user may receive a notification or a prompt to carry out the modification through user interface 522…” paragraphs 0035-0037). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan and Martin with the teaching of Allweil because the teaching of Allweil would improve the system of Orhan and Martin by providing a analysis component for controlling when to modification of resource usage is needed. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. as applied to claim 9 above, and further in view of U.S. Pub. No. 2006/0136761 A1 to Frasier et al. As to claim 10, Orhan as modified by Martin teaches the teaches the method of claim 9 however it is silent with reference to wherein said software modifies availability of computing resources by sending an instruction to a host provider associated with the at least one of the plurality of computing resources. Fraiser teaches wherein said software modifies availability of computing resources by sending an instruction ("resource adjustment message") to a host provider (Server 12) associated with the at least one of the plurality of computing resources (“…In one embodiment of the present invention, computer 14 can send the resource allocation or de allocation message ("resource adjustment message") directly to server 12. In another embodiment of the present invention, computer 14 directs its resource adjustment message to a management console 62 for server 61. After authenticating computer 14, management console 62 forwards the resource adjustment message to program 84. In some cases, as described below, program 87 cannot automatically adjust the resource allocation in server 12 or the subject LPAR. In such cases, messages are sent to a remote computer center 63 or systems administrators to determine other remedies, such as transferring one or more applications from one server or LPAR to another… If the resource allocation can be performed automatically by program 87 within server 12 (decision 64, yes branch), program 73 addresses the resource adjustment message to the proper destination to activate program 87, i.e. server 12 or management console 62 (step 90). (In the case of the management console 62 receiving the resource adjustment message, the management console, after recording the proposed resource adjustment and ensuring that it originated from an authorized source, forwards the resource adjustment message to server 12.) In some cases it is not possible or practical for program 87 to adjust the resource allocation in server 12, for example, if the server 12 or subject LPAR cannot physically accommodate an additional allocation or a de allocation, or if there are no additional resources to allocate (decision 64, no branch). In such a case, the rules engine will send the resource adjustment message or a description of the resource constraint or excess to a remote computer center 63 (decision 70, yes branch). This will notify an administrator 79 to consider transferring an application to or from server 12 or the subject LPAR to balance resource utilization. This is a remedy when the program 87 in server 12 cannot make the required allocation or de allocation…” paragraphs 0020/0023). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan and Martin with the teaching of Fraiser because the teaching of Fraiser would improve the system of Orhan and Martin by providing a server for remedies to resource usage anomalies. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. as applied to claim 11 above, and further in view of U.S. Pub. No. 2021/0373987 A1 to Raghavendra et al. As to claim 12, Orhan as modified by Martin teaches the method of claim 11 however it is silent with reference to wherein the one or more event designators are compared to the event to determine a correlation between the event and the one or more event designators such that a size of the predicted future anomaly is predicted. Raghavendra teaches wherein the one or more event designators are compared (Matching Unit 104) to the event to determine a correlation between the event (actual time series data) and the one or more event designators (forecasted time series data) such that a size of the predicted future anomaly is predicted (the matching unit 104 calculates a degree of variation between the deviation and the forecasted time series data. Whether a deviation constitutes an actual anomaly is based in part on the degree of the deviation from forecasted time series data/score describes a magnitude of a deviation from the forecasted time series data) (“…In embodiments of the invention, the system 100 is configured to monitor a computing system 108. Periodically, the system 100 can receive an error message from the computing system 108 suggesting an error has occurred in the computing system 108. In response to the error message, the matching unit 104 is configured to analyze data collected from the monitored computing system 108 and determine a presence of an anomaly and a root cause of an error. The matching unit 104 compares forecasted time series data for and actual time series data from each unit of the computing system 108. The matching unit 104 searches for deviations between the forecasted time series data and the collected time series data. Once a deviation is detected, the matching unit 104 calculates a degree of variation between the deviation and the forecasted time series data. Whether a deviation constitutes an actual anomaly is based in part on the degree of the deviation from forecasted time series data. Once a potential anomaly is identified as an actual anomaly, the matching unit 104 performs a causal analysis to determine the root cause of the anomaly…The matching unit 104 determines a root cause in connection with a hierarchical representation 200 (shown in FIG. 2) of the computing system 108. Using the hierarchical representation 200, which is stored in the system hierarchy unit 102, the matching unit 104 generates an anomaly vector describing a unit of the hierarchical representation 200 that is causing the anomaly. The anomaly vector describes an anomalous node. The anomaly vector quantifies each anomaly that has been detected as a result of the univariate anomaly detection and aggregation over the hierarchical representation 200. For example, if the matching unit 104 detects anomalies of CPU usage and bytes read at a node, the anomaly vector would contain include anomaly weights for each of these dimensions. The hierarchical representation 200 is a data structure that describes each unit of the computing system 108 and also describes relationships between the various units. The matching unit 104 calculates a score at each unit of the hierarchical representation 200. The score describes a magnitude of a deviation from the forecasted time series data. The scores are used to determine a root cause of the anomaly. Once the root cause is identified, the matching unit 104 further uses the score to generate an anomaly vector describing the location of the root cause and a severity of the problem…” paragraphs 0019/0020). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan and Martin with the teaching of Raghavendra because the teaching of Raghavendra would improve the system of Orhan and Martin by providing a technique for determining the root cause of the anomaly and solution. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. in view of in view of U.S. Pat. No. 10,719,364 B2 issued to Martin et al. and further in view of U.S. Pub. No. 2021/0373987 A1 to Raghavendra et al. as applied to claim 12 above, and further in view of U.S. Pat. No. 11,836,578 B2 issued to Qiu et al. As to claim 13, Orhan as modified by Martin and Raghavendra teaches the method of claim 12 however it is silent with reference to wherein the size of the predicted future anomaly determines how said software modifies availability of computing resources. Qiu teaches wherein the size of the predicted future anomaly (final anomaly score) determines how said software modifies availability of computing resources (“…In some implementations, the one or more actions may include the anomaly detection platform generating an alarm when the final anomaly score satisfies a threshold during a time period, when resource usage deviates from a predicted usage by a threshold amount, and/or the like. For example, the anomaly detection platform may activate a light, may output a sound via a speaker of a client device, may configure an account to display a message when a user is logged into the account, and/or the like. This may prevent underutilization or overutilization of the resource…In some implementations, the one or more actions may include the anomaly detection platform generating a recommendation to modify allocation of a resource for an organization based on the final anomaly score. For example, the anomaly detection platform may generate a recommendation based on an amount by which an actual usage deviates from an expected usage, and may provide information for display, in a message to a client device, and/or the like, that identifies the recommendation. In this way, the anomaly detection platform may provide the recommendation to individuals responsible for managing resource usage, and the individuals may address the anomaly and conserve resources in the future…” Col. 10 Ln 1-17). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Orhan, Martin and Raghavendra with the teaching of Qiu because the teaching of Qiu would improve the system of Orhan, Martin and Raghavendra by providing a anomaly detection platform for generating a recommendation to modify allocation of a resource based on a final anomaly score (Qiu Col. 10 Ln 1-17). Allowable Subject Matter Claim 7 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Reasons for Allowance The following is an examiner’s statement of reasons for allowance: The closest prior art of records, (U.S. No. 2024/0028830 A1 (also 11,748,568 B1) to Orhan et al. and U.S. Pat. No. 10,719,364 B2 issued to Martin et al.), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claim 7) of “…wherein a baseline usage for the software application is determined by excluding at least one of the one or more anomalies and based on the predicted occurrence of the predicted future anomaly, availability of computing resources is modified for a period of time for an adjusted usage which includes the baseline usage and the at least one of the one or more anomalies…”, when taken in the context of claims as a whole. 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 The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Pub. No. 2019/0042353 A1 to Ahad and directed to anomaly detection and resolution system (ADRS) is disclosed for automatically detecting and resolving anomalies in computing environments. U.S. Pub. No. 2021/0288983 A1 to Tamuluri et al. and directed to Machine Learning Based Anomaly Detection and Response. U.S. Pat. No. 9,400,731 B1 issued to Preece and directed to forecasting server behavior. U.S. Pub. No. 2021/0286699 A1 to Jha et al. and directed to automated selection of performance monitors. U.S. Pub. No. 2005/0120111 A1 to Bailey et al. and directed to a computer system that is able to analyze resource utilization data for components of the computer system. U,S. No. 12,452,272 B2 issued to Subramanian et al. and directed to a method for reducing resource consumption spikes in an anomaly detection framework. U.S. Pub. No. 2009/0037922 A1 to Herington et al. and directed to a workload management controller that detects and tracks resource consumption volatility patterns and automatically and dynamically adjusts resource headroom according to the volatility patterns. U.S. Pat. No. 10,031,785 B2 issued to Gonzalez et al. and directed to a method for predictive computing resource allocation in a distributed environment. U.S. Pub. No. 2014/0082614 A1 to Klein et al. and directed to a method of computing resource utilization including automatically determining resource usage and operating metric profiles for consumers of computing resources based on an analysis of actual resource usage measurements and other operating metrics. U.S. Pat. No. 9,497,136 B1 issued to Rananao et al. and directed to a management console application provides a dashboard which centralizes data from and access to one or more other applications. U.S. Pub. No. 11,799,889 B2 issued to Das et al. and directed to techniques for detecting and preventing web service usage anomalies, including forecasting, based on a model, a number of resource instances for one or more web services for a time period. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KEVIN YOUNG can be reached at 571-270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /CHARLES E ANYA/Primary Examiner, Art Unit 2194
Read full office action

Prosecution Timeline

Aug 31, 2023
Application Filed
Jan 02, 2026
Non-Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591471
KNOWLEDGE GRAPH REPRESENTATION OF CHANGES BETWEEN DIFFERENT VERSIONS OF APPLICATION PROGRAMMING INTERFACES
2y 5m to grant Granted Mar 31, 2026
Patent 12591455
PARAMETER-BASED ADAPTIVE SCHEDULING OF JOBS
2y 5m to grant Granted Mar 31, 2026
Patent 12585510
METHOD AND SYSTEM FOR AUTOMATED EVENT MANAGEMENT
2y 5m to grant Granted Mar 24, 2026
Patent 12579014
METHOD AND A SYSTEM FOR PROCESSING USER EVENTS
2y 5m to grant Granted Mar 17, 2026
Patent 12572393
CONTAINER CROSS-CLUSTER CAPACITY SCALING
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
82%
Grant Probability
99%
With Interview (+33.5%)
3y 2m
Median Time to Grant
Low
PTA Risk
Based on 891 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month