Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-20 are pending.
Response to Arguments
Applicant's arguments with respect to the prior art rejection of the claims have been considered but are moot in view of the new grounds of rejection, particularly the application of the Uriel reference. The 35 USC 103 rejections of claims 7-10 and 17-20 have been withdrawn in view of the amendments and remarks.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-6 and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Tuffs (US Pub. No. 2023/0145807) in view of Uriel (US Pub. No. 2016/0285783).
As to claim 1, Tuffs discloses a dynamic monitoring system comprising: a memory configured to load dynamic monitoring program; one or more processors configured to execute the dynamic monitoring program; and a network interface configured to receive metric data from a monitoring target resource, wherein the dynamic monitoring program is configured to, when executed by the one or more processors (Fig. 1 and Abstract), cause the dynamic monitoring system to perform operations comprising:
obtaining a first representative value and a first standard deviation of the metric data measured at a first plurality of measurement times belonging to a first time window (Fig. 1 and [0037], particularly, “At block 401, a cloud monitoring system generates statistics for metric data within a current accumulation time window. Based on detecting the emit trigger, the cloud monitoring system generates statistical indicators of distribution or dispersion of the accumulated metric data. Examples of the statistical indicators include mean and standard deviation.”);
obtaining a second representative value and a second standard deviation of the metric data measured at a second plurality of measurement times belonging to a second time window subsequent to the first time window (Fig. 1 and [0037], particularly, “At block 401, a cloud monitoring system generates statistics for metric data within a current accumulation time window. Based on detecting the emit trigger, the cloud monitoring system generates statistical indicators of distribution or dispersion of the accumulated metric data. Examples of the statistical indicators include mean and standard deviation.” the system continually loops, see [0046], particularly, “Asynchronously, operational flow continues to block 401 to obtain a next set of tagged metric data.”);
increasing or decreasing a value of feedback for the monitoring target resource, using at least one of (i) a first comparison result between the first representative value and the second representative value or (ii) a second comparison result between the first standard deviation and the second standard deviation ([0033], particularly, “The sustain filter 305 sustains metrics to track when outliers for the metrics are detected. Single time-point outliers of a metric are converted/sustained into multi time-point values of the metric for possible use with other filters in determining significance. Cloud metrics previously having outlier values can be of interest for future outlier behavior and can be sustained using the sustain filter 305…In this embodiment, all cloud metrics filtered as outliers by the feedback control loop at stages B1-BN have their sustain value increase to the baseline (e.g., 5 iterations) so as to track behavior for the corresponding cloud metrics over time.”); and
adjusting a monitoring level for the monitoring target resource based on comparing the value of feedback ([0032]-[0033], particularly, “The upper value and lower value can be specified for either normalized or unnormalized metric values. For instance, a metric value such as CPU percent usage can have a hard cutoff (e.g., 90%) above which automatically corresponds to outlier behavior. The range filter 303 can be a lower value of 90% CPU usage that filters all CPU usage values below 90%. The standard deviation filter 307 filters metric values to be above a threshold number of standard deviations and below a threshold number of standard deviations (e.g., 2). The upper threshold and lower threshold number of standard deviations can be different…In this embodiment, all cloud metrics filtered as outliers by the feedback control loop at stages B1-BN have their sustain value increase to the baseline (e.g., 5 iterations) so as to track behavior for the corresponding cloud metrics over time.”).
However, Tuffs does not explicitly disclose adjusting the monitoring level for the monitoring target resource based on comparing the value of feedback to at least one threshold value, wherein the at least one threshold value for one monitoring level is different from at least one threshold value for at least one other monitoring level
adjusting a monitoring interval based on a corresponding change in the monitoring level.
But, Uriel discloses adjusting a monitoring level for a monitoring target resource based on comparing a value of feedback to at least one threshold value (Fig. 4, labels 305 (reading on “monitoring level”, 410 (reading on “feedback”), label 415 (reading on “threshold value”)), wherein the at least one threshold value for one monitoring level is different from at least one threshold value for at least one other monitoring level (Fig. 4, labels 430-485 and [0060]-[0062], particularly, “Using different thresholds enables control of the monitoring level and, accordingly, resources used by the monitoring operations. For example, a low threshold (e.g., 20% processor utilization) at a first monitoring level might cause the monitoring resource controller 130 to transition to a second monitoring level that utilizes a higher threshold (e.g., 50% processor utilization), and hold at the second monitoring level until (a) no failure conditions occur for a threshold period of time (causing the example monitoring resource controller 130 to revert to the first monitoring level), or (b) a failure condition occurs at the increased threshold (causing the example monitoring resource controller 130 to transition to a third monitoring level).”).
adjusting a monitoring interval based on a corresponding change in the monitoring level (Fig. 3, labels 305, 310 (testing frequency reading on “a monitoring interval”), 330-370 and [0052]-[0053], particularly, “The example testing threshold column 310 of the illustrated example of FIG. 3 identifies how often monitoring operations associated with the identified monitoring level (identified by the monitoring level column 305) should be executed. Indicating a low frequency (e.g., perform monitoring operations every five minutes, ten minutes, etc.) results in low resource utilization by the monitoring agent 105…The example safe state threshold column 315 of the illustrated example of FIG. 3 identifies how long all monitoring operations must return a passing result before the selected monitoring level will be decreased. In the illustrated example, the first example monitoring level zero (row 330) does not have a safe state threshold value because, for example, the first example monitoring level (row 330) represents the least processor intensive monitoring operations that will be performed.”).
Therefore it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Tuffs and Uriel in order to prevent and/or understand failure conditions in a computing environment (Uriel, [0002])
As to claim 11, it is rejected by a similar rationale by that set forth in claim 1’s rejection.
As to claims 2 and 12, the teachings of Tuffs and Uriel as combined for the same reasons set forth in claim 1’s rejection further disclose a number of measurement times of the first plurality of measurement times belonging to the first time window is greater than or equal to a number of measurement times of the second plurality of measurement times belonging to the second time window (Tuffs, Fig. 1 and [0037], particularly, “At block 401, a cloud monitoring system generates statistics for metric data within a current accumulation time window. Based on detecting the emit trigger, the cloud monitoring system generates statistical indicators of distribution or dispersion of the accumulated metric data. Examples of the statistical indicators include mean and standard deviation.” the system continually loops, see [0046], particularly, “Asynchronously, operational flow continues to block 401 to obtain a next set of tagged metric data.”).
As to claims 3 and 13, the teachings of Tuffs and Uriel as combined for the same reasons set forth in claim 1’s rejection further disclose a number of measurement times of the first plurality of measurement times belonging to the first time window is greater than a number of measurement times of the second plurality of measurement times belonging to the second time window (Uriel, Figs. 3, 4, and [0052]-[0053]).
As to claims 4 and 14, the teachings of Tuffs and Uriel as combined for the same reasons set forth in claim 1’s rejection further disclose based on an outlier occurrence frequency of the metric data for the monitoring target resource being less than a reference value, the number of measurement times of the first plurality of measurement times belonging to the first time window is greater than the number of measurement times of the second plurality of measurement times belonging to the second time window (Tuffs, [0020], particularly, “The cloud metric aggregator 151 can average or otherwise compute statistics (such as min/mean/max/standard-deviation) for metric values across time windows. For instance, the cloud metric aggregator 151 can average CPU utilization over 15-minute periods. The granularity of the time windows can depend on available computing resources to filter and store metric values and the desired level of outlier detection. For some metrics that are known to have low variability over short time windows, the cloud metric aggregator 151 can extend the time windows.” And Uriel, Fig. 3 and [0052]-[0053]).
As to claims 5 and 15, the teachings of Tuffs and Uriel as combined for the same reasons set forth in claim 1’s rejection further disclose in a predetermined first time band, the number of measurement times of the first plurality of measurement times belonging to the first time window is greater than the number of measurement times of the second plurality of measurement times belonging to the second time window (Uriel, Figs. 3, 4, and [0052]-[0053]).
As to claims 6 and 16, the teachings of Tuffs and Uriel as combined for the same reasons set forth in claim 1’s rejection further disclose the monitoring target resource includes a cloud compute instance, and wherein obtaining the second representative value and the second standard deviation of metric measured at the second plurality of measurement times belonging to the second time window includes: performing (i) a time window setting in which the number of measurement times of the first plurality of measurement times belonging to the first time window is greater than the number of measurement times of the second plurality of measurement times belonging to the second time window, or (ii) a time window setting in which the number of measurement times of the first plurality of measurement times belonging to the first time window is the same as the number of measurement times of the second plurality of measurement times belonging to the second time window, using tag information of the cloud compute instance (Tuffs, Fig. 1 and [0037], particularly, “At block 401, a cloud monitoring system generates statistics for metric data within a current accumulation time window. Based on detecting the emit trigger, the cloud monitoring system generates statistical indicators of distribution or dispersion of the accumulated metric data. Examples of the statistical indicators include mean and standard deviation.” the system continually loops, see [0046], particularly, “Asynchronously, operational flow continues to block 401 to obtain a next set of tagged metric data.” and (Uriel, Figs. 3, 4, and [0052]-[0053]).
Allowable Subject Matter
Claims 7-10 and 17-20 are 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS J DAILEY whose telephone number is (571)270-1246. The examiner can normally be reached on 9:30am-6:00pm.
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, Umar Cheema can be reached on 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/THOMAS J DAILEY/ Primary Examiner, Art Unit 2458
Prosecution Insights