Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
Regarding claim 8, the recited operations are performed from the perspective of a security management client: communicating a request from a security management client, receiving a security posture visualization, and causing display of the visualization. Under the broadest reasonable interpretation, the "computerized system" of claim 1 is broad enough that its one or more processors perform these client-side operations in addition to the operations of claim 1. All of the operations of claim 8 are positively recited and are addressed with prior art below.
Regarding claims 9 and 18, each claim recites receiving an indication to execute a remediation action and communicating the indication "to cause execution of the remediation action." The positive acts recited in these claims are receiving the indication and communicating the indication. No element of either claim performs the execution of the remediation action; causing execution is the intended result of the communication. The examiner finds that performing the remediation action itself is not required by the claim. If the applicant believes it is required or will amend to require it, it is preemptively addressed below.
Regarding claim 20, the claim recites that TPs are communicated "for investigation and remediation," that BPs are communicated "for review and compliance checks," and that LCs are discarded. The positive acts recited are communicating the TPs, communicating the BPs, and discarding the LCs. No element of the claim performs investigation, remediation, review, or a compliance check; these phrases state the intended use of each communication. The examiner finds that performing the investigation, the remediation, the review, or the compliance checks is not required by the claim. If the applicant believes these are required or will amend to require them, they are preemptively addressed below.
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 6, 18, 19, and 20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 6 recites "wherein generating the usualness score." There is insufficient antecedent basis for "the usualness score" or “generating the usualness score” in the claim. Claim 1 recites "an anomaly score" and “generating an anomaly score” and no claim recites a usualness score or its generating. A person of ordinary skill in the art cannot reasonably determine whether "the usualness score" refers to the anomaly score of claim 1 or to a different score, and the two readings differ in scope. For purposes of examination, "the usualness score" is interpreted as the anomaly score of claim 1 and, likewise, “wherein generating the usualness score” refers to “wherein generating the anomaly score”.
Claims 18 and 19 each recite "The media of claim 16." Claim 16 is a method claim and does not recite media, so the scope of claims 18 and 19 cannot be determined. For purposes of examination, claims 18 and 19 are each interpreted as depending from claim 17, which recites the computer-storage media. Claim 20 depends from claim 19 and inherits this indefiniteness; for purposes of further examination, claim 20 is interpreted as depending from claim 19 as just-indicated-as-interpreted.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The references relied upon in the following rejections are:
Aouad et al. (US-11275831-B1), hereinafter "Aouad."
Muddu et al. (US-20170134410-A1), hereinafter "Muddu."
Tian et al. (CN-118573487-A), hereinafter "Tian."
Beauchesne et al. (US-20240396907-A1), hereinafter "Beau."
Lim et al. (KR-20230070752-A), hereinafter "Lim."
Claims 1, 3, 4, 5, 8, 9, 10, 11, 15, 17, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Aouad in view of Muddu.
Regarding claim 1, claim 1 recites "A computerized system comprising: one or more computer processors; and computer memory storing computer-useable instructions that, when used by the one or more computer processors, cause the one or more computer processors to perform operations." Aouad provides for this limitation because Aouad discloses a system with at least one physical processor and physical memory comprising computer-executable instructions and one or more modules that, when executed by the physical processor, cause the physical processor to perform the operations of its method (Aouad, col. 2, ll. 32-49).
Claim 1 further recites the operation of "accessing command-line data associated with a first command-line." Aouad provides for this limitation because Aouad discloses a receiving module that receives command line data from a target computing system, either from a real-time monitoring application running on the target computing system or from stored event logs associated with previously occurring security events (Aouad, col. 6, ll. 51-65).
Claim 1 further recites "generating an anomaly score for the first command-line, wherein the anomaly score quantifies unusual characteristics of the first command-line." Aouad provides for part of this limitation because Aouad discloses assigning anomalous scores to command line data instances that have a low reputation or that fail to exceed a threshold associated with known common data (Aouad, col. 6, ll. 27-34), and discloses assigning the anomalous score after determining that the commands in a data instance are uncommon commands (Aouad, col. 8, ll. 27-42). The disclosed anomalous score corresponds to the claimed anomaly score because it is a score assigned to a command-line data instance based on the instance being unusual. However, while Aouad assigns an anomalous score to unusual command-line data, Aouad does not explicitly disclose that the anomaly score "quantifies unusual characteristics" of the command-line, because Aouad's final verdict for a data instance is either that it is anomalous or that it is an already seen command or variant (Aouad, col. 9, ll. 17-19), rather than a score expressing a degree.
Muddu provides for the missing quantifying score. Muddu discloses an anomaly score that represents a quantification of a degree to which processed event data is associated with anomalous activity, for example a value between 0 and 10, with 0 being the least anomalous and 10 being the most anomalous (Muddu, [0360]). Muddu does not provide for command-line data; Muddu is relied upon only for its graded anomaly scoring and, as set forth below, its security management display. Aouad provides the command-line data and the command-line analysis.
Claim 1 further recites "determining a local context associated with the first command-line, wherein the local context is determined based on historical data corresponding to the first command-line." Aouad provides for this limitation because Aouad discloses determining whether a command is common based on the number of times the command has been run over a configuring time period, such as a POWERSHELL command that is repeated at least once every X days (Aouad, col. 7, l. 46 - col. 8, l. 7). The disclosed per-command execution history corresponds to the claimed historical data corresponding to the first command-line, and the resulting commonness determination corresponds to the claimed local context of that command line.
Claim 1 further recites "based on the anomaly score and the local context, generating a security insight for the first command-line." Aouad provides for this limitation because Aouad discloses identifying anomalous commands comprising potentially malicious data based on the assigned score (Aouad, col. 8, ll. 43-48), where the identification results from Aouad's two determinations together: data that is present in the clean index, or that has a near-duplicate count exceeding a threshold, is considered common, and data that is not is put through the SVM ensemble, which provides a final verdict for the data (Aouad, col. 9, ll. 1-19). The disclosed identification of a command as potentially malicious corresponds to the claimed security insight for the command-line.
Claim 1 further recites "communicating the security insight to a security management client." Aouad provides for part of this limitation because Aouad discloses sending the identified anomalous commands to a security module for reporting as potentially malicious data to a network security administrator for analysis and possible threat remediation (Aouad, col. 8, ll. 55-60). However, while Aouad reports the identified anomalous commands to a network security administrator, Aouad does not explicitly disclose communicating the security insight to a security management "client," that is, a client computing component that receives and presents the insight.
Muddu provides for the missing security management client. Muddu discloses a GUI generator module that gathers generated anomaly data and threat data, generates display data based on the gathered data, and sends the generated display data to one or more physical display devices to cause those devices to display the GUI features, and that receives user inputs and modifies the display data based on those inputs (Muddu, [0439]). The disclosed GUI generator and display correspond to the claimed security management client because they are the client-side component that receives the security determinations and presents them for review.
The proposed modification is to add Muddu's graded anomaly scoring (Muddu, [0360]) and Muddu's security-management display (Muddu, [0439]) to Aouad's command-line anomaly detection system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification. Aouad's verdict for a command-line data instance is only that the instance is anomalous or already seen (Aouad, col. 9, ll. 17-19); replacing that two-value outcome with Muddu's score that quantifies a degree of anomalousness lets the system express how unusual each command-line is, so that command-lines that are more unusual can be distinguished from command-lines that are only slightly unusual. Sending the resulting insights to Muddu's display gets each insight in front of a user who can review it and act on it, because Muddu's GUI generator both presents the data and receives the user's inputs (Muddu, [0439]). This is a predictable use of a known scoring approach and a known security display with a known command-line detection system, and the combination provides for the limitations of claim 1.
Regarding claim 3, claim 3 depends from claim 1 and further recites "wherein the security insight is associated with an anomaly detection engine, the anomaly detection engine is associated with an analysis framework comprising data processing, global analysis, local analysis, and combining of results of both global analysis and local analysis." Aouad provides for this additional limitation. Aouad's baseline-model system corresponds to the claimed anomaly detection engine, and it operates in the claimed framework: for data processing, Aouad discloses extracting lexical information from the command line data, including command line n-grams such as 3-grams (Aouad, col. 7, ll. 23-34); for global analysis, Aouad discloses screening incoming data against a clean index and a near-duplicate count threshold that reflect the command line data of the environment as a whole (Aouad, col. 9, ll. 1-19); for local analysis, Aouad discloses a further determination for the individual data instance, in which the SVM determines whether the commands in that instance are previously seen commands or variants, or are uncommon commands (Aouad, col. 8, ll. 27-42); and for combining of results, Aouad discloses that data passing the index and count screen is considered common, and data that is not is put through the SVM ensemble, which provides the final verdict (Aouad, col. 9, ll. 1-19), so the final verdict for an instance results from both stages together.
Regarding claim 4, claim 4 depends from claim 3 and further recites "wherein the anomaly detection engine comprises an anomalous command-line detector the enables data pre-processing, global analysis, local analysis, and an application engine that enables combining the results, triaging anomalies, generating alerts and human-in-the-loop validation, and a feedback loop for fine-tuning the models." As discussed above with respect to claim 3, Aouad provides for the data pre-processing, the global analysis, the local analysis, and the combining of results (Aouad, col. 7, ll. 23-34; col. 8, ll. 27-42; col. 9, ll. 1-19). Aouad also provides for generating alerts, because Aouad discloses reporting the identified anomalous commands to a network security administrator for analysis (Aouad, col. 8, 11. 55-60). However, while Aouad reports its identified anomalous commands for analysis, Aouad does not explicitly disclose triaging anomalies, human-in-the-loop validation, or a feedback loop for fine-tuning the models.
Muddu provides for the missing triaging, human-in-the-loop validation, and feedback loop. Muddu discloses a filter section that lets a user filter threat results according to time, severity, or type, and filter out threats whose scores are below a chosen value (Muddu, [0456]), which corresponds to triaging anomalies because it orders the review of the detections by their importance. Muddu discloses a user interface element to accept feedback from a user to confirm or reject the security-related conclusion, and providing that feedback to a model training process thread to update the model state (Muddu, [0319]), which corresponds to human-in-the-loop validation and to a feedback loop for fine-tuning the models, because the human's confirmation or rejection is fed back to update the model.
The proposed modification is to add Muddu's severity filtering (Muddu, [0456]) and Muddu's confirm or reject feedback loop (Muddu, [0319]) to the display of the Aouad-Muddu system discussed for claim 1. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because Aouad reports its anomalous commands for analysis but provides no way to manage that review or to correct the models afterward; Muddu's filters let the reported anomalies be reviewed in order of severity, and Muddu's confirm-or-reject feedback updates the model state so that later detections improve. This is a predictable use of Muddu's known review and feedback features with the detections already produced by the combination.
Regarding claim 5, claim 5 depends from claim 3 and further recites "wherein the anomaly detection engine supports detecting anomalous command-lines using a plurality of unusual command-line types that define possible types of anomalous command-lines and command-line metadata that define command-line contextual factors." Aouad provides for the plurality of unusual command-line types, because Aouad discloses that uncommon commands may include commands that are not among the previously seen commands or variants of previously seen commands, and additionally or alternatively may include commands having a low reputation (Aouad, col. 8, ll. 27-42), which are two different defined types of anomalous command-lines. However, while Aouad defines these types of anomalous command-lines, Aouad does not explicitly disclose command-line metadata that define command-line contextual factors.
Muddu provides for the missing contextual metadata. Muddu discloses determining behavior baselines for entities such as users and devices and comparing the activities of those entities to their baselines (Muddu, [0182]), and discloses that a baseline can be created for any type of entity, for example a user, a group of users, a device, or an application (Muddu, [0184]). The user and device associated with monitored activity correspond to the claimed contextual factors, because they are the circumstances in which the activity occurred. Muddu does not provide for command-line data; Muddu is relied upon only for associating monitored activity with the user and device that produced it.
The proposed modification is to associate Aouad's command-line data with Muddu's user and device context (Muddu, [0182], [0184]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because knowing which user and which device produced a command-line allows the command-line to be judged against what is normal for that user and device, so that a command-line that is unusual for the environment but routine for its own user is recognized as legitimate rather than treated as a detection (Muddu, [0185], where activities judged legitimate update the entity's normal baseline).
Regarding claim 8, claim 8 depends from claim 1 and further recites the operations of "The system of claim 1, the operations further comprising: communicating, from a security management client, a request for a security posture of a computing environment; based on communicating the request, receiving a security posture visualization comprising a security insight associated with the first command-line, wherein the security insight identifies the first command-line as a true positive, a benign positive, or a legitimate command; and causing display of the security posture visualization." The identification limitation is recited in the alternative, so prior art meeting any one of the alternatives is sufficient.
While Aouad communicates its insights outward for analysis (Aouad, col. 8, ll. 55-60), Aouad does not explicitly disclose the client-side operations of communicating the request, receiving the visualization, and causing its display. However, Muddu provides for communicating the request from a security management client, because Muddu discloses that the home screen prompts a user to begin a threat review, and that clicking the "Start Threat Review" button causes a Threats Review view to be provided (Muddu, [0454]); the click communicates the user's request for the security posture of the monitored environment. Muddu provides for receiving and displaying the security posture visualization, because Muddu discloses the GUI generator generating display data from the gathered anomaly and threat data and sending the display data to physical display devices to cause the display (Muddu, [0439]), and discloses that the Threats Review view identifies a particular threat with a summary description and a threat score (Muddu, [0457]). In the combination discussed for claim 1, the identified threat presented in the view is Aouad's command-line identified as comprising potentially malicious data (Aouad, col. 8, ll. 43-48), so the displayed insight identifies the first command-line as a true positive, meeting the first alternative. Muddu also provides for the remaining alternatives, because a displayed threat can be tagged "False Positive" or redesignated "Not a Threat" (Muddu, [0477], [0460]), identifications corresponding to the claimed benign positive and legitimate command respectively.
The proposed modification is to present the insights of the Aouad-Muddu system through Muddu's request-driven threat review display (Muddu, [0454], [0439], [0457]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because it lets a user ask for the current security state of the computing environment and receive, on a display, the insight for the detected command-line, using the same display component already added to the combination for claim 1.
Regarding claim 9, claim 9 depends from claim 8 and further recites "receiving an indication to execute a remediation action associated with the security insight; and communicating the indication to execute the remediation action to cause execution of the remediation action." As stated in the Claim Interpretation section above, the positive acts of this claim are receiving the indication and communicating the indication; the execution itself is the intended result and is not required by the claim; as per the Claim interpretation section above, it is being addressed arguendo, in the alternative. While Aouad reports the anomalous commands for analysis and possible threat remediation (Aouad, col. 8, ll. 55-60), Aouad does not explicitly disclose receiving an indication to execute a remediation action or communicating the indication. However, Muddu provides for this limitation because Muddu discloses generating a user interface element to solicit an action command to activate a threat response, and, upon the action command, sending a message to the target-side computer system to demand termination of a problematic application, blocking of specific network traffic, or removal of a user account (Muddu, [0319]). The solicited action command corresponds to the claimed indication to execute a remediation action, and sending the message that demands the termination, blocking, or removal corresponds to communicating the indication to cause execution of the remediation action.
The proposed modification is to add Muddu's action-command interface element (Muddu, [0319]) to the threat review display of the combination. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because it lets the user who is reviewing the displayed insight respond to the detected command-line directly, by terminating the application, blocking the traffic, or removing the account associated with it.
Regarding claim 10, claim 10 recites "A computer-implemented method, the method comprising: accessing command-line data associated with a plurality of command-lines, wherein the command-line data is associated with a computing environment." Aouad provides for this limitation because Aouad discloses receiving command line data from a target computing system, from a real-time monitoring application or from stored event logs (Aouad, col. 6, ll. 51-65), and discloses scores assigned to command line data instances, in the plural (Aouad, col. 6, ll. 27-34). The target computing system corresponds to the claimed computing environment.
Claim 10 further recites "executing a plurality of global analysis operations to flag anomalies associated with the computing environment." Aouad provides for this limitation because Aouad discloses receiving incoming data in LSH indexes and then determining whether the data is present in the clean index or has a near-duplicate count that exceeds a threshold; data meeting either condition is considered common, and data meeting neither is put through the SVM ensemble (Aouad, col. 9, ll. 1-19). The index lookup and the count comparison are a plurality of operations performed against the data of the environment as a whole, and the data that fails them is the flagged anomalies.
Claim 10 further recites "executing a plurality of local analysis operations to differentiate benign positive command-lines from true positive command-lines." Aouad provides for this limitation because Aouad discloses, for an individual flagged data instance, receiving the instance in the SVM from the hashing function and determining, utilizing the SVM, whether the commands in the instance are previously seen commands or a variant of previously seen commands, in which case a clean score is assigned, or are uncommon commands, in which case an anomalous score is assigned (Aouad, col. 8, ll. 27-42), with the final verdict being that the data is either anomalous or an already seen command or variant (Aouad, col. 9, ll. 14-19). A command-line flagged by te global screen that the SVM then determines to be a variant of previously seen commands corresponds to the claimed benign positive command-line, because it was flagged but is in fact harmless; a flagged command-line that the SVM determines to be an uncommon command, and that is identified as comprising potentially malicious data, corresponds to the claimed true positive command-line. Receiving the instance in the SVM and making the SVM determination are a plurality of local analysis operations on the individual instance.
Claim 10 further recites "based executing the plurality of global analysis operations and the plurality of local analysis operations, generating one or more security insights." Aouad provides for this limitation because Aouad discloses identifying anomalous commands comprising potentially malicious data based on the assigned scores (Aouad, col. 8, ll. 43-48), where, as discussed above, the scores result from the global screen and the SVM determination together.
Claim 10 further recites "communicating the one or more security insights to a security management client." Aouad provides for part of this limitation because Aouad discloses reporting the identified anomalous commands to a network security administrator for analysis and possible threat remediation (Aouad, col. 8, ll. 55-60). However, as with claim 1, Aouad does not explicitly disclose communicating the insights to a security management client. Muddu provides for the missing security management client for the same reasons set forth above with respect to claim 1 (Muddu, [0439]).
The proposed modification is to present the insights of Aouad's method on Muddu's security-management display (Muddu, [0439]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because it delivers the generated insights to a client component where a user can view them and respond to them, since Muddu's GUI generator both presents the data and receives the user's inputs. Thus, the combination provides for the limitations of claim 10.
Regarding claim 11, claim 11 depends from claim 10 and further recites "wherein the executing the plurality of global analysis operations comprises: applying 1-gram tokenization to identify unusual parameters; applying 2-gram tokenization to detect rare or suspicious combinations of parameters; converting 1-gram tokens into corresponding numerical formats via text vectorization using a CountVectorizer model; and converting 2-gram tokens into corresponding numerical formats via text vectorization using the CountVectorizer model." Aouad provides for part of this additional limitation because Aouad discloses extracting lexical information comprising command line n-grams, for example 3-grams of POWERSHELL command lines seen on target environments (Aouad, col. 7, ll. 23-34), and discloses vectorizing the data for input into a model (Aouad, col. 9, ll. 1-19). However, while Aouad tokenizes command lines into n-grams and vectorizes the data, Aouad does not explicitly disclose using n-gram sizes of one and two, or that the text vectorization uses a CountVectorizer model.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use 1-gram and 2-gram tokenization, and a CountVectorizer model, in Aouad's global analysis. Aouad already tokenizes command lines into n-grams; the size of the n-gram is a selection from a small set of known options, and the two smallest sizes have known, predictable effects: a 1-gram isolates each individual parameter of the command-line, and a 2-gram captures each pair of adjacent parameters, which is what reveals a rare or suspicious combination. A CountVectorizer is a conventional, off-the-shelf text-vectorization tool that converts tokens into numerical count vectors, which is the same vectorization for model input that Aouad already performs. Selecting these known options to perform their established functions in Aouad's existing tokenization and vectorization would have produced no unexpected result.
Regarding claim 15, claim 15 depends from claim 10 and further recites "wherein the executing the plurality of local analysis operations comprises: accessing historical data associated with a flagged payload item; identifying metrics associated with command-line contextual factors of the flagged payload item; using the metrics, generating a historical baseline for the flagged payload; generating a local context based on the historical baseline for the flagged payload item." Aouad provides for accessing historical data associated with a flagged payload item, because Aouad's local determination for a flagged instance is made against the previously seen commands and their variants (Aouad, col. 8, ll. 27-42), which are historical command-line data. However, while Aouad checks each flagged instance against historical command-line data, Aouad does not explicitly disclose identifying metrics associated with contextual factors of the flagged item, generating a historical baseline from the metrics, or generating a local context based on that baseline.
Muddu provides for the missing metrics, baseline, and local context. Muddu discloses generating a baseline profile for the access activities of a specific user based on event data indicative of that user's network activities (Muddu, [0183]) and for other entities such as a device (Muddu, [0184]); discloses that the baseline profiles are continuously updated based on event data (Muddu, [0185]); discloses stored metrics for an entity's combined activities, including the number of times the activities occur, the average gap period between them, and the standard deviation of the gap periods (Muddu, [0425]); and discloses detecting anomalies by comparing incoming event data against the baseline profile for the entity to which the event data relates (Muddu, [0186]). The user and device associated with the flagged item correspond to the claimed command-line contextual factors; the counts, average gaps, and standard deviations correspond to the claimed metrics; the baseline profile built from them corresponds to the claimed historical baseline; and the comparison of the item against the profile corresponds to the claimed local context based on the baseline.
The proposed modification is to build Muddu's per-entity baseline profiles (Muddu, [0183] - [0186], [0425]) for the users and devices associated with the flagged command-lines of Aouad's method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because a command-line that is rare across the whole environment can still be routine for the particular user or device that produced it; evaluating the flagged command-line against the baseline of its own user or device lets such command-lines be recognized as legitimate, which is the differentiation of benign positives from true positives that claim 10 recites, and Muddu updates the baseline when flagged activity is judged legitimate (Muddu, [0185]).
Regarding claim 17, claim 17 recites "One or more computer-storage media having computer-executable instructions embodied thereon that, when executed by a computing system having a processor and memory, cause the processor to perform operations." Aouad provides for this limitation because Aouad discloses that its method may be encoded as computer-readable instructions on a non-transitory computer-readable medium that, when executed by at least one processor of a computing device, cause the computing device to perform the method (Aouad, col. 2, ll. 50-52).
Claim 17 further recites the operation of "accessing a plurality of flagged payload items associated with corresponding global analysis results and local analysis results." Aouad provides for this limitation because Aouad discloses command line data instances that carry the results of both of its stages: the instance's clean-index and near-duplicate count results from the corpus-level screen, and the SVM ensemble's verdict for the instance (Aouad, col. 9, ll. 1-19).
Claim 17 further recites "based on the corresponding global analysis results and local analysis results, generating classifications for the flagged payload items, the classifications are selected from the following: True Positives (TP), Benign Positives (BP), or Legitimate Commands (LC)." Aouad provides for part of this limitation because Aouad's two stages sort command line data instances into three outcomes: instances that are common, instances that are previously seen commands or variants and are assigned clean scores, and instances that are uncommon commands comprising potentially malicious data and are assigned anomalous scores (Aouad, col. 8, ll. 27-42; col. 9, ll. 1-19). However, while Aouad sorts the instances into these three outcomes, Aouad does not explicitly disclose generating classifications selected from True Positives, Benign Positives, or Legitimate Commands.
Muddu provides for the missing classification scheme. Muddu discloses classifying reviewed detections: a user can re-designate an identified threat as "Not a Threat," which instructs the system to delete the threat page and no longer identify it as a threat (Muddu, [0460]), and a user can tag a threat with "False Positive" or "Reviewed," with the tag remaining associated with the threat (Muddu, [0477]). A detection confirmed and kept as a threat corresponds to the claimed True Positive; a detection tagged "False Positive," which was flagged but is not actually a threat, corresponds to the claimed Benign Positive; and an item re-designated "Not a Threat" corresponds to the claimed Legitimate Command, because it is treated as ordinary activity rather than a detection.
Claim 17 further recites "communicating the flagged payload items based on workflows associated with the classifications." Aouad provides for part of this limitation because Aouad discloses that identified anomalous commands are sent to the security module for reporting to a network security administrator for analysis and possible threat remediation (Aouad, col. 8, ll. 55-60), which is the workflow for the items classified as actual threats. While Aouad routes those items to that reporting workflow, Aouad does not explicitly disclose a workflow associated with each of the classifications. However, Muddu provides for the remaining per-classification workflows, because in Muddu each disposition has its own handling: threats are stepped through in the Threats Review view (Muddu, [0454]), and items re-designated "Not a Threat" are deleted from the Threats View and no longer identified as threats (Muddu, [0460]).
The proposed modification is to apply Muddu's disposition classifications and their handling (Muddu, [0454], [0460], [0477]) to the command-line data instances scored by Aouad's two stages, on the media of Aouad's encoded instructions (Aouad, col. 2, ll. 50-52). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because separating the detections into actual threats, items flagged in error, and ordinary activity determines what happens to each item: the threats are reviewed and acted on, the items flagged in error are tagged so they are not treated as threats again, and the ordinary items are removed from the review. Thus, the combination provides for the limitations of claim 17.
Regarding claim 18, claim 18 is interpreted as depending from claim 17, as stated in the 112(b) rejection above, and further recites limitations substantially identical to those of claim 9, with the indication associated with a flagged item classified as a TP. Claim 18 is rejected for the same reasons set forth above with respect to claims 9 and 17: Muddu's user interface element solicits the action command when the security-related conclusion indicates a potential security breach, and the resulting message demands termination of the application, blocking of the traffic, or removal of the account (Muddu, [0319]); in the combination, the item for which the conclusion indicates a breach is the item classified as an actual threat, which corresponds to the claimed flagged item classified as a TP. As stated in the Claim Interpretation section above, the execution of the remediation action is the intended result of the communication and, as per the Claim Interpretation section above, is being addressed arguendo, in the alternative.
Regarding claim 20, claim 20 depends from claim 19 and recites "wherein TPs are communicated for investigation and remediation; BPs are communicated for review and compliance checks; and LCs are discarded." As stated in the Claim Interpretation section above, the recited purposes of the communications are intended uses and, as per the Claim Interpretation section above, are being addressed arguendo, in the alternative; the positive acts are the communication of the TPs, the communication of the BPs, and the discarding of the LCs. Aouad provides for communicating the TPs, because the identified anomalous commands are reported to a network security administrator for analysis and possible threat remediation (Aouad, col. 8, ll. 55-60). While Aouad communicates its identified anomalous commands, Aouad does not explicitly disclose communicating benign positives or discarding legitimate commands. However, Muddu provides for communicating the BPs, because a threat tagged "False Positive" or "Reviewed" retains its tag and is presented with that tag in subsequent reviews of the threat (Muddu, [0477]). Muddu provides for discarding the LCs, because an item re-designated "Not a Threat" is deleted from the Threats View and is no longer identified as a threat (Muddu, [0460]). These are the per-classification workflows discussed for claim 17, and the rationale set forth for claim 17 applies.
Claims 2 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Aouad in view of Muddu, further in view of Beau.
Regarding claim 2, claim 2 depends from claim 1 and further recites "wherein the command-line data is a payload item that is generated based on concatenating fields associated with the first command-line." As discussed above with respect to claim 1, Aouad in view of Muddu provides for the limitations of claim 1. Aouad's command line data instances comprise the command line data received from the target computing system (Aouad, col. 6, ll. 51-65). However, while Aouad's instances comprise the command line data itself, Aouad does not explicitly disclose that the command-line data is a payload item that is generated based on concatenating fields associated with the first command-line.
Beau provides for the missing payload item. Beau discloses an observation record for a process whose features include the command line used to launch the process on the host, including any specific options, together with network information about the process and information about modules loaded by the process (Beau, [0047]); further features including the identity and type of the host that executed the process, the identity and type of the user who initiated the process, and information about the parent process and any child processes (Beau, [0048]); and encoding the raw observation record of a process as a document in a bag-of-words representation, where the individual attributes and features of the process are represented as distinct terms seen in the document (Beau, [0049]). The disclosed record corresponds to the claimed payload item generated based on concatenating fields associated with the command-line, because it combines the command line and its associated fields into one item that is treated as a single document. Beau does not provide for the two-stage global and local command-line analysis of the combination; Beau is relied upon only for its technique of combining a command line and its associated fields into a single record.
The proposed modification is to generate Aouad's command line data instances as Beau's composite records (Beau, [0047]-[0049]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because a record that carries the command line together with the fields describing its execution gives the analysis the command and its circumstances in one item, so that the same item that is scored by the global analysis also carries the user, host, and process fields used to determine its local context, as recited in claim 1. Beau, like Aouad, concerns detecting anomalous activity using records that contain command lines, and applying its record format to Aouad's command line data is a predictable use of a known record format.
Regarding claim 16, claim 16 depends from claim 10 and further recites "wherein the executing the plurality of local analysis operations comprises executing multi-factor anomaly scoring, wherein multi-factor anomaly scoring employs an isolation forest anomaly detection model to analyze command-line contextual factors for identifying deviations from an established baseline." As discussed above with respect to claim 10, Aouad in view of Muddu provides for the limitations of claim 10. Aouad's local analysis determines, utilizing a one-class SVM, whether the commands in a flagged instance are previously seen commands or variants (Aouad, col. 8, ll. 27-42). However, while Aouad's one-class SVM scores each flagged instance against previously seen commands, Aouad does not explicitly disclose multi-factor anomaly scoring that employs an isolation forest anomaly detection model to analyze command-line contextual factors for identifying deviations from an established baseline.
Beau provides for the missing isolation forest scoring. Beau discloses using an Isolation Forest to detect outliers, in which an Isolation Tree is built by recursively splitting the feature space randomly and computing the depth for each individual point, with shorter paths in the tree likely to be associated with anomalies (Beau, [0083]); merging a number of Isolation Trees into an Isolation Forest whose outlier score may be an average of the depths across the trees, with the score mapped to a score range that may be calibrated based on the scores of historical processes in the relevant category (Beau, [0084]); and using outlier detection models, such as Isolation Forest and One-Class SVM, that are trained using unsupervised learning techniques without labeled data, where each model accepts input feature vectors and generates an outlier metric that indicates a quantitative measure of how abnormal an observed process is based on historical observations (Beau, [0122]). The input feature vector built from the record's multiple features corresponds to the claimed multi-factor scoring of contextual factors, and calibrating the score against the historical processes of the category corresponds to the claimed identifying of deviations from an established baseline.
The proposed modification is to use Beau's isolation forest model (Beau, [0083]-[0084], [0122]) as the local analysis of the combination, in place of, or alongside, Aouad's one-class SVM. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because Beau discloses the Isolation Forest and the One-Class SVM as alternative outlier detection models that are trained without labeled data and that serve the same function (Beau, [0122]), so substituting the isolation forest for Aouad's one-class SVM is the predictable substitution of one known unsupervised outlier detector for another; and the isolation forest scores each flagged command-line by how far it deviates from the historical items of its own category, which provides the claimed deviation measure against an established baseline rather than only a seen-or-unseen determination.
Claims 7, 12, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Aouad in view of Muddu, further in view of Tian.
Regarding claim 7, claim 7 depends from claim 1 and further recites the operation of "employing a dynamic threshold selection to dynamical compute thresholds to classify anomaly scores to high-, medium-, or low- severity categories based on deviations from the mean." As discussed above with respect to claim 1, Aouad in view of Muddu provides for the limitations of claim 1, including anomaly scores. However, while Aouad assigns clean scores and anomalous scores based on whether command-line data instances exceed a threshold associated with known common data (Aouad, col. 6, ll. 27-34), Aouad does not explicitly disclose dynamically computing thresholds that classify the anomaly scores into high-, medium-, or low-severity categories based on deviations from the mean.
Tian provides for the missing severity classification. Tian discloses scoring each observation by its deviation from the normal behavior pattern using the Z score, or standard score, computed as the observation value minus the average value of the data set, divided by the standard deviation, where the larger the absolute value, the more likely the observation is abnormal (Tian, claim 4; [0045]). Tian further discloses dividing the range of the resulting comprehensive scores, from the minimum score to the maximum score, into five regions whose boundary values are taken from the scores themselves and are evenly distributed between the minimum and the maximum, and judging the threat level of each detection by the region its score falls in, from normal, to suspicious behavior, to mild attack, to moderate attack, to serious attack (Tian, claim 7; [0050]). The disclosed scoring corresponds to classifying anomaly scores based on deviations from the mean, because each score expresses how far the observation deviates from the data set's average; the disclosed region boundaries correspond to the claimed dynamically computed thresholds, because they are computed form the observed scores rather than fixed in advance; and the disclosed graduated threat levels correspond to the claimed high-, medium-, and low-severity categories, because both grade the scores into ordered severity bins. Tian does not provide for command-line data; Tian concerns anomaly detection for network traffic and is relied upon only for its statistical scoring and severity-classification technique, which applies to anomaly scores generally.
The proposed modification is to apply Tian's deviation-based scoring and severity classification (Tian, claim 4; claim 7; [0045], [0050]) to the anomaly scores of the Aouad-Muddu system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because grading the scores into severity categories based on how far each deviate from the mean separates the most severe detections from the marginal ones, and because Tian computes the category thresholds from the scores themselves, the categories adapt as the score distribution changes, which is the claimed dynamic threshold selection. This is a predictable use of a known statistical grading technique on the anomaly scores the combination already produces.
Regarding claim 12, claim 12 depends from claim 10 and further recites "wherein the executing the plurality of global analysis operations comprises: analyzing statistical properties of anomaly scores associated with payload items of the command-line data, wherein the statistical properties include mean and standard deviation; and dynamically computing thresholds to classify the anomaly scores into high-, medium-, or low-severity categories based on deviations from the mean." As discussed above with respect to claim 10, Aouad in view of Muddu provides for the limitations of claim 10, and Aouad's command line data instances correspond to the claimed payload items. However, Aouad does not explicitly disclose analyzing the mean and standard deviation of the anomaly scores or dynamically computing severity thresholds from deviations from the mean. Tian provides for these limitations: Tian's Z score analysis uses the average value of the data set and the standard deviation (Tian, claim 4; [0045]), which are the claimed statistical properties of mean and standard deviation, and Tian's five score regions, with boundaries computed from the observed scores, classify the scores into graduated severity levels (Tian, claim 7; [0050]), as discussed for claim 7. The rationale set forth above with respect to claim 7 applies.
Regarding claim 14, claim 14 depends from claim 10 and further recites two elements. The first element, "employing a dynamic threshold selection to dynamical compute thresholds to classify anomaly scores to high-, medium-, or low- severity categories based on deviations from the mean," is substantially identical to the additional limitation of claim 7 and is rejected for the same reasons set forth above with respect to claim 7 (Tian, claim 4; claim 7; [0045], [0050]). The second element recites "flagging one or more command-lines for local analysis based the one or more command-lines having a high- or medium- severity." Aouad provides for part of this element, because in Aouad the data instances that fail the global screen are the ones put through the SVM for the local determination (Aouad, col. 9, ll. 1-19). However, while Aouad forwards the unresolved instances for the local determination, Aouad does not explicitly disclose flagging the command-lines for local analysis based on the command-lines having a high- or medium- severity. Tian provides for this element, because Tian discloses adjusting the detection strategy based on the threat level of the detection: when the score falls in the two lowest regions, the basic detection mode with five key features is used, and when the score falls in the three highest regions, the enhanced detection mode with ten key features is used (Tian, claim 8; [0026]). Subjecting the detections in the higher severity regions to the enhanced, deeper analysis corresponds to flagging command-lines for local analysis based on their having a high or medium severity.
The proposed modification is to condition the local analysis of the combination on Tian's severity levels (Tian, claim 8; [0026]), so that the command-lines whose scores fall in the higher severity regions are the ones flagged for the local analysis. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because it directs the deeper, per-entity analysis to the detections whose severity warrants it, exactly as Tian applies its enhanced detection mode to the detections in its higher threat-level regions.
Regarding claim 19, claim 19 is interpreted as depending from claim 17, as stated in the 112(b) rejection above, and further recites "periodically updating thresholds and baselines using recent data patterns of command-lines; incorporating feedback to refine anomaly detection criteria and scoring models; and employing a weighted scoring approach that integrates the feedback." As discussed above with respect to claim 17, Aouad in view of Muddu provides for the limitations of claim 17.
For the periodic updating, while Aouad determines commonness over a configurable time period (Aouad, col. 7, l. 46 - col.8, l.7), Aouad does not explicitly disclose periodically updating thresholds and baselines using recent data patterns of command-lines. However, Muddu provides for updating baselines using recent data, because Muddu's baseline profiles are continuously updated in response to received event data, dynamically and adaptively (Muddu, [0185]). Tian provides for performing such updating periodically and for updating the detection thresholds, because Tian's system uses the latest data to update the isolation forest model and the detection strategy according to a predetermined period (Tian, claim 1, step six), and Tian's severity thresholds are computed from the observed scores (Tian, [0050]), so updating the model and strategy with the latest data updates the thresholds with it.
For incorporating feedback: Aouad does not disclose incorporating feedback to refine its detection criteria or models. However, Muddu provides for this element, because Muddu accepts feedback from a user to confirm or reject the security-related conclusion and provides that feedback to a model training process thread to update the model state (Muddu, [0319]).
For the weighted scoring approach: Aouad does not disclose a weighted scoring approach. However, Muddu provides for the weighted scoring, because Muddu discloses generating the anomaly score as a weighted linear combination of feature scores, where a weighting factor is applied to each feature score and the anomaly score is the summation of the feature scores with their weighting factors (Muddu, [0630]). Tian provides for integrating feedback into the weights, because Tian discloses dynamically adjusting the weights of its two score components based on the proportions of known and unknown features, where a feature is known if it exists in the known-threat database, and detected unknown features are recorded into the known-threat database, with the key feature base periodically adjusted and updated (Tian, claim 6, [0049]). Because the detections are recorded back into the database that determines the proportions, the weights change as the system's own findings accumulate, which corresponds to a weighted scoring approach that integrates the feedback.
The proposed modification is to add Tian's periodic updating and dynamic weight adjustment (Tian, claim 1, step six; claim 6; [0049], [0050]) to the scoring of the Aouad-Muddu combination. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because command activity changes over time, and updating the model and its thresholds on a set period using the latest data keeps the severity categories aligned with the current data patterns; and because adjusting the score weights as newly detected features are recorded into the database refines the scoring models with what the system learns, which is the claimed integration of the feedback into the weighted scoring.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Aouad in view of Muddu, further in view of Lim.
Regarding claim 6, claim 6 depends from claim 1 and further recites "wherein generating the usualness score is based on global analysis comprising applying a BM25 function to rank command-line parameters by relevance or a Log Entropy function to assess irregularity of command-line parameters; and determining the local context is based on local analysis that examines typical usage patterns to determine whether command-lines are within expected behavior for a given asset or user." As stated in the 112(b) rejection above, "the usualness score" is interpreted as the anomaly score of claim 1. The first part of the limitation is recited in the alternative, so prior art meeting either the BM25 alternative or the Log Entropy alternative is sufficient.
As discussed above with respect to claim 1, Aouad in view of Muddu provides for the limitations of claim 1, and Aouad's global analysis scores command-line data against the command line data of the environment as a whole, using extracted command line n-grams (Aouad, col. 7, ll. 23-34; col. 9, ll. 1-19). However, while Aouad's global analysis scores command-line n-grams against the corpus, Aouad does not explicitly disclose applying a BM25 function to rank command-line parameters by relevance.
Lim provides for the missing BM25 function. Lim discloses calculating a score using the BM25 algorithm, expressed as Equation 1 (Lim, [0035]), and explains its components: IDF is an inverse document frequency function that prevents excessive weight from being added to words that appear too often but lack practical meaning; f(q_i,D) is the keyword frequency, the frequency with which a specific vocabulary item appears in the set; |D| is the length of the item and avgDL is the average length of the items in the set; and k and b are hyper-parameters, where setting k adjusts the influence of an individual segment and setting b adjusts the influence of the item's length, with k and b settable, for example, to 1.2 and 0.75 (Lim, [0037]). Lim does not concern security; Lim concerns retrieving responses to queries based on semantic similarity, and Lim is relied upon solely as evidence of the known BM25 ranking function and of how that function scores the terms of a text item relative to a body of items. Lim is reasonably pertinent to the problem addressed by the claimed global analysis, because both concern scoring how significant individual text tokens are relative to a corpus, which is the same problem Aouad's corpus-level command-line screening addresses.
The proposed modification is to use Lim's BM25 function (Lim, [0035], [0037]) as the scoring function of Aouad's global analysis, applied to the command line n-grams that Aouad already extracts. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this modification, because BM25 ranks how significant each token is relative to the corpus, using the term frequencies and lengths that a corpus of command lines provides, which ranks the command-line parameters by relevance as the claim recites; this is the predictable use of a known ranking function for its established purpose. The limitation is alternatively met by the Log Entropy branch, because the applicant's own specification acknowledges that the Log Entropy function "is widely used" (Specification, [0092]), an acknowledgement that the function was a known option for this purpose.
For the second part of this limitation: while Aouad's local analysis examines the command-line's own execution history (Aouad, col. 7, l. 46 - col. 8, l. 7), Aouad does not explicitly disclose local analysis that examines typical usage patterns for a given asset or user. However, Muddu provides for the local analysis that examines typical usage patterns for a given asset or user, because Muddu discloses determining behavior baselines of entities such as users and devices and comparing the activities of those entities to their baselines to determine whether the activities are anomalous (Muddu, [0182]), including a baseline generated for a server (Muddu, [0184]), with anomalies detected by comparing incoming event data against the baseline profile for the entity to which the event data relates (Muddu, [0186]). An entity's baseline corresponds to the claimed typical usage patterns, the comparison corresponds to determining whether the activity is within expected behavior, and the user and server correspond to the claimed user and asset. The proposed modification and the reason to combine are as set forth above with respect to claims 1 and 15: evaluating a flagged command-line against the baseline of its own user or asset recognizes command-lines that are within that entity's expected behavior.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Aouad in view of Muddu, further in view of Tian and Lim.
Regarding claim 13, claim 13 depends from claim 10 and further recites "wherein the executing the plurality of global analysis operations comprises: identifying payload items of the command-line data that meet high- or medium-severity criteria based on either BM25 or Log Entropy scores; discarding low-severity anomalies to reduce false positives; forwarding flagged payload items with high- and medium-severity anomaly scores for local analysis." The severity criteria are recited as based on "either BM25 or Log Entropy scores," in the alternative, so prior art meeting either alternative is sufficient. This claim combines, in one global-analysis arrangement, features addressed individually above, and the combination is explained as one arrangement below.
As discussed above with respect to claim 10, Aouad in view of Muddu provides for the limitations of claim 10. In the arrangement of the combination: Aouad's global analysis scores the command line data instances of the environment (Aouad, col. 9, ll. 1-19); Lim's BM25 function provides the scores, for the reasons and with the rationale set forth above with respect to claim 6 (Lim, [0035], [0037]), meeting the BM25 alternative; and Tian's severity classification grades the scores into its graduated threat levels using thresholds computed from the scores themselves, for the reasons and with the rationale set forth above with respect to claim 7 (Tian, claim 7; [0050]). Identifying the items whose graded scores fall in the higher severity regions corresponds to identifying payload items that meet high- or medium- severity criteria based on BM25 scores.
For discarding low-severity anomalies: while Aouad sets aside the instances its screen resolves as common (Aouad, col. 9, ll. 1-19), Aouad does not explicitly disclose discarding low-severity anomalies. However, Muddu provides for this element, because Muddu discloses filtering out threats based on their scores, for example filtering out any threats with a score less than a chosen value when the user is only interested in evaluating high risk threats (Muddu, [0456]). Filtering the low-scoring detections out of the review corresponds to discarding low-severity anomalies, and doing so serves the claim's stated purpose of reducing false positives, because the lowest-graded detections are the ones least likely to be actual threats.
For forwarding flagged payload items with high- and medium-severity anomaly scores for local analysis, Aouad provides for the forwarding structure, because in Aouad the instances that are not resolved by the global screen are the ones put through the SVM for the local determination (Aouad, col. 9, ll. 1-19), and Tian provides for conditioning that forwarding on severity, because Tian applies its enhanced detection mode to the detections whose scores fall in the higher threat-level regions (Tian, claim 8; [0026]), as discussed above with respect to claim 14.
The proposed modification is to arrange the global analysis of the combination so that the command line data instances are scored with Lim's BM25 function, graded into Tian's severity levels, filtered by Muddu's score filter to remove the lowest-graded detections, and forwarded to the local analysis when their severity is high or medium (Lim, [0035], [0037]; Tian, claim 7, claim 8, [0026], [0050]; Muddu, [0456]; Aouad, col. 9, ll. 1-19). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make this arrangement, because each part performs its established function in sequence: the BM25 scores rank the items, the severity levels grade the ranked scores, removing the lowest-graded items keeps the local analysis focused on the detections most likely to matter, which reduces false positives as the claim recites, and forwarding the high- and medium- severity items sends the deeper analysis where the grading says it is warranted. Each reference is relied upon only for the part identified above, and the reasons for adding Lim's function and Tian's grading are those set forth for claims 6, 7, and 14, respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZAIN J AHMED whose telephone number is (571)270-0251. The examiner can normally be reached 8am - 4pm.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
