DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in responsive to communication(s): original application filed on 06/08/2023. Claims 1-20 are pending. Claims 1, 17, and 19 are independent.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because (1) reference characters "322" in ¶ [0037] and "324" in FIG. 3 with ¶¶ [0037]-[0040] have both been used to designate "labeled data"; and (2) reference characters "324" in ¶ [0037] and "322" in FIG. 3 with ¶ [0039] have both been used to designate "unlabeled data" Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because (1) reference character “322” has been used to designate both "labeled data" in ¶ [0037] and "unlabeled data" in FIG. 3 with ¶ [0039]; and (2) reference character “344” has been used to designate both "unlabeled data" in ¶ [0037] and "labelled data" in FIG. 2 with ¶¶ [0037]-[0040]. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to because FIG. 3 shows that "unlabeled data 322 and labeled data 324 are inputs to few-shot anomaly detection algorithm for outputting anomaly scores 326"; however, specification in ¶ [0037] described "... The program code can label the data both by utilizing domain knowledge and/or by applying an unsupervised anomaly detection algorithm (320). However, the program code performs the workload pattern analysis on the temporal input (the original data) rather than on the embedded data. The inputs to this algorithm are labeled data 322 and unlabeled data 324 and the output is anomaly scores 326 ...". Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
in ¶ [0009], "… computer systems that detect detecting anomalous workloads in a semi-supervised manner by using temporal multi-channel metrics data as input" appears to be "… computer systems that detect anomalous workloads in a semi-supervised manner by using temporal multi-channel metrics data as input";
in ¶ [0016], "… enables the program code to classify workloads, including identifying detecting non-productive workloads …" appears to be "… enables the program code to classify workloads, including identifying non-productive workloads …";
in ¶ [0037], "… The inputs to this algorithm are labeled data 322 and unlabeled data 324 and the output is anomaly scores 326 …" appears to be "… The inputs to the few-shot anomaly detection algorithm are unlabeled data 322 and labeled data 324 and the output is anomaly scores 326 …" (see also Drawings Objections).
Appropriate correction is required.
The use of the term "Bluetooth" in ¶ [0027] and "Wi-Fi" in ¶¶ [0028]-[0029], which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Objections
Claims 1-3, 6, 9, 11, 14-15, and 17-20 are objected to because of the following informalities:
in Claim 1, lines 5-6; Claim 17, lines 9-10; and Claim 19, lines 9-10, "… determining, by the one or more processors, if domain knowledge is available to assist in identifying anomalous workloads …" appears to be "… determining, by the one or more processors, whether domain knowledge is available to assist in identifying anomalous workloads …" which provide more definite condition in scope;
in Claim 1, lines 7-8; Claim 17, lines 12-14; and Claim 19, lines 12-14, "… based on determining that domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis …" appears to be "… based on determining that the domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis …";
in Claim 1, lines 12-13; Claim 17, lines 18-20; and Claim 19, lines 18-20, "… based on determining that domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify …" appears to be "… based on determining that the domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify …";
in Claim 1, lines 16-18; Claim 17, lines 22-24; and Claim 19, lines 22-24, "… generating, by the one or more processors, a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the pattern and unlabeled data comprising the extracted patterns …" appears to be "… generating, by the one or more processors, a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns and unlabeled data comprising the extracted patterns …";
in Claim 1, lines 20-22; Claim 17, lines 27-28; and Claim 19, lines 27-28, "… combining one or more anomaly scores for the pattern selected one or more of the first set of anomaly scores and the second set of anomaly scores …" appears to be "… combining one or more anomaly scores for the pattern selected from one or more of the first set of anomaly scores and the second set of anomaly scores …" according to ¶ [0046] of the specification;
in Claim 1, lines 23-25; Claim 17, lines 29-32; and Claim 19, lines 29-32, "… determining, by the one or more processors, for each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for each pattern to a pre-defined threshold" appears to be "… determining, by the one or more processors, for said each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for said each pattern to a pre-defined threshold";
in Claim 2, line 1, "The computer-implemented method, wherein …" appears to be "The computer-implemented method of claim 1, wherein …";
in Claim 2, lines 1-2; Claim 18, lines 1-2; and Claim 20, lines 1-2, "… wherein generating the second set of anomaly scores for the labeled data is performed by semi-supervised anomaly detection algorithm …" appears to be "… wherein generating the second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns is performed by semi-supervised anomaly detection algorithm …" to distinct with other instances of "labeled data" recited in their respective based claim;
in Claim 3, lines 1-2, "… wherein generating the second set of anomaly scores for the labeled data comprises …" appears to be "… wherein generating the second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns comprises …" to distinct with other instances of "labeled data" recited in their respective based claim;
in Claim 6, lines 1-2, "… wherein extracting patterns from the temporal input comprises …" appears to be "… wherein extracting the patterns from the temporal input comprises …";
in Claim 9, lines 1-2, "… wherein the labeled data identified by applying the one or more unsupervised anomaly detection algorithm comprises …" appears to be "… wherein the labeled data comprising the additional portion of the patterns identified by applying the one or more unsupervised anomaly detection algorithm comprises …" to distinct with other instances of "labeled data" recited in their respective based claim;
in Claim 11, line 3, "… wherein the enhancing is selected from the group consisting of …" appears to be "… wherein the enhancing is selected from a group consisting of …";
in Claim 14, lines 2-3, "… based on determining that the given pattern is comprised in a non-productive workload, automatically shutting down… at least one resource of the computing system that handles the non-productive workload" appears to be "… based on determining that the given pattern is comprised in the non-productive workload, automatically shutting down… at least one resource of the computing system that handles the non-productive workload";
in Claim 15, lines 2-4, "… based on determining that the given pattern is comprised in a hotspot, migrating … at least a portion of the hotspot to a new resource in the computing system" appears to be "… based on determining that the given pattern is comprised in the hotspot, migrating … at least a portion of the hotspot to a new resource in the computing system".
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 17, and 19 recite the limitation "… identifying anomalous workloads in the extracted patterns based on the temporal input … perform a workload pattern analysis to identify a portion of the patterns as indicative of anomalous workloads … identify an additional portion of the patterns as indicative of the anomalous workloads …" in lines 6-14, lines 10-21, which rendering these claims indefinite because (1) it is unclear whether the first two instances of ".
Claims 2-16, 18, and 20 are rejected for fully incorporating the deficiency of their respective based claim.
Claims 2, 18, and 20 recite the limitation "... updating … the semi-supervised anomaly detection algorithm by utilizing patterns of the patterns determined to be anomalous data as training data; and updating … the domain knowledge with patterns of the patterns determined to be the normal and abnormal data" in lines 4-8, which rendering these claims indefinite because ".
Claim 6 recites the limitation "the temporal output" in lines 4-5. There is insufficient antecedent basis for this limitation in the claim. Clarification is required.
Claim 7 recites the limitation "the temporal output" in line . There is insufficient antecedent basis for this limitation in the claim. Clarification is required.
Claim 10 recites the limitation "the training data" in lines 2-3. There is insufficient antecedent basis for this limitation in the claim. Clarification is required.
Claim 11 recites the limitation "... enhancing … the patterns determined to indicate anomalous data to provide explainability … selecting or weighing features in the patterns determined to indicate anomalous data for imbalanced binary classification, performing attention-guided feature weighting, and re-mapping the patterns determined to indicate anomalous data to infrastructure metrics of the computing system" in lines 2-7, which rendering the claim indefinite because ".
Claim 12 is rejected for fully incorporating the deficiency of its based claim.
Claim 13 recites the limitation "… based on the determining concluding that a given pattern indicates anomalous data, determining, for the given pattern whether the given pattern is comprised in a non-productive workload or in a hotspot" in lines 2-4, which rendering the claim indefinite because ".
Claims 14-15 are rejected for fully incorporating the deficiency of their respective based claim.
Claim 16 recites the limitation "… wherein generating " in lines 1-8, which rendering the claim indefinite because ".
Claim 17 recites the limitation "A computer system" in lines 1-6, which rendering the claim indefinite because it is unclear whether the first instance and the third instance of ".
Claim 18 is rejected for fully incorporating the deficiency of its based claim.
Claim 19 recites the limitation "A computer program product comprising: one or more computer readable storage media and program instructions collectively stored on the one or more computer readable storage media readable by at least one processing circuit to perform a method comprising: obtaining, by the one or more processors, temporal input from resources … extracting, by the one or more processors, patterns from the temporal input; determining, by the one or more processors, if domain knowledge is available to assist in identifying anomalous workloads in the extracted patterns based on the temporal input … generating, by the one or more processors, a second set of anomaly scores for the labeled data … for each pattern of the patterns, calculating, by the one or more processors, a weighted sum … determining, by the one or more processors, for each pattern of the patterns, whether the pattern indicates anomalous data or normal data …" in lines 1-30, which rendering the claim indefinite because (1) t.
Claim 20 is rejected for fully incorporating the deficiency of its based claim.
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, 3-11, 13, 16-17, and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Independent Claims 1, 17, and 19
Step 1: Claim 1 is a process claim, Claim 17 is a system claim, and Claim 19 is a claim for one or more computer readable storage media (excluding transitory signal per se. in ¶ [0019]). These claims fall within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) recite(s) "extracting patterns from the temporal input ", "determining if domain knowledge is available to assist in identifying anomalous workloads in the extracted patterns based on the temporal input", "based on determining that domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis to identify a portion of the patterns as indicative of anomalous workloads, labeling data comprising the portion of the patterns, and generating a first set of anomaly scores for the labelled data comprising the portion of the patterns", "based on determining that domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify an additional portion of the patterns as indicative of the anomalous workloads and labeling data comprising the additional portion of the patterns", "generating a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the pattern and unlabeled data comprising the extracted patterns", "for each pattern of the patterns, calculating a weighted sum comprising a combined anomaly score for the pattern based on combining one or more anomaly scores for the pattern selected one or more of the first set of anomaly scores and the second set of anomaly scores", and "determining for each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for each pattern to a pre-defined threshold" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) recite(s) additional elements/limitations of "one or more processors ", "a computing system", "a memory" (Claim 17), "one or more computer readable storage media" (Claim 19), "at least one processing circuit" (Claim 19), and "obtaining temporal input from resources" which only amount to "apply it" with the use of generic computer components or insignificant extra solution activity. None of the additional elements/limitations, taken alone or in combination, integrate the abstract idea into a practical application.
Step 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitation/element of "obtaining temporal input from resources" is well-understood, routine and conventional (WURC) activity similar to "receiving or transmitting data over a network" (see MPEP 2106.05(d), "Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)"). Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claims 2, 18, and 20
Step 1: Claim 2 is a process claim, Claim 18 is a system claim, and Claim 20 is a claim for one or more computer readable storage media (excluding transitory signal per se. in ¶ [0019]). These claims fall within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "generating the second set of anomaly scores for the labeled data is performed by semi-supervised anomaly detection algorithm" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is integrated into a practical application because the claim(s) further recite(s) additional elements/limitations of "updating the semi-supervised anomaly detection algorithm by utilizing patterns of the patterns determined to be anomalous data as training data", and "updating the domain knowledge with patterns of the patterns determined to be the normal and abnormal data" which are integrated with other "judicial exception elements/limitations" in a meaning way so that improvement of a practical technology indicating in ¶¶ [0010]-[0013] of the specification is reflected in these claims as a whole. Therefore, these claims include patten eligible subject matters.
Claim 3
Step 1: Claim 3 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "generating the second set of anomaly scores for the labeled data comprises applying a few-shot anomaly detection model" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 4
Step 1: Claim 4 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) does/do not further recite(s) elements/limitations which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/algorithms/calculations.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) further recite(s) additional element/limitation of "obtaining temporal input from resources, wherein the temporal input comprises service level metrics, infrastructure level metrics, and host-level metric" which only amount to "apply it" with the use of generic computer components or insignificant extra solution activity. None of the additional elements/limitations, taken alone or in combination, integrate the abstract idea into a practical application.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitation/element of "obtaining temporal input from resources, wherein the temporal input comprises service level metrics, infrastructure level metrics, and host-level metric" is well-understood, routine and conventional (WURC) activity similar to "receiving or transmitting data over a network" (see MPEP 2106.05(d), "Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)"). Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 5
Step 1: Claim 5 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) does/do not further recite(s) elements/limitations which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/algorithms/calculations.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) further recite(s) additional element/limitation of "obtaining temporal input from resources, wherein the temporal input comprises a multi-channel comprised of system metrics from the resources comprising the computing system" which only amount to "apply it" with the use of generic computer components or insignificant extra solution activity. None of the additional elements/limitations, taken alone or in combination, integrate the abstract idea into a practical application.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitation/element of "obtaining temporal input from resources, wherein the temporal input comprises a multi-channel comprised of system metrics from the resources comprising the computing system" is well-understood, routine and conventional (WURC) activity similar to "receiving or transmitting data over a network" (see MPEP 2106.05(d), "Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)"). Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 6
Step 1: Claim 6 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "embedding a multi-channel with the patterns" and "filtering out noisy and redundant information across different metrics comprising the temporal output" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 7
Step 1: Claim 7 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "extracting patterns from the temporal input, wherein the patterns comprise temporal patterns and structural patterns in data comprising the temporal output" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 8
Step 1: Claim 8 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) does/do not further recite(s) elements/limitations which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/algorithms/calculations.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) further recite(s) additional elements/limitations of "ensemble learning" which only amount to "apply it" with the use of generic computer components or insignificant extra solution activity. None of the additional elements/limitations, taken alone or in combination, integrate the abstract idea into a practical application.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitation/element of "ensemble learning" is also well-understood, routine and conventional (WURC) activity similar to "performing repetitive calculation" (see MPEP 2106.05(d), "Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values)"). Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 9
Step 1: Claim 9 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "the labeled data identified by applying the one or more unsupervised anomaly detection algorithm comprises data comprising patterns from the patterns classified as anomalous with high confidence by the one or more unsupervised anomaly detection algorithm" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 10
Step 1: Claim 10 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) does/do not further recite(s) elements/limitations which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/algorithms/calculations.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) further recite(s) additional elements/limitations of "training the few-shot anomaly detection model with the training data" which only amount to "apply it" with the use of generic computer components or insignificant extra solution activity. None of the additional elements/limitations, taken alone or in combination, integrate the abstract idea into a practical application.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitation/element of "training the few-shot anomaly detection model with the training data" is also well-understood, routine and conventional (WURC) activity similar to "performing repetitive calculation" (see MPEP 2106.05(d), "Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values)"). Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 11
Step 1: Claim 11 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "enhancing the patterns determined to indicate anomalous data to provide explainability, wherein the enhancing is selected from the group consisting of: selecting or weighing features in the patterns determined to indicate anomalous data for imbalanced binary classification, performing attention-guided feature weighting, and re-mapping the patterns determined to indicate anomalous data to infrastructure metrics of the computing system" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 12
Step 1: Claim 12 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) does/do not further recite(s) elements/limitations which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/algorithms/calculations.
Step 2A Prong 2: This judicial exception is integrated into a practical application because the claim(s) further recite(s) additional element/limitation of "updating the domain knowledge with the enhanced patterns" which is integrated with other "judicial exception elements/limitations" in a meaning way so that improvement of a practical technology indicating in ¶¶ [0010]-[0013] of the specification is reflected in the claim as a whole. Therefore, the claim include patten eligible subject matters
Claim 13
Step 1: Claim 13 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "based on the determining concluding that a given pattern indicates anomalous data, determining, for the given pattern whether the given pattern is comprised in a non-productive workload or in a hotspot" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Claim 14
Step 1: Claim 14 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "determining that the given pattern is comprised in a non-productive workload" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is integrated into a practical application because the claim(s) further recite(s) additional element/limitation of "automatically shutting down at least one resource of the computing system that handles the non-productive workload" in a meaning way so that improvement of a practical technology indicating in ¶¶ [0010]-[0011] of the specification is reflected in the claim as a whole. Therefore, the claim include patten eligible subject matters.
Claim 15
Step 1: Claim 15 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "determining that the given pattern is comprised in a hotspot" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is integrated into a practical application because the claim(s) further recite(s) additional element/limitation of "migrating at least a portion of the hotspot to a new resource in the computing system" in a meaning way so that improvement of a practical technology indicating in ¶¶ [0010]-[0011] of the specification is reflected in the claim as a whole. Therefore, the claim include patten eligible subject matters.
Claim 16
Step 1: Claim 16 is a process claim which falls within at least one of the four categories of patent eligible subject matter.
Step 2A Prong 1: The claim(s) further recite(s) "generating the anomaly scores comprises: for a portion of the labeled data labeled based on the workload pattern analysis, calculating a distance that represents a divergence between the extracted patterns against representative patterns for the domain comprising the domain knowledge, and correlating the distance with the anomaly scores; and for portions of the data not labeled based on the workload pattern analysis, applying a few-shot anomaly detection model to generate the anomaly scores" which can be reasonably considered as mental processes (i.e., which "can be performed in the human mind, or by a human using a pen and paper") or mathematical concepts/calculations/algorithms.
Step 2A Prong 2: This judicial exception is not integrated into a practical application because the claim(s) does/do not further recite(s) additional elements/limitations.
Step 2B: The claim(s) does/do not further include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, none of the additional limitations, taken either alone or combined, amount to significantly more than the abstract idea.
Allowable Subject Matter
Claims 1, 3-11, 13, 16-17, and 19 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 101 and 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
Claims 2, 12, 14-15, 18, and 20 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
In regard to independent Claims 1, 17, and 19, prior arts of records, either
singularly or in combination, do not teach or suggest the combination of claimed
elements including "a computer-implemented method comprising: obtaining, by one or more processors, temporal input from resources comprising a computing system; extracting, by the one or more processors, patterns from the temporal input; determining, by the one or more processors, whether domain knowledge is available to assist in identifying anomalous workloads in the extracted patterns based on the temporal input; based on determining that the domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis to identify a portion of the patterns as indicative of first anomalous workloads, labeling data comprising the portion of the patterns, and generating a first set of anomaly scores for the labelled data comprising the portion of the patterns; based on determining that the domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify an additional portion of the patterns as indicative of second anomalous workloads and labeling data comprising the additional portion of the patterns; generating, by the one or more processors, a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns and unlabeled data comprising the extracted patterns; for each pattern of the patterns, calculating, by the one or more processors, a weighted sum comprising a combined anomaly score for the pattern based on combining one or more anomaly scores for the pattern selected from one or more of the first set of anomaly scores and the second set of anomaly scores; and determining, by the one or more processors, for said each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for said each pattern to a pre-defined threshold", "a computer system comprising: a memory; and one or more processors in communication with the memory, wherein the computer system is configured to perform a method, said method comprising: obtaining, by the one or more processors, temporal input from resources comprising a computing system; extracting, by the one or more processors, patterns from the temporal input; determining, by the one or more processors, whether domain knowledge is available to assist in identifying anomalous workloads in the extracted patterns based on the temporal input; based on determining that the domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis to identify a portion of the patterns as indicative of first anomalous workloads, labeling data comprising the portion of the patterns, and generating a first set of anomaly scores for the labelled data comprising the portion of the patterns; based on determining that the domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify an additional portion of the patterns as indicative of second anomalous workloads and labeling data comprising the additional portion of the patterns; generating, by the one or more processors, a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns and unlabeled data comprising the extracted patterns; for each pattern of the patterns, calculating, by the one or more processors, a weighted sum comprising a combined anomaly score for the pattern based on combining one or more anomaly scores for the pattern selected from one or more of the first set of anomaly scores and the second set of anomaly scores; and determining, by the one or more processors, for said each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for said each pattern to a pre-defined threshold", or "a computer program product comprising: one or more computer readable storage media and program instructions collectively stored on the one or more computer readable storage media readable by one or more processors to perform a method comprising: obtaining, by the one or more processors, temporal input from resources comprising a computing system; extracting, by the one or more processors, patterns from the temporal input; determining, by the one or more processors, whether domain knowledge is available to assist in identifying anomalous workloads in the extracted patterns based on the temporal input; based on determining that the domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis to identify a portion of the patterns as indicative of first anomalous workloads, labeling data comprising the portion of the patterns, and generating a first set of anomaly scores for the labelled data comprising the portion of the patterns; based on determining that the domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify an additional portion of the patterns as indicative of second anomalous workloads and labeling data comprising the additional portion of the patterns; generating, by the one or more processors, a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns and unlabeled data comprising the extracted patterns; for each pattern of the patterns, calculating, by the one or more processors, a weighted sum comprising a combined anomaly score for the pattern based on combining one or more anomaly scores for the pattern selected from one or more of the first set of anomaly scores and the second set of anomaly scores; and determining, by the one or more processors, for said each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for said each pattern to a pre-defined threshold " when interpreted as a whole.
Zhao et al. ("Label-Less: A Semi-Automatic Labelling Tool for KPI Anomalies", IEEE INFOCOM 2019 - IEEE Conference on Computer Communications, Apr 29-May 2, 2019, pp. 1882-1890) discloses in Abstract and Section I of Pages 1882-1883 that (1) propose a semi-automatic labelling tool called Label-Less, which minimizes the labeling overhead in order to enable an ImageNet-like large-scale KPI anomaly dataset with high-quality ground truth; (2) one novel technique in Label-Less is robust and rapid anomaly similarity search, which saves operators from scanning and checking the long KPIs back and forth for abnormal patterns or label consistency; (3) obtaining a large-scale KPI anomaly dataset with high-quality ground truth has been a great challenge due to following reasons; (4) first, labeling KPI anomalies takes domain knowledge of IT operations; (5) thus the number of people who can reliably label in our domain is much fewer than in image and speech areas; (6) besides, even the experienced operators may not have enough confidence to perform high-quality labeling since it is difficult to give an explicit definition of “what is an anomaly” in various KPIs and applications; (7) second, it is labor intensive to carefully examine a several-month-long KPI back and forth and try to label anomalies in a consistent manner; (8) third, we fundamentally need to label a large number of KPIs to train anomaly detection algorithms, because the anomalies in each KPI are relatively rare, KPI patterns are diverse, and the number of KPIs in practice is huge in large companies; (9) labeling overhead has become the main hurdle to large-scale KPI anomaly dataset, which in turn is the main hurdle to effective and practical KPI anomaly detection; (10) aim to tackle the KPI anomaly labeling overhead problem and propose a semi-automatic labeling framework called Label-Less; (11) the visual scanning is replaced by unsupervised anomaly detection which emphasizes on high recall and acceptable precision, and the results are candidate potential anomalies; (12) The manual consistency checking is replaced with our novel technique anomaly similarity search, which given an anomaly template by the operator, i.e., a KPI segment containing known anomalous data points, discovers anomalies similar to the template among the candidate anomalies; (13) our proposed framework Label-Less including an unsupervised anomaly detection component and an anomaly similarity search component, is a general one to tackle labeling overhead reduction problem; (14) this paper is the first one that applies Isolation Forest to unsupervised KPI anomaly detection, with features given by time series prediction models; (15) the unsupervised anomaly detection approach adopted in Label-Less has better performance and lower computation complexity compared with other alternatives; and (16) this is the first attempt to define and study the new problem: search anomalies similar to a given anomaly template from a set of candidate anomalies. Zhao further teaches in Section II with FIG.2 of Pages 1883-1884 that (1) KPI is a special type of time series data; (2) compared with general time series, KPIs are based on the domain knowledge of IT operations; (3) besides, the length of one KPI is long and the number of KPIs is huge; (4) KPI Anomalies refer to the data points in a KPI that do not conform to the expected behavior and significantly differ from the normal data; e.g., jitters, spikes and dips; (5) since an anomalous case always has its context instead of an individual point, it is a collection of continuous points called anomaly segment (anomaly for short hereinafter); (6) an anomaly template is an anomaly segment chosen by an operator according to his interest, denoted as q with length m, which is the input to the anomaly similarity search problem; (7) according to some distance measure, segment(i) with length m which has a small distance with the anomaly template q is considered as a similar anomaly to the template q; (8) operators provide an anomaly template q, which is an anomaly case that operators are interested in, such as the dip of the number of requests, and the goal of “anomaly similarity search” is to discover top-k similar anomalies from candidate anomalies (given by unsupervised anomaly detection) with the given template q; (9) anomaly similarity search is a little different from general time series similarity search: (a) first of all, anomaly information is indispensable in our scenario; i.e., what we are searching for is not only a segment similar to the template but also an anomaly; (b) thus the search space here is candidate anomalies given by unsupervised anomaly detection instead of the entire KPI; (c) besides, different from traditional time series, e.g., Electrocardiogram (ECG) and Electroencephalogram (EEG), a large number of long KPIs bring a great challenge in search responsiveness; (10) the overall framework of Label-Less shown in Fig. 2 has two major components.: (a) the first component, Unsupervised Anomaly Detection, takes a set of related unlabeled KPIs (e.g., the number of requests per server in a well load-balanced server cluster) as its input, and identifies a set of candidate anomalies as its output; (b) in detail, we apply Isolation Forest as an outlier detector and use the features extracted from time series models such as Holt-Winters; (c) then an appropriate detection threshold θ is selected with bias towards high recall and acceptable precision; (d) with a high recall rate, most anomalies can be included as candidate anomalies; (e) unsupervised anomaly detection not only provides candidate anomalies which can save the visual scanning time for operators, but also plays a key role in anomaly similarity search; (f) it filters out normal points so as to reduce false positives, i.e., similar normal segment; (g) besides, it can significantly reduce the search space and improve search efficiency; (h) to label anomalies consistently for the given KPIs, an operator first labels a true candidate anomaly as template; (i) then the second component, Anomaly Similarity Search, uses the template to automatically search for the top-k similar anomalies from the candidate anomalies; (j) propose an accelerated DTW method to reduce the search response time; (k) the operator then confirms the returned similar anomalies and labels them accordingly; and (l) this process continues until there are no more unlabeled anomalies. Zhao also discloses in Section III with FIG. 3 of Pages 1884-1885 that (1) Isolation Forest (iForest) is a popular outlier detector and has shown good performance with a linear time complexity in outlier detection but it has not been applied in KPI anomaly detection; (2) thus, we novelly apply iForest to unsupervised KPI anomaly detection; (3) different from most existing approaches, iForest explicitly isolates anomalies rather than profiling normal instances; (4) it takes advantage of two properties of anomalies: they are the minority consisting of fewer samples and they have some features which are very different from those of normal samples; i.e., anomalies are "few and different"; (5) therefore, they are more susceptible to be isolated; (6) iForest isolates observations by randomly selecting a feature and a split value between the minimum and maximum values of the selected feature; (7) usually, only a few conditions are needed to isolate anomalies from normal ones, whereas separating normal observations requires more conditions; (8) thus an anomaly score can be calculated as the number of conditions required to separate a given observation; (9) recursive partitioning of iForest can be represented by a tree structure (iTree), and the number of splittings required to isolate a sample is equivalent to the path length from the root node to the terminating node; (10) therefore, iForest builds an ensemble of iTrees for the input data, and anomalies are those instances with short average path lengths on the iTrees; (11) Fig. 3(a) presents an intuitive illustration and the features on every node will be introduced later; (12) before unsupervised anomaly detection, we first need to preprocess the input unlabeled KPIs; (13) KPIs are monitored with certain interval, e.g., every minute, and occasionally, a monitoring system does not receive data, leading to missing values; (14) we simply use linear interpolation to fill them based on their adjacent data points; (15) in addition, since KPIs are sourced from different servers, we normalize them to eliminate scale variances to prepare for similarity search; (16) zero-mean normalization is applied to transform a KPI to have zero mean and one standard deviation; (17) to apply iForest algorithm, we first need to extract anomaly features; (18) inspired by the idea of ensemble learning, we adopt several classical time series prediction models as feature extractors, i.e., Difference, Moving Average (MA), Weighed MA (WMA), Exponentially Weighted MA (EWMA), Autoregressive Integrated MA (ARIMA) and Holt-Winters; (19) the parameters are chosen based on our experience and domain knowledge, and these six models have low computation complexity and good performance which have been proved in anomaly detection literature; (20) in general, normal points can be well predicted with small prediction errors, since they conform to the expected behavior, while anomalies with unexpected patterns are hard to be predicted, creating large prediction errors; (21) in previous step, the raw KPI vector X (n × 1) was transformed into feature matrix X' (n × 6); (22) then we recursively divide X' by randomly selecting a feature, e.g., MA, and a split value ϵ, as shown in Fig. 3(a), to construct an iForest; (23) each terminal node in iForest is associated with a score between 0 and 1, calculated based on its path length; (24) the larger the score is, the more likely the node is an anomaly; (25) Fig. 3(b) presents an example to illustrate the anomaly score (right Yaxis) from a real KPI (left Y-axis), where obviously, the anomaly scores of anomalies are much higher than normal points; (26) to detect potential anomalies based on anomaly scores, we need to choose an appropriate threshold θ; (27) if the anomaly score of a point xi is larger than θ, we regard this point as a potential anomalous point, and then add segment(i) into the candidate anomalies; (28) usually, threshold selection for anomaly detection needs to tradeoff between high recall and high precision, and often uses F-score as the metric; (29) since here we try to generate candidate anomalies for operators and as our search space for anomaly similarity search, we choose to bias towards high recall and acceptable precision, so that false negative rate can be minimized; (30) Fig. 3(c) shows the CDF of anomaly scores of a real KPI, where we observe that the majority of points are likely to be normal with low anomaly scores and only few points have high anomaly scores; and (31) thus we choose anomaly score at 85th percentile (marked as the black dot) as the threshold θ such that the chance of false negatives is really small. Zhao further teaches in Section IV with FIG. 3 of Pages 1885-1886 that (1) through unsupervised anomaly detection, we can get a set of candidate anomalies as our search space; (2) next we search for the top-k anomalies most similar to a user-provided anomaly template and report to operators; (3) the key issue here is how to find similar anomalies with high accuracy and low response latency; (4) the design of anomaly similarity search is shown in Algorithm 1 and details will be introduced below; (5) choosing a suitable distance measure is the first step for anomaly similarity search; (6) in spite of dozens of alternative measures, recent empirical evidence strongly suggests that none of these alternatives routinely beats Dynamic Time Warping (DTW); (7) by optimally aligning two sequences in temporal domain, DTW calculates the minimized accumulated aligning cost as distance with dynamic programming; (8) hence, DTW can handle shift invariance as shown in Fig. 4(a); (9) given two time series x and y, with length of s and t, respectively , the time complexity of DTW is O(st). Fig. 4(b) shows the computation of DTW with a matrix, and the warping path representing the optimal alignment is marked in black color; (10) suppose there are r candidate anomalies, the complexity of similarity search reaches O(rm2), where m is the length of anomaly template; (11) when m and r are large, DTW computation can be very costly, and thus speeding up DTW is a key challenge in our scenario; (12) after careful investigation and extensive experiments, we design an accelerated DTW approach leveraging constrained DTW, lower bound, and early stopping, as shown in Algorithm 1; (13) the core idea of constrained DTW (cDTW) is to limit the permissible warping paths by providing local restrictions on the set of alternative steps considered; (14) it works under the assumption that it is unlikely for qi and cj to be matched if i and j are too far apart; (15) the threshold is determined by a warping window size w; (16) when w = 0, cDTW becomes the Euclidean distance, whereas when w ≥ m, cDTW has no local constraint; (17) the computational complexity of cDTW is O(wm); (18) as shown in Fig. 4(b), the gray area is the permissible scope of warping path; (19) the basic idea of lower bound is to use a cheap-to-compute lower bound of DTW to prune segments that cannot possibly be the top-k similar anomalies; (20) the process of pruning by lower bound has been shown in Algorithm 1, where best-so-far is the furthest distance in top-k segments; (21) in order to maintain best-so-far efficiently, we create a max-heap to keep the top-k similar anomalies; (22) the root node of the max-heap is the value of best-so-far; (23) when computing similarity, once the lower bound exceeds best-so-far, this segment is discarded since it cannot be in the top-k list; (23) Fig. 5(b) explains the idea of early stopping; (24) in the process of computing cDTW with dynamic programming, the black/dashed line moves from left to right; (25) if we add the partial (incrementally calculated) cDTW contribution from the left side of the dashed line and the LBKeogh contribution from the right of dashed line, this can be a new lower bound to DTW(q, c); and (26) once the sum of partial DTW and partial LBKeogh exceeds best-so-far, we can admissibly stop the calculation and prune off this candidate anomaly c.
QIU et al. (US 2020/0311603 A1, pub. date: 10/01/2020) discloses in ABSTRACT, ¶¶ [0003]-[0005], and ¶¶ [0011]-[0013] that (1) receive historical data associated with multiple cloud computing environments, trains one or more machine learning models, with the historical data, to generate trained machine learning models that generate outputs, and trains a model with the outputs to generate a trained model; (2) receive particular data, associated with a cloud computing environment, that includes data identifying usage of resources associated with the cloud computing environment, and processes the particular data, with the trained machine learning models, to generate anomaly scores indicating anomalous usage of the resources associated with the cloud computing environment; (3) the device processes the one or more anomaly scores, with the trained model, to generate a final anomaly score indicating anomalous usage of at least one of the resources associated with the cloud computing environment, and performs one or more actions based on the final anomaly score; (4) receive historical data associated with multiple cloud computing environments, and determine a multi-entity profile for the historical data associated with the multiple cloud computing environments, wherein the multi-entity profile may include data groupings of the historical data based on a set of attributes included in the historical data; (5) identify trends and patterns in the historical data based on the data groupings of the multi-entity profile, and may train one or more machine learning models, with the historical data and data identifying the trends and the patterns, to generate one or more trained machine learning models, wherein the training of the one or more machine learning models may generate outputs; (6) train a model with the outputs to generate a trained model, and receive particular data associated with a cloud computing environment, wherein the particular data may include at least data identifying usage of resources associated with the cloud computing environment; (7) process the particular data, with the one or more trained machine learning models, to generate one or more anomaly scores indicating anomalous usage of the resources associated with the cloud computing environment; (8) process the one or more anomaly scores, with the trained model, to generate a final anomaly score indicating anomalous usage of at least one of the resources associated with the cloud computing environment, and perform one or more actions based on the final anomaly score; (9) monitoring computing resource usage in relation to historical usage and/or usage by similar organizations, for similar tasks, and/or the like is difficult due to having to analyze millions, billions, or more data points across thousands, millions, or more accounts, which results in poor management of computing resource usage and/or mis-allocation of computing resources, thereby wasting computing resources that could otherwise be allocated to other organizations and/or tasks, resulting in overuse of computing resources, and/or the like; (10) anomalous usage (e.g., over-usage, usage of an unexpected combination of computing resources, and/or the like) of computing resources can disrupt operations of the organization, can result in significant expense to the organization, and/or the like; (11) facilitate improved management of resources (e.g., processing resources, memory resources, networking resources, and/or the like) associated with a cloud computing environment, which reduces or eliminates over usage of the resources, thereby conserving the resources, and reduces or eliminates over allocation of resources, thereby reducing instances of idle or unused resources and improving a utilization efficiency of the resources; and (12) improving management of resources through improved anomaly detection facilitates improved cost management with regard to the resources and improved planning with regard to future resource needs. QIU further discloses in ¶¶ [0014]-[0048] with FIGS. 1A-1I that (1) the anomaly detection platform may receive historical data associated with the cloud computing environments from, for example, one or more of the client devices, one or more of the resources, and/or the like; (2) the historical data may include (a) data identifying a usage of a set of resources associated with an organization; e.g., the historical data may include data identifying types of resources used by the organization, quantities of the resources used, times of day or days of the week when the resources are used, costs associated with the resources used by an organization (e.g., billing data), and/or the like; and (b) data identifying a migration plan for an organization with regard to resources; e.g., the historical data may include data identifying when resources are to be transitioned from non-cloud-based resources (e.g., server devices managed by an organization) to cloud-based resources (e.g., of the cloud computing environments), which types of resources are to be transitioned, whether the resources are to undergo an upgrade or a downgrade after being transitioned, and/or the like; (3) the anomaly detection platform may determine a multi-entity profile for the historical data associated with the cloud computing environments; e.g., the anomaly detection platform may determine the multi-entity profile after receiving the historical data, based on a request to determine the multi-entity profile, and/or the like; (4) a multi-entity profile may include a set of groupings of the historical data (e.g., data groupings) based on a set of attributes included in the historical data; e.g., the multi-entity profile may organize the historical data by types of resources, by tasks for which resources are organized, by users of the resources, by costs associated with resources, and/or the like; (5) the anomaly detection platform may identify trends and/or patterns in the historical data based on the data groupings of the multi-entity profile; (6) the anomaly detection platform may process the data groupings of the multi-entity profile to, e.g., identify trends, patterns, and/or the like in the data; (7) the anomaly detection platform may utilize a trend analysis technique (e.g., a regression analysis, a Marm-Kendall test, and/or the like), a pattern recognition technique (e.g., a classification model, a clustering model, an ensemble learning model, and/or the like), and/or the like to identify trends and/or patterns in the historical data based on the data groupings of the multi-entity profile; (8) the anomaly detection platform may train multiple machine learning models, with the historical data and data identifying the trends and/or the patterns in the historical data, to generate multiple trained machine learning models; (9) the machine learning models may include a kernel density estimation model, a regression splines model, a Gaussian process regression model, a discrete cosine transform signal processing model, a wavelet signal processing model, a filter banks signal processing model, and/or the like; (9) the trained machine learning models may be utilized by the anomaly detection platform to determine anomaly scores indicating anomalies (e.g., related to resource usage by an organization) in data received from a cloud computing environment (e.g., similar to the historical data); (10) the anomaly detection platform may train the machine learning models, with the historical data and the data identifying the trends and/or the patterns in the historical data, to identify anomaly scores for the historical data and the data identifying the trends and/or the patterns in the historical data; (11) the anomaly detection platform may train the machine learning models using, for example, an unsupervised training procedure and based on the historical data and the data identifying the trends and/or the patterns in the historical data; e.g., the anomaly detection platform may perform dimensionality reduction to reduce the historical data and the data identifying the trends and/or the patterns in the historical data to a minimum feature set, thereby reducing resources (e.g., processing resources, memory resources, and/or the like) to train the machine learning models, and may apply a classification technique to the minimum feature set; (12) the anomaly detection platform may use a logistic regression classification technique to determine a categorical outcome (e.g., that the historical data and the data identifying the trends and/or the patterns in the historical data include particular anomalies); (13) the anomaly detection platform may use a naive Bayesian classifier technique, where the anomaly detection platform may perform binary recursive partitioning to split the historical data and the data identifying the trends and/or the patterns in the historical data into partitions and/or branches and use the partitions and/or branches to determine outcomes (e.g., that the historical data and the data identifying the trends and/or the patterns in the historical data include particular anomalies); (14) based on using recursive partitioning, the anomaly detection platform may reduce utilization of computing resources relative to manual, linear sorting and analysis of data points, thereby enabling use of thousands, millions, or billions of data points to train the machine learning models, which may result in more accurate models than using fewer data points; (15) the anomaly detection platform may use a support vector machine (SVM) classifier technique to generate a non-linear boundary between data points in the training set. In this case, the non-linear boundary is used to classify test data into a particular class; (16) the anomaly detection platform may train the machine learning models using a supervised training procedure that includes receiving input to one or more of the machine learning models from a subject matter expert, which may reduce an amount of time, an amount of processing resources, and/or the like to train the machine learning models relative to an unsupervised training procedure; (17) the anomaly detection platform may use one or more other model training techniques, such as a neural network technique, a latent semantic indexing technique, and/or the like; (18) the anomaly detection platform may perform an artificial neural network processing technique ( e.g., using a two-layer feedforward neural network architecture, a three-layer feedforward neural network architecture, and/or the like) to perform pattern recognition with regard to patterns of the historical data and the data identifying the trends and/or the patterns in the historical data; (19) using the artificial neural network processing technique may improve an accuracy of the trained machine learning models generated by the anomaly detection platform by being more robust to noisy, imprecise, or incomplete data, and by enabling the anomaly detection platform to detect patterns and/or trends undetectable to human analysts or systems using less complex techniques; (20) the outputs generated based on training the machine learning models may include anomaly scores (e.g., indicating anomalies related to resource usage by organizations) generated by each of the multiple machine learning models; e.g., the kernel density estimation model may generate a first anomaly score, the regression splines model may generate a second anomaly score, the Gaussian process regression model may generate a third anomaly score, the discrete cosine transform signal processing model may generate a fourth anomaly score, the wavelet signal processing model may generate a fifth anomaly score, the filter banks signal processing model may generate a sixth anomaly score, and/or the like; (21) the anomaly detection platform may weight the outputs of training the machine learning model by a total amount of change; e.g., if a cost is consistent over time, small changes may be reported as large anomalies, the anomaly detection platform may silence anomalies where a change in a cost is below a predefined threshold that may be adjusted; (22) the anomaly detection platform may weight the outputs by a percent change; e.g., if a high cost is a relative term that may change over time for a given client as the client adjusts spending, the anomaly detection platform may silence anomalies where a percent change in cost is below a predefined threshold that may be adjusted; (23) the anomaly detection platform may train a super model, with the outputs based on training the machine learning models, to generate a trained super model; (24) the super model may include a model that determines an average anomaly score, a mean anomaly score, a particular anomaly score (e.g., a best anomaly score), a weighted average anomaly score, and/or the like based on anomaly scores output from the various machine learning model; e.g., the anomaly detection platform may generate the super model based on combining output from training the various machine learning models with the historical data, the data identifying trends and/or patterns in the historical data, and/or the like; (25) a threshold may be defined to determine cutoff scores to report as anomalies; (26) the anomaly detection platform may receive current data associated with a cloud computing environment which may include resources (e.g., computing resources, processing resources, memory resources, network resources, and/or the like) and may be associated with client devices; (27) the current data may include data identifying types of resources used by the organization, quantities of the resources used, times of day or days of the week when the resources are used, costs associated with the resources used by the organization (e.g., billing data), and/or the like; (28) the current data may include data identifying when resources are to be transitioned from non-cloud-based resources (e.g., server devices managed by an organization) to cloud-based resources ( e.g., of the cloud computing environment), which types of resources are to be transitioned, whether the resources are to undergo an upgrade or a downgrade after being transitioned, and/or the like; (29) the anomaly detection platform may process the current data, with the multiple trained machine learning models, to generate anomaly scores indicating anomalous resource usage of the cloud computing environment; (30) each of the trained machine learning models may generate an anomaly score indicating an anomaly related to resource usage of the cloud computing environment by an organization; (31) the anomaly detection platform may process the anomaly scores, with the trained super model, to generate a final anomaly score indicating anomalous resource usage of the cloud computing environment; (32) the anomaly detection platform may use the trained super model to process the anomaly scores from the various trained machine learning models that are used to process the current data; (33) the super model may output a final anomaly score that indicates a presence of an anomaly in usage of one or more resources of the cloud computing environment; (34) the trained super model may apply different weights to the different anomaly scores generated by the trained machine learning models, and add the weighted anomaly scores together to determine the final anomaly score; (35) the trained super model may divide a sum of the weighted anomaly scores by the quantity of anomaly scores to determine a weighted average anomaly score as the final anomaly score; (36) the anomaly detection platform may perform one or more actions based on the final anomaly score, wherein the one or more actions may include (a) providing, for display, information indicating whether an anomaly has been detected based on the final anomaly score so that the anomaly detection platform may alert individuals responsible for managing resource usage, and the individuals may address the anomaly and conserve resources in the future; (b) providing, to a resource, instructions that cause the resource to reboot, power off, or power on based on the final anomaly score so that the anomaly detection platform may better control usage of the resource and prevent underutilization or overutilization of the resource; (c) 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 to prevent underutilization or overutilization of the resource; (d) generating a recommendation to modify allocation of a resource for an organization based on the final anomaly score so that 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; (e) identifying a cause of an anomaly based on the final anomaly score; e.g., the anomaly detection platform may be capable of detecting a particular type of resource, an amount of time of the usage, a quantity of tasks, and/or the like that is the cause of the anomalous usage, based on scores output by corresponding machine learning models; (f) causing a robot to be dispatched to service a resource based on the final anomaly score; e.g., the robot may be dispatched to replace a resource, replace a component of a resource, record video of a resource, power off a resource, power on a resource, and/or the like; (g) the one or more actions may include the anomaly detection platform retraining the machine learning models and/or the super model based on the final anomaly score so that the machine learning models and/or the super model may better predict anomalies associated with a cloud computing environment; and (h) ordering a new resource to replace a resource based on the final anomaly score; e.g., the anomaly detection platform may order a new processor for a server device of the cloud computing environment based on determining that an existing processor of the server device is nonoperational; (37) the anomaly detection platform may determine a reallocation of the resources of the cloud computing environment based on the final anomaly score, and may cause the reallocation of the resources to be implemented by the cloud computing environment; (38) the anomaly detection platform may identify a type of resource, and may determine a quantity of usage time of a resource and a quantity of tasks performed by a resource; (39) the anomaly detection platform may determine a reallocation for the resources based on the type of the resource, the quantity of usage time of the resource, and the quantity of tasks performed by the resource, and may cause the reallocation to be implemented by the cloud computing environment; (40) the anomaly detection platform may be utilized to determine anomalies associated with virtual machines of a cloud computing environment; (41) the anomaly detection platform may perform frequency domain analysis of usage patterns of individual virtual machines in order to identify changes in the usage patterns; and (42) several different stages of the process for processing resource usage data and determining anomalous usage of resources may be automated via machine learning models, which may improve speed and efficiency of the process and conserve computing resources ( e.g., processing resources, memory resources, and/or the like).
Wang et al. ("Workload-Aware Online Anomaly Detection in Enterprise Applications with Local Outlier Factor", 2012 IEEE 36th Annual Computer Software and Applications Conference, Jul 16-20, 2012, pp. 25-34) discloses in Abstract and Section I of Page 25 that (1) detecting anomalies are essential for improving the reliability of enterprise applications; (2) current approaches set thresholds for metrics or model correlations between metrics, and anomalies are detected when the thresholds are violated or the correlations are broken; (3) however, we have found that the dynamic workload fluctuating over multiple time scales causes system metrics and their correlations to change; (4) moreover, it is difficult to model various metric correlations in complex applications; (5) this paper addresses these problems and proposes an online anomaly detection approach for enterprise applications; (6) a method is presented for recognizing workload patterns with an incremental clustering algorithm; (7) the Local Outlier Factor (LOF) based on the specific workload pattern is adopted for detecting anomalies; (8) our approach is evaluated on a testbed running the TPC-W benchmark; and (9) the experimental results show that our approach can capture workload fluctuations accurately and detect the typical faults effectively. Wang further discloses in Section III with Algorithms 1-3 of Pages 26-28 that (1) introduce Request Matrix (RM) to represent a workload in enterprise applications; (2) given k components in an application, we get a k-order matrix; (3) each request type is represented as a state, and then the users’ access pattern is described by the number of state transitions during a period; (4) RM presents not only the users’ visit pattern, but also the request volume that the server should afford; (5) let's denote RM in equation (1), where pij represents the number of transitions from state i to state j, and k is the number of components; (6) introduce Workload Vector (WV) transformed from RM to characterize the runtime workload by equation (2), wherein where em = pij, m = (i-1)×k+j, pij is an element in RM; (7) we observe that in most real systems, each component only interacts with a small number of other components, which allows us to find correlated groups of components using an online approximate principal component analysis (PCA) and clustering is suitable for presenting high dimension data with lower complexity; (8) the characterization of workload is described in Algorithm 1; (9) in order to get the request sequence of a customer, we analyze sessions which record the customers’ IDs and access history; (10) for an arriving request, session manager first decides if it requires to create a new session; (11) if the session ID corresponding to the request is null, we create a new session for it (1-5); (12) if there exists its session and the session is not time-out, we update RM through adding l on the value of element pij, where i is the last request type and j is the current request type (7-11); (13) if the session is time-out, we update it as a new session (12-15); (14) finally, we get a workload vector from the request matrix in period (17-19); (15) we group workloads with similar resource demand into a workload pattern; (16) the workloads belonging to the same pattern have similar request sequence and density; (17) clustering is an unsupervised method which is suitable for online classification, and is convenient to present high dimensional data; (18) propose a method for employing an incremental clustering algorithm to classify workloads automatically; (19) a workload is presented as a workload vector in formula (2) and a workload pattern is presented as a cluster; (20) thus, similar vectors are grouped into a cluster through clustering; (21) because (a) firstly, workloads vary over time in real applications, so the number of clusters is unknown in advance; (b) secondly, since a workload pattern ought to be stable during a period, the cluster generated by workload fluctuation ought to be considered as an access anomaly instead of a new pattern; and (c) finally, the clusters evolve with time, hence, we propose an incremental clustering method for recognizing workload patterns which uses the least distance to divide workload vectors into hyper spheres with the same radius as described in Algorithm 2; (22) (a) Step1: initialize a cluster (1-5), wherein when the first workload vector arrives, we initialize a cluster as cluster zero to present a workload pattern; (b) Step 2: train and classify workload patterns (6-16), wherein (i) we calculate distances between the coming data and every cluster, and then select the minimum distance; (ii) if the distance is not less than the defined threshold, a new cluster is initialized to the point; and (iii) otherwise, the workload vector is merged in the cluster with the shortest distance; and (c) Step 3: update clusters (18-24), wherein we traverse all existing clusters in the period to re-compute the centroid of every cluster, and delete the anomalous clusters with a few points caused by occasional workload fluctuation; (23) the distance threshold between a point and a cluster should influence the quality of clustering, which decides whether a point should be merged into a cluster; (24) we employ offline simulation using statistics to calculate the threshold as shown in Algorithm 3; (25) given some specific workload pattern, we generate the corresponding workloads and collect workload vectors periodically; (26) the distances between the centroid and every point are calculated, and we normalize every distance based on the average and standard deviation of the set of distances; (27) finally, we get the distance in (1-α) confidence interval; and (28) we simulate many workload patterns repeatedly, calculate distances respectively, and take the average of these distances as a threshold; (29) according to the rule of thumb from statistics, the proportion of contaminated data is usually less than 5%, and it is reasonable to set α as 0.05. Wang further discloses in Section IV with FIG. 3 and Algorithm 4 of Pages 28-30 that (1) we aim at detecting the contextual anomaly that the status is anomalous in a specific context; (2) a slight change at runtime may cause anomaly because of complex interactions with various runtime factors such as access sequences, concurrency number, resource usage, and so on; (3) we can online characterize system healthy situations, and take them as a baseline to detect anomalies in the specific contexts; (4) since system metrics vary with workload, i.e., there exists the relationship between workload and system metrics, a workload pattern corresponds to a metric space; (5) the composition of the workload pattern and its metric space is introduced to characterize system healthy situation as follows: (a) assuming that we have monitored metrics at time t, let’s denote the monitoring point by equation (3), where, mi is the ith metric, e.g., CPU, memory, network utilization and disk reading/writing frequency, and n is the number of metrics; (b) then, we use a pair of workload and system metrics to characterize the system runtime status by equation (4); (c) a metric space i is defined as equation (5), where Mi is a metric vector set and d is the Mahalanobis distance on Mi, i.e., a function d: M×M→R, such that for
∀
x,y,z [Symbol font/0xCE]M, holds non-negative, identity of indiscernibles, symmetry, and triangle inequality; (d) thus we use the pair of workload pattern and metric space to describe system healthy situation; (e) let's denote HSi = <WPi, MSi> in equation (6); and (f) the system healthy situation set is shown in Figure 3 and denoted by equation (7); (6) we online construct system healthy situations and take them as a baseline to detect anomaly as given in Algorithm 4; (7) we online train and recognize workload patterns with Algorithm 2 to get the corresponding metric space (1-2); (8) if the cluster is less than a defined size, the metric vector is merged in the metric space (3-6); (9) otherwise, we employ LOF (Local Outlier Factor) based on the metric space as an anomaly score of the runtime status to determine the anomalous status (8-9); (10) after finding the anomalous status, we use a student’s t-test method to detect anomalous metrics (10-15); (11) finally, the algorithm returns normal/anomalous status with LOF value (17-21); (12) compared to the distance-based methods, which are not suitable for varying workload pattern, we choose the local density-based method; (13) the local outlier factor (LOF) is a score assigned to each object as a degree of being an outlier, which means how isolated the object is with respect to the surrounding neighborhood; (14) we employ LOF which is based on k-nn method and local density method to detect anomaly and quality anomaly degree; (15) the normal data instances occur in dense neighborhoods, while anomalies occur far from their closest neighbors; (16) to decrease the influence of dimensional effect, we use Z-Score to standardize the metrics; (17) the Z-Score of metric vector is denoted by equation (18) given a instance Z(MV), the LOF score is equal to the ratio of average local density of its k nearest neighbors and its local density, and then the LOF is calculated as follows: (a) for any positive integer k, the k-distance of object p, denoted as k-distance(p), is defined as the distance d(p,o) between p and an object o such that for at least k objects o’[Symbol font/0xCE]D\{p} it holds that d(p,o’)≤d(p,o), and for at most k-l objects o’[Symbol font/0xCE]D\{p} it holds that d(p, o’)≤d(p,o); (b) given the k-distance of p, the k-distance neighborhood of p contains every object whose distance from p is not greater than the k-distance; (c) the reachability distance of object p with respect to object o is defined as equation (10); (d) the local density is then computed by dividing k by the volume of this hyper-sphere, wherein the local reachability density of p is defined as equation (11); and (e) the local outlier factor of p is defined as equation (12); (18) for a normal instance, it lies in a dense region, so its local density will be similar to that of its neighbors; (19) on the contrary, for an anomalous instance, its local density will be lower than that of its nearest neighbors; (20) therefore the anomalous instance will get a higher LOF score, and this score increases as the anomaly degree increases; (21) the computation complexity of our anomaly detection is brought from workload pattern recognition, LOF calculation, and system healthy situation construction; (22) for workload pattern recognition, we calculate the distance between the arriving monitoring point and cluster centroids to choose cluster with minimum distance, and then update the cluster centroid, and hence, its computation complexity is k × (m+n), where k is the size of dimension of a data instance, m is the number of clusters, and n is the number of data instances in a cluster; (23) for LOF calculation, the computation complexity is about O(n×time for a k-nn query), where we use SR-tree to find nearest neighbors, which provides an average complexity of O (log n) for k-nn queries, leading to a complexity of O (k log n); (24) for system situation construction, we need to calculate the variance and covariance matrix which take account for O (n2) computation complexity, where n is the number of components; and (25) since there are limited workload patterns, and we do not need to calculate repeatedly once getting a cluster, and thus, the computation complexity of this part cannot affect overall performance.
Gupta et al. ("A Supervised Deep Learning Framework for Proactive Anomaly Detection in Cloud Workloads", 2017 14th IEEE India Council International Conference, Dec 15-17, 2017, pp. 1-6) discloses in Abstract and Section I of Page 1 that (1) cloud environment is highly prone to failures due to its distributed nature and inherent complexity; (2) proactive identification of failures aids the service providers to avert these failures by taking corrective actions before they actually happen; (3) in this paper, we analyze the resource usage patterns to identify failures due to resource contention in cloud; (4) the resource usage and performance metrics of the working system are analyzed at regular time instants to model the normal and anomalous working behaviors; (5) a two stage framework has been implemented where a hybrid of long short term memory (LSTM) and bidirectional long short term memory (BLSTM) is used to predict the future resource usage and performance metric values in the first stage; (6) in the second stage, the hybrid model is used to classify the expected state as either normal or abnormal; (7) we evaluate the proposed anomaly detection model in a virtual environment set up using Docker containers; (8) the experimental results show that the proposed algorithm outperforms state-of-the-art algorithms; (9) since CPU bottleneck can lead to slow running of applications, memory bottlenecks can cause crashing of individual services and running out of disk space can leave the entire node unusable, therefore, the challenge for the service providers is to detect the expected failures/anomalies before they occur so that corrective actions can be taken to steer the system away from the impending anomalies; (10) most of the existing models for anomaly identification in cloud workloads assume that the observations at different time instants are independent of each other; (11) however, as the resource contention failures develop gradually over time, therefore it is important to analyze the failures/anomalies using a model that can exploit the dependencies between these observations; (12) the anomaly identification methods are broadly classified as reactive and proactive approaches, wherein (a) reactive approaches identify failures at the moment of failure; and (b) the proactive methods for anomaly detection work towards identifying the anomalies by analyzing the future resource usage values and predicting anomalies before they actually happen; (13) in this work we focus on proactive approach for anomaly detection; (14) in this work, we propose a proactive approach where a hybrid architecture of LSTM and BLSTM models is built for the prediction of future resource usage and anomaly detection in cloud workloads; (15) in this work, we propose a prediction-classification framework for proactive anomaly detection in cloud workloads; (16) under this framework, proactive anomaly identification is performed in two stages: (a) in the first stage, the hybrid architecture is used to generate the future resource usage and performance metrics patterns; and (b) in the second stage, the predicted resource usage patterns are analyzed for detecting anomalous behaviors; (17) the proposed prediction-classification framework is evaluated in a virtual environment set up using Docker containers; and (18) the contributions of this paper are twofold: (a) first, we propose to build a hybrid LSTM and BLSTM models for future prediction of cloud resource metrics; and (b) secondly, we propose to build and analyze the hybrid network for supervised classification of resource usage patterns as either normal/abnormal. Gupta further discloses in Sections III-IV with Table I and FIGS. 1-2 of Pages 2-4 that (1) deploy a Docker based virtual environment to continuously monitor the usage of different resources and performance metrics for the identification of upcoming resource contention failures; (2) to model the real scenario, a mix of normal and failure workloads is generated; (3) stress tool is used to generate different types of workloads, which forks worker processes to create a specific amount of CPU, memory, I/O, and disk burden; (4) different workload behaviors are generated randomly for different period of time namely, normal workload, bottlenecks in CPU, memory, I/O, disk and also combinations of different resource bottlenecks; (5) as failures are rare in a working environment, therefore the failure load generation probability is set as 0.03; (6) the metrics are collected from Docker statistics files, outside the containers because collecting the metrics from inside the stressed container results in the variation in the time at which the metrics are collected; (7) a total of 17 metrics covering usage of different resources and different performance metrics are recorded, which are presented in Table I; (8) in the proposed work, we analyze these recorded metrics to predict future usage of resources and hence proactive identification of anomalies; (9) an overview of the proposed framework for proactive detection of anomalies is presented in Figure 1; (10) after collecting the resource metrics, the data is pre-processed to remove noise in the data; (11) while pre-processing, missing values are filled by the mean of neighborhood values; (12) data averaging is used to reduce the effect of any sudden spikes in the recorded metrics; (13) after cleaning, the data is passed to a feature selection component; (14) feature (resource metric) selection is performed for selecting the most relevant set of features and to reduce the training time of models; (15) correlation between different features is analyzed to filter the most significant features; (16) different correlation measures model distinct types of relationships from the data; (17) therefore, Pearson, Spearman and Kendall correlation coefficients are computed and minimum redundancy maximum relevance rule is used for selecting the relevant features; (18) the correlation between features is analyzed and the features that are found insignificant from all the correlation measures are removed; (19) in this way, the set of features are reduced to 9, wherein the final set of resource metrics considered are: CPU, cache, RSS, mapped file, writeback, pgpin, pgout, active_anon and active_file; (20) it has been observed that long range dependence is present in cloud workloads, wherein the presence of long range dependence in the data under consideration is identified using Hurst exponent (H) and the Hurst parameter H >0.5 indicates that the data has long range dependence; (21) use variant of LSTM models in our prediction-classification framework for detection of anomalies in cloud workloads, wherein a LSTM block consists of three gates: the input, output and forget gates regulate the flow of information in or out of the memory; (22) the LSTM network predicts future by learning forward dependencies from t = 1, 2, …, T in time series; (23) on the other hand, forward and backward prediction networks integrate both forward and backward dependencies to learn the patterns; (24) these models are also called bidirectional models, wherein a bidirectional LSTM (BLSTM) network processes data in both directions with the backward layer iterating from t = T, …, 1 and forward layer iterating from t = 1, …, T; (25) intuitively, as a bidirectional LSTM model analysis both forward and backward dependencies in the resource usage patterns it is expected to be better than a unidirectional forward analysis LSTM model; (26) however because of the addition of an extra hidden layer for processing of backward dependencies, a bidirectional model requires more computations than a unidirectional LSTM model, which makes using bidirectional LSTM at all the layers highly computationally intensive; (27) therefore, we propose to implement a hybrid model that uses a combination of different LSTM and BLSTM layers; (28) Figure 2 presents the architecture of the hybrid model, wherein this hybrid model is the hybrid of BLSTM, BLSTM, and LSTM models; (29) it is a three-layered architecture, where a combination of both layers is explored for achieving better predictions within a reasonable computational overhead; (30) the solid lines in the Figure represent the connections between different units of the model at a particular time step whereas the dotted lines indicate the connections between different units from one time step to other; (30) the resource usage patterns predicted using the hybrid model are passed to the anomaly detection module for identification of upcoming resource bottleneck anomalies; (31) we use window based supervised learning models for identification of failures; (32) we also use the proposed hybrid architecture in Figure 2 for the detection of upcoming anomalies; (33) a supervised two class hybrid model is trained for classifying the predicted resource usage workload as either normal or abnormal; (34) in the hybrid model used for future resource usage prediction, linear activation is used at the Dense layer whereas for anomaly detection, the softmax activation is used at the Dense layer; (35) the future resource predictions are continuously analyzed for the detection of upcoming resource bottleneck anomalies; and (36) therefore, the prediction-classification architecture is designed with the motivation of serving as a proactive anomaly identification model for better resource provisioning in cloud.
Cheng et al. ("AI for IT Operations (AIOps) on Cloud Platforms: Reviews, Opportunities and Challenges", arXiv:2304.04661v1, Apr 10, 2023, pp. 11-34) discloses in Abstract of Page 1 that (1) artificial Intelligence for IT operations (AIOps) aims to combine the power of AI with the big data generated by IT Operations processes, particularly in cloud infrastructures, to provide actionable insights with the primary goal of maximizing availability; (3) we provide a review of the AIOps vision, trends challenges and opportunities, specifically focusing on the underlying AI techniques; (4) we discuss in depth the key types of data emitted by IT Operations activities, the scale and challenges in analyzing them, and where they can be helpful; (5) we categorize the key AIOps tasks as - incident detection, failure prediction, root cause analysis and automated actions; (6) we discuss the problem formulation for each task, and then present a taxonomy of techniques to solve these problems; (7) we also identify relatively under explored topics, especially those that could significantly benefit from advances in AI literature; (8) we also provide insights into the trends in this field, and what are the key investment opportunities. Cheng further discloses in Section I with FIGS. 1-2 of Pages 1-3 that (1) IT Operations plays a key role in the success of modern software companies and as a result multiple concepts have been introduced, such as IT service management (ITSM) specifically for SaaS, and IT operations management (ITOM) for general IT infrastructure; (2) Life cycle of Software systems can be separated into several main stages, including planning, development/coding, building, testing, deployment, maintenance/operations, monitoring, etc.; (3) the operation part of DevOps can be further broken down into four major stages: observe, detect, engage and act, shown in Figure 1; (4) observing stage includes tasks like collecting different telemetry data (metrics, logs, traces, etc.), indexing and querying and visualizing the collected telemetries; (5) Time-to-observe (TTO) is a metric to measure the performance of the observing stage; (6) detection stage includes tasks like detecting incidents, predicting failures, finding correlated events, etc. whose performance is typically measured as the Time-to-detect (TTD) (in addition to precision/recall); (7) engaging stage includes tasks like issue triaging, localization, root-cause analysis, etc., and the performance is often measured by Time-to-triage (TTT); (8) acting stage includes immediate remediation actions such as reboot the server, scale-up / scale-out resources, rollback to previous versions, etc.; (9) Time-to-resolve (TTR) is the key metric measured for the acting stage; (10) unlike software development and release, where we have comparatively mature continuous integration and continuous delivery (CI/CD) pipelines, many of the post-release operations are often done manually; (11) such manual operational processes face several challenges: (a) Manual operations struggle to scale: (i) the capacity of manual operations is limited by the size of the DevOps team and the team size can only increase linearly; (iii) when the software usage is at growing stage, the throughput and workloads may grow exponentially, both in scale and complexity; (iii) it is difficult for DevOps team to grow at the same pace to handle the increasing amount of operational workload; (b) Manual operations is hard to standardize: (i) it is very hard to keep the same high standard across the entire DevOps team given the diversity of team members (e.g. skill level, familiarity with the service, tenure, etc.); (ii) it takes significant amount of time and effort to grow an operational domain expert who can effectively handle incidents; and (iii) unexpected attrition of these experts could significantly hurt the operational efficiency of a DevOps team; and (c) Manual operations are error-prone: (i) it is very common that human operation error causes major incidents; and (ii) even for the most reliable cloud service providers, major incidents have been caused by human error in recent years; (12) given these challenges, fully-automated operations pipelines powered by AI capabilities becomes a promising approach to achieve the SLA and SLO goals; (13) AIOps combines big data and machine learning to automate IT operations processes, including event correlation, anomaly detection and causality determination; (14) AIOps is the key to achieve high availability, scalability and operational efficiency; (15) AIOps can dynamically scale its capabilities with growth demands and use AI for automated incident and resource management, thereby reducing the burden of hiring and training domain experts to meet growth requirements; (16) automation through AIOps helps save valuable developer time, and avoid fatigue; (17) transforming from manual to automated operations using AIOps is not a one-step effort; and (18) based on the adoption level of AI techniques, we break down AIOps maturity into four different levels based on the adoption of AIOps capabilities as shown in Figure 2: (a) Manual Ops: at this maturity level, DevOps follows traditional best practices and all processes are setup manually; (b) Human-centric: (i) at this level, operations are done mainly in manual process and AI techniques are adopted to replace sub-procedures in the workflow, and mainly act as assistants; (c) Machine-centric: at this level, all major components (monitoring, detecting, engaging and acting) of the E2E operation process are empowered by more complex AI techniques, and humans are mostly hands-free but need to participate in the human-in-the-loop process to help fine-tune and improve the AI systems performance; and (d) Fully-automated: at this level, AIOps platform achieves full automation with minimum or zero human intervention, and with the help of fully-automated AIOps platforms, the current CI/CD (continuous integration and continuous deployment) pipelines can be further extended to CI/CD/CM/CC (continuous integration, continuous deployment, continuous monitoring and continuous correction) pipelines. Cheng also discloses in Section II of Page 3 with FIG. 3 of Page 4 that we group AIOps tasks based on which operational stage they can contribute to, shown in Figure 3: (a) Incident Detection: incident detection tasks contribute to detection stage, and the goal of these tasks are reducing meantime-to-detect (MTTD); (b) Failure Prediction: failure prediction also contributes to detection stage, and the goal of failure prediction is to predict the potential issue before it actually happens so actions can be taken in advance to minimize impact as well as to reduce mean-time-to-detect (MTTD); (c) Root-cause Analysis: (i) root-cause analysis tasks contributes to multiple operational stages, including triaging, acting and even support more efficient long-term issue fixing and resolution; (ii) helping as an immediate response to an incident, the goal is to minimize time to triage (MTTT), and simultaneously contribute to reduction on reducing Mean Time to Resolve (MTTR); and (iii) an added benefit is also reduction in human toil; and (d) Automated Actions: automated actions contribute to acting stage, where the main goal is to reduce mean-time-to-resolve (MTTR), as well as long-term issue fix and resolution. Cheng further teaches in Section IV with FIGS. 7-9 of Pages 6-14 that (1) anomaly detection is to detect abnormalities, outliers or generally events that not normal; (2) anomaly detection can be further broken down to handling one or more specific telemetry data sources, including metric anomaly detection, log anomaly detection, trace anomaly detection; (3) another way to distinguish anomaly detection techniques is depending on different application use cases, such as detecting service health issues, detecting networking issues, detecting security issues, fraud transactions, etc.; (4) usually these variety of techniques are derived from same set of base detection algorithms and localized to handle specific tasks; (5) metric based incident detection, which aims to find the anomalous behaviors of monitored metrics that significantly deviate from the other observations, is vital for operators to timely detect software failures and trigger failure diagnosis to mitigate loss; (6) the most basic form of incident detection on metrics is the rule-based method which sets up an alert when a metric breaches a certain threshold; (7) due to the difficulty in obtaining labelled data for metrics incident detection and labels of anomalies are prone to error, unsupervised approaches, which do not require labels to build anomaly detectors, are generally preferred and more widespread; (8) particularly, unsupervised anomaly detection methods can be roughly categorized into density-based methods, clustering-based methods, and reconstruction-based methods; (9) density-based methods compute local density and local connectivity for outlier decision; (10) clustering-based methods formulate the anomaly score as the distance to cluster center; (11) reconstruction-based methods explicitly model the generative process of the data and measure the anomaly score with the reconstruction error; (12) while methods in metric anomaly detection are generally unsupervised, there are cases where there is some access to labels, and in such situations, semi-supervised, domain adaptation, and active learning paradigms come into play; (13) the semi-supervised paradigm enables unsupervised models to leverage information from sparsely available positive labels; (14) domain adaptation relies on a labelled source dataset, while the target dataset is unlabeled, with the goal of transferring a model trained on the source dataset, to perform anomaly detection on the target; (15) a wide range of machine learning models can be used for time series anomaly detection, broadly classified as deep learning models, tree-based models, and statistical models; (16) intrinsic anomaly detection considers the functional dependency structure between the monitored metric, and the environment; (17) this setting considers changes in the environment, possibly leveraging information that may not be available in the regular (extrinsic) setting; e.g., when scaling up/down the resources serving an application (perhaps due to autoscaling rules), we will observe a drop/increase in CPU metric, and while this may be considered as an anomaly in the extrinsic setting, it is in fact not an incident and accordingly, is not an anomaly in the intrinsic setting; (18) Figure 7 provides an outline of the different steps in the log analysis workflow; (19) While some of these steps are more of engineering challenges, others are more AI-driven and some even employ a combination of machine learning and domain knowledge rules; (20) Log Preprocessing: (a) this step typically involves customized filtering of specific regular expression patterns (like IP addresses or memory locations) that are deemed irrelevant for the actual log analysis; and (b) other preprocessing steps like tokenization requires specialized handling of different wording styles and patterns arising due to the hybrid nature of logs consisting of both natural language and programming language constructs; (21) Log Parsing: to enable downstream processing, unstructured log messages first need to be parsed into a structured event template (i.e. constant part that was actually designed by the developers) and parameters (i.e. variable part which contain the dynamic runtime information); (22) Log Partitioning: (i) after parsing the next step is to partition the log data into groups, based on some semantics where each group represents a finite chunk of log lines or log sequences; and (ii) the main purpose behind this is to decompose the original log dump typically consisting of millions of log lines into logical chunks, so as to enable explicit modeling on these chunks and allow the models to capture anomaly patterns over sequences of log templates or log parameter values or both; (23) Log Representation: (i) after log partitioning, the next step is to represent each partition in a machine-readable way (e.g. a vector or a matrix) by extracting features from them, which can be done in various ways - either by extracting specific handcrafted features using domain knowledge or through sequential representation which converts each partition to an ordered sequence of log event ids; (ii) quantitative representation which uses count vectors, weighted by the term and inverse document frequency information of the log events; and (iii) semantic representation captures the linguistic meaning from the sequence of language tokens in the log events and learns a high-dimensional embedding vector for each token in the dataset; (24) Log Analysis tasks for Incident Detection: (a)once the logs are represented in some compact machine-interpretable form which can be easily ingested by AI models, a pipeline of log analysis tasks can be performed on it - starting with Log compression techniques using Clustering and Summarization, followed by Log based Anomaly Detection; and (b) in turn, anomaly detection can further enable downstream tasks in Incident Management like Failure Prediction and Root Cause Analysis; (25) Log Compression through Clustering & Summarization: this is a practical first-step towards analyzing the huge volumes of log data is Log Compression through various clustering and summarization techniques, and the objective of this analysis serves two purposes – (a) firstly, this step can independently help the site reliability engineers and service owners during incident management by providing a practical and intuitive way of visualizing these massive volumes of complex unstructured raw log data; and (b) secondly, the output of log clustering can directly be leveraged in some of the log based anomaly detection methods; (26) Log Anomaly Detection: (a) perhaps the most common use of log analysis is for log based anomaly detection where a wide variety of models have been employed in both research and industrial settings; (b) these models are categorized based on various factors the learning setting - supervised, semi-supervised or unsupervised; (c) while the semi-supervised models assume partial knowledge of labels or access to few anomalous instances, unsupervised ones train on normal log data and detect anomaly based on their prediction confidence; (d) there are also systems which employ a rule engine built using domain knowledge and an ensemble of different ML models to cater to different incident types and also heuristic methods for doing contrast analysis between normal and incident-indicating abnormal logs; (30) Log Model Deployment: the final step in the log analysis workflow is deployment of these models in the actual industrial settings; and (31) Incorporating Domain Knowledge: (a) while existing log anomaly detection systems are entirely rule-based or automated, given the complex nature of incidents and the diverse varieties of anomalies, a more practical approach would involve incorporating domain knowledge into these models either in a static form or dynamically, following a humanin-the-loop feedback mechanism; e.g., in a complex system generating humungous amounts of logs, which kinds of incidents are more severe and which types of logs are more crucial to monitor for which kind of incidents; (b) or even at the level of loglines, domain knowledge can help understand the real-world semantics or physical significance of some of the parameters or variables mentioned in the logs; and (c) these aspects are often hard for the ML system to gauge on its own especially in the practical unsupervised settings. Cheng also teaches in Section VI of Pages 15-20 that (1) Root-cause Analysis (RCA) is the process to conduct a series of actions to discover the root causes of an incident; (2) when an anomaly is detected in a multi-service application, the services whose KPI metrics are anomalous can possibly be the root causes; (3) the first approach directly analyzes these KPI metrics to determine root causes based on the assumption that significant changes in one or multiple KPI metrics happen when an anomaly occurs; (4) therefore, the key is to identify whether a KPI metric has pattern or magnitude changes in a look-back window or snapshot of a given size at the anomalous timestamp; (5) the advantage of metric data analysis methods is the ability of handling millions of metrics, but most of them don’t consider the dependencies between services in an application; (6) the second type of RCA approaches leverages such dependencies, which usually involves two steps, i.e., constructing topology/causal graphs given the KPI metrics and domain knowledge, and extracting anomalous subgraphs or paths given the observed anomalies; (7) such graphs can either be reconstructed from the topology (domain knowledge) of a certain application or automatically estimated from the metrics via causal discovery techniques; (8) when the service graphs (the relationships between the services) or the call graphs (the communications among the services) are available, the topology graph of a multi-service application can be reconstructed automatically; (9) but such domain knowledge is usually unavailable or partially available especially when investigating the relationships between the KPI metrics instead of API calls; (10) therefore, given the observed metrics, causal discovery techniques, play a significant role in constructing the causal graph describing the causal relationships between these metrics; (11) the most popular causal discovery algorithm applied in RCA is the well-known PC-algorithm due to its simplicity and explainability; (12) given the discovered causal graph, the possible root causes of the observed anomalies can be determined by random walk; (13) Lack of Domain Knowledge: (a) the domain knowledge about the monitored application, e.g., service graphs and call graphs, is valuable to improve RCA performance; (b) but for a complex multi-service application, even developers may not fully understand the meanings or the relationships of all the monitored metrics; and (c) therefore, the domain knowledge provided by experts is usually partially known, and sometimes conflicts with the knowledge discovered from the observed data; (14) Combining Causal Discovery and Domain Knowledge: (a) the domain knowledge provided by experts are valuable to improve causal discovery accuracy, e.g., providing required or forbidden causal links between metrics; (b) but sometimes such domain knowledge introduces more issues when recovering causal graphs, e.g., conflicts with data properties or conditional independence tests, introducing cycles in the graph; and (c) how to combine causal discovery and expert domain knowledge in a principled manner is an interesting research topic.(15) the causal graph can be built in an iterative way, i.e., an initial causal graph is reconstructed by a certain causal discovery algorithm, and then users examine this graph and provide domain knowledge constraints (e.g., which relationships are incorrect or missing) for the algorithm to revise the graph; (16) Knowledge Mining based Methods: (a) takes a different approach of summarizing log events into an entity-relation knowledge graph by extracting custom entities and relationships from log lines and mining temporal and procedural dependencies between them from the overall log dump; (b) while this gives a more structured representation of the log summary, it is also an intuitive way of aggregating knowledge from logs, it is also a way to bridge the knowledge gap developer community who creates the log data and the site reliability engineers who typically consume the log data when investigating incidents; (c) however, eventually the end goal of constructing this knowledge graph representation of logs is to facilitate RCA; and (d) while these works do provide use-cases like case-studies on RCA for this vision, but they leave ample scope of research towards a more concrete usage of this kind of knowledge mining in RCA; (17) Knowledge Graph based Methods: (a) amongst knowledge graph based methods, [182] diagnoses and triages performance failure issues in an online fashion by continuously building a knowledge base out of rules extracted from a random forest constructed over log data using heuristics and domain knowledge; (b) [151] constructs a system graph from the combination of KPI metrics and log data; (c) based on the detected anomalies from these data sources, it extracts anomalous subgraphs from it and compares them with the normal system graph to detect the root cause; (d) other works mine normal log patterns or time-weighted control flow graphs from normal executions and on estimates divergences from them to executions during ongoing failures to suggest root causes; (e) [184], [185], [186] mines execution sequences or user actions [187] either from normal and manually injected failures or from good or bad performing systems, in a knowledge base and utilizes the assumption that similar faults generate similar failures to match and diagnose type of failure; and (f) most of these knowledge based approaches incrementally expand their knowledge or rules to cater to newer incident types over time; and (18) Causal Graph based Methods: (a) [188] uses a multivariate time-series modeling over logs by representing them as error event count, wherein this work then infers its causal relationship with KPI error rate using a page-rank style centrality detection in order to identify the top root causes; (b) [167] constructs a knowledge graph over operation and maintenance entities extracted from logs, metrics, traces and system dependency graphs and mines causal relations using PC algorithm to detect root causes of incidents; (c) [189] uses a Knowledge informed Hierarchical Bayesian Network over features extracted from metric and log based anomaly detection to infer the root causes; (d) [190] constructs dynamic causality graph over events extracted from logs, metrics and service dependency graphs; and (e) [191] similarly constructs a causal dependency graph over log events by clustering and mining similar events and use it to infer the process in which the failure occurs. Cheng further discloses in Section VII of Pages 20-22 that (1) without automation to take actions, human operators will still be needed in every single ops task; (2) thus, automated actions is critical to build fully-automated end-to-end AIOps systems; (3) automated actions contributes to both short-term actions and longer-term actions: a) short-term remediation: immediate actions to quickly remediate the issue, including server rebooting, live migration, automated scaling, etc.; and b) longer-term resolutions: actions or guidance for tasks such as code bug fixing, software updating, hard build-out and resource allocation optimization; (4) besides continuously monitoring the IT infrastructure, detecting issues and discovering root causes, remediating issues with minimum, or even no human intervention, is the path towards the next generation of fully automated AIOps; (5) automated issue remediation (Auto-remediation) is taking a series of actions to resolve issues by leveraging known information, existing workflows and domain knowledge; (6) end-to-end auto-remediation solutions usually contain three main components: anomaly or issue detection, root cause analysis and remediation engine; (7) Knowledge learning: (a) the knowledge here refers to a variety of categories.; (b) anomaly detection and root cause analysis for this specific issue contributes to a majority of the learnable knowledge; (c) remediation engine uses these information to locate and categorize the issue; (d) besides, the human activity records (such as tickets, bug fixing logs) of past issues are also significant for the remediation to learn the full picture of how issues were handled in history; (e) mining knowledge graphs from system metrics, logs and human-in-the-loop records; and (f) a high quality knowledge graph which clearly describes the relationship of system components; and (8) Learn to generate and update knowledge graphs: (a) quality of auto-remediation decision making strongly depends on domain knowledge; (b) currently humans collect most of the domain knowledge; and (c) in the future, it is valuable to explore approaches that learn and maintain knowledge graphs of the systems in a more reliable way.
However, closest arts of records, as discussed above, singly or in combination
do not teach or suggest at least following features "obtaining temporal input from resources comprising a computing system; extracting patterns from the temporal input; determining whether domain knowledge is available to assist in identifying anomalous workloads in the extracted patterns based on the temporal input; based on determining that the domain knowledge is available to assist in the identifying, utilizing the domain knowledge to perform a workload pattern analysis to identify a portion of the patterns as indicative of first anomalous workloads, labeling data comprising the portion of the patterns, and generating a first set of anomaly scores for the labelled data comprising the portion of the patterns; based on determining that the domain knowledge is not available to assist in the identifying, applying one or more unsupervised anomaly detection algorithms to identify an additional portion of the patterns as indicative of second anomalous workloads and labeling data comprising the additional portion of the patterns; generating a second set of anomaly scores for the labeled data comprising the portion of the patterns and the additional portion of the patterns and unlabeled data comprising the extracted patterns; for each pattern of the patterns, calculating a weighted sum comprising a combined anomaly score for the pattern based on combining one or more anomaly scores for the pattern selected from one or more of the first set of anomaly scores and the second set of anomaly scores; and determining for said each pattern of the patterns, whether the pattern indicates anomalous data or normal data based on utilizing an inference component to compare the combined anomaly score for said each pattern to a pre-defined threshold" when combining with all other limitations of these claims as a whole.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HWEI-MIN LU whose telephone number is (313)446-4913. The examiner can normally be reached Mon - Fri: 9:00 AM - 6:00 PM EST.
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, Mariela D. Reyes can be reached at (571) 270-1006. 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.
/HWEI-MIN LU/Primary Examiner, Art Unit 2142
Prosecution Insights