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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/16/2026 has been entered.
Response to Amendment
This office action is in response to the RCE filed on 03/05/2026. Claims 1-20 are pending. Claims 1, 15-16, and 20 are amended. Claims 1, 15, and 20 are independent.
Response to Arguments
Rejections under 35 U.S.C. § 103:
Applicant’s arguments, see pages 8-11 of applicant’s remarks (hereinafter “REMARKS”), filed 10/07/2025, with respect to the rejection of the claims under 35 U.S.C. § 103 have been fully considered and are not persuasive. Specifically, that the prior art of record Ladnai et al. (U.S. PGPub No. 2019/0258800; hereinafter “Ladnai”) in view of Zaytsev et al. (U.S. PGPub No. 2023/0344843; hereinafter “Zaytsev”) do not disclose all the limitations of the amended independent claims.
Ladnai teaches causally related events or objects, apart of a sequence, that are collected and recorded from a monitored endpoint (¶ 0004, ¶ 0008, ¶ 0013, ¶ 0107). When a beacon or trigger event is detected, information relating to the events may be analyzed to determine a root cause and identify affected computing objects, and the event that caused the trigger is identified as a security event (¶ 0084, ¶ 0092, ¶ 0095-0096). A series/sequence of events causally related to the event is uploaded for analysis (¶ 0008-0012, ¶ 0100). From the security event, and other events recorded or logged, an event graph is created by an analysis facility which may reside on the endpoint (¶ 0008-0012, ¶ 0098). The events are traversed backwards from the security event to determine the cause of the security event (¶ 0122, ¶ 0123, ¶ 0127, ¶ 0132, ¶ 0137). Filtering/pruning of computing objects from the event graph may occur where those computing objects not causally related to the root cause in some ways are removed from the event graph, i.e. they are not located on a path between the security event and the root cause (¶ 0122, ¶ 0132, ¶ 0140). The security state of the endpoint is evaluated based on the event graph, and from this the set of logical locations used for data collection at the endpoint are adjusted according to the security state, such as by removing existing logical locations (¶ 0009-0012, ¶ 0145, ¶ 0156-0157, ¶ 0159).
Applicant argues Ladnai does not teach “wherein the relationships comprise a causal relationship based on a chain of directly related entities including the entity associated with the alert”, however, Ladnai teaches causal relationships of related entities, such as those events recorded, and that the security event on the path to the root cause is a chain of related entities (¶ 0004, ¶ 0008, ¶ 0013, ¶ 0107, ¶ 0122, ¶ 0132, ¶ 0140). Applicant further argues Ladnai does not teach “and wherein determining whether to include or exclude comprises excluding data associated with the subset of the entities in response to determining that the subset of the entities has no direct relationship to the chain of directly related entities”, however, Ladnai teaches pruning those events that are a part of the events recorded but are not directly on the path between the security event detected and the root cause, and adjusting the data collected based on the security state of endpoint from the event graph (¶ 0140, ¶ 0132, ¶ 0122). Furthermore, Applicant argues that the event graph created during forensic/root-cause workflows is not a technique for controlling whether data associated with particular entities is collected in the first place, however, Ladnai teaches adjusting data collection by adjusting logical locations used for collecting data based on security state of the endpoint, which is determined from the event graph (¶ 0010-0012, ¶ 0157-0159).
Zaytsev teaches classifying the severity level of alerts for the filtered activity depending on the activity pattern type, based on whether that particular activity pattern is a stronger indication of attack (¶ 0078).
Therefore, applicant’s arguments are not persuasive, and in view of the amendments a new ground(s) of rejection is made over Ladnai in view of Zaytsev.
Regarding applicants’ arguments with respect to the dependent claims, the amendments to the independent claims have necessitated a new ground(s) of rejection with respect to independent claims from which the dependent claims depend, thereby requiring new grounds of rejection for the dependent claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-6, 9-17, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ladnai et al. (U.S. PGPub No. 2019/0258800; hereinafter “Ladnai”) in view of Zaytsev et al. (U.S. PGPub No. 2023/0344843; hereinafter “Zaytsev”).
As per claim 1: Ladnai discloses a non-transitory machine-readable storage medium comprising instructions that upon execution cause a system to (The memory 214 may include any volatile or non-volatile memory or other computer-readable medium [Ladnai ¶ 0073, Fig. 2]):
monitor operations in at least one electronic device in which entities are started, created, or modified (monitoring activity for one or more endpoints and recording the activity in a data recorder or the like … The data recorder may collect information about device activity, such as file creation, process creations, registry changes, memory injections, and so forth [Ladnai ¶ 0084, ¶ 0008, ¶ 0005, Fig. 3]; a monitoring facility [Ladnai ¶ 0085, Fig. 3]; The data recorder 320 may monitor and record activity related to the objects 312 and events 314 occurring on the endpoint 310 [Ladnai ¶ 0092]; The monitoring facility 330 may work in conjunction with the data recorder 320 to instrument the endpoint 310 so that any observable events 314 by or involving various objects 312 can be monitored and recorded [Ladnai ¶ 0094]; the endpoint 310 may include any number of computing objects 312 which may for example be processes … files or data … or any other computing objects … data, process, file or combination of these [Ladnai ¶ 0087-0088]);
generate an alert based on the monitoring, the alert being associated with a group of entities (when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security) information from the data recorder may be analyzed [Ladnai ¶ 0084]; activity of the endpoint 310 may be stored in a data log 33 … Thus, the data log 322 may include a continuous feed of events 314. When an event 314 is detected that is a beacon or a trigger event (such as a file detection, a malicious traffic detection, or the like), the data log 322 may be saved and transmitted to an analysis facility 340 or the like for analysis [Ladnai ¶ 0092, Fig. 3; Examiner’s Note: beacon or trigger event is interpreted as an alert]; detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system [Ladnai ¶ 0095-0096]; detecting a security event associated with one of the number of computing objects on the first endpoint … traversing an event graph based on the sequence of events in reverse order from the one of the computing objects associated with the security event to one or more preceding ones of the computing objects [Ladnai ¶ 0008, Examiner’s Note: event from the detection is associated with other events and objects, a graph of entities as the object causing the security event is part of a sequence of objects]; Security events may also or instead be caused by a certain combination of events or combinations of events and computing objects [Ladnai ¶ 0130]); and
adapt an amount of data collected based on contextual information associated with the alert (A data recorder stores endpoint activity on an ongoing basis as sequence of events that causally relate computer objects such as processes and files, and patterns with this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time [Ladnai, ¶ 0009, ¶ 0094, abstract, Fig. 3, Fig. 6, adjust monitoring and data collection]), wherein the adapting of the amount of data collected comprises determining whether to include or exclude data associated with a subset of the group of entities based on a type of relationship of the subset to the group of entities (detecting a security event associated with one of the number of computing objects on the first endpoint [Ladnai ¶ 0008, ¶ 0120]; excluding at least one of the plurality of logical locations associated with a known, good process [Ladnai ¶ 0012]; a number of computing objects at a plurality of logical locations within a computing environment on the endpoint, selecting a set of logical locations from the plurality of logical locations, recording a sequence of events causally relating the number of computing objects at the set of logical locations, creating an event graph based on the sequence of events, evaluating a security state of the endpoint based on the event graph, adjusting the set of logical locations by adding a new logical location, removing an existing logical location, or changing a level of filtering at one of the set of logical locations according to the security state of the endpoint [Ladnai ¶ 0010]; excluding at least one of the plurality of logical locations associated with a known, good process [Ladnai ¶ 0012]; selecting a second set of logical locations different from the first set of logical locations in response to an observed event graph for the sequence of events … adding one or more of the plurality of logical locations in response to a detected increase in security risk … removing one of the plurality of logical locations from the first set of logical locations in response to detected decrease in security .. filtering one or more of the events in the sequence of events according to reputation [Ladnai ¶ 0012]; monitor a number of causal relationships among a number of computing objects at a plurality of logical locations within a computing environment related to the endpoint … recording a sequence of events causally relating the number of computing objects at the first set of logical locations… The processor may be further configured to adjust the set of logical locations by adding a new logical location, removing an existing logical location, or changing a level of filtering at one of the set of logical locations according to a security state of the endpoint [Ladnai ¶ 0013]; when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security), information from the data recorder may be analyzed (e.g., start at the trigger event) to determine a root cause and to determine affected computing objects … An event graph may be generated showing connected events that are causally related to the detected event [Ladnai ¶ 0084, ¶ 0088-0089, ¶ 0091, ¶ 0121, ¶ 0132, Fig. 3]; a series of events/processes related to the detected event that may be uploaded for execution/analysis [Ladnai ¶ 0100]; monitoring may be adapted to a current security context [Ladnai ¶ 0145-0149, ¶ 0159, Fig. 6]), [wherein the type of relationship is based on a severity of the alert], wherein the relationships comprise a causal relationship based on a chain of directly related entities including the entity associated with the alert (a first endpoint, a data recorder instrumented to monitor a number of causal relationships among a number of computing objects on the first endpoint and to record a sequence of events casually relating the number of computing objects [Ladnai ¶ 0008]; detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system [Ladnai ¶ 0095-0096]; detecting a security event associated with one of the number of computing objects on the first endpoint … traversing an event graph based on the sequence of events in reverse order from the one of the computing objects associated with the security event to one or more preceding ones of the computing objects [Ladnai ¶ 0008, Examiner’s Note: event from the detection is associated with other events and objects, a graph of entities as the object causing the security event is part of a sequence of objects]; Security events may also or instead be caused by a certain combination of events or combinations of events and computing objects [Ladnai ¶ 0130]; the event graph 500 may be stored in any suitable data structure or combination of data structures suitable for capturing the chain of events and objects in a manner that preserves causal relationships for use in forensics and malware detection as contemplated herein [Ladnai ¶ 0134]), and wherein determining whether to include or exclude comprises excluding data associated with the subset of the entities in response to determining that the subset of the entities has no direct relationship to the chain of directly related entities (The event graph 500 may include one or more computing objects or events that are not located on a path between the security event 502 and the root cause 504. These computing objects or events may be filtered or 'pruned' from the event graph 500 when performing a root cause analysis or an analysis to identify other computing objects affected by the root cause 504 or the security event 502 [Ladnai ¶ 0140, Examiner’s Note: objects or events that are not located on a path between the security event and the root cause which are then pruned]; the method 400 may include traversing the event graph forward from an identified or presumed cause of the security event to identify one or more other ones of the computing objects affected by the cause. In this manner, an analysis of each of the computing objects in the event graph may be conducted by working forward from the root cause to other causally dependent computing objects that might be compromised or otherwise affected by the root cause. This may include labeling or otherwise identifying the potentially compromised objects, e.g. for remediation or further analysis. A pruning step may also be employed, e.g. where any computing objects that are not causally dependent on the root cause in some way are removed from the event graph [Ladnai ¶ 0132]; variety of filtering techniques may be usefully employed. For example, certain types of objects or events may be removed from an event graph for specific trigger events, or certain groups of events may be condensed into a single event, such as all normal activity that occurs when a user logs into an endpoint. Similarly, computing objects that are too remote, either within the event graph or timewise, may be pruned and removed, particularly if they have a known, low diagnostic significance. Thus, the event graph may be filtered and condensed in a variety of manners to obtain a useful snapshot of events optimized for root cause analytics. Filtering of the data may be dependent upon the type of security event that is detected. Filtering of the data may adjust the level of detail included in the event graph based on memory limits, user parameters, security event type, or any other object metrics or inputs. In an aspect, the data is filtered based on reputation or the like, e.g., of computing objects included therein. For example, if an application has a good reputation, the application may not include a high level of detail associated therewith in a filtered version of the data log [Ladnai ¶ 0122]; evaluating a security state of the endpoint based on the event graph, such as by applying a malware detection rule to the event graph … comparing current event graph to other patterns of events that show a causal relationship among computing objects that is suggestive or indicative of malicious activity [Ladnai ¶ 0157, Fig. 6]; adjusting the set of logical locations according to the security state of the endpoint ... removing an existing logical location … changing a level of filtering at one of the set of logical locations according to the security state of the endpoint [Ladnai ¶ 0159]).
Ladnai discloses the claimed subject matter as discussed above but does not explicitly disclose wherein the type of relationship is based on a severity of the alert. However, Zaytsev teaches wherein the type of relationship is based on a severity of the alert (In some examples, the analysis component 118 may analyze the observed behavioral events, including cross-machine activities, to determine if a second host device connected to the host device(s) 102 is potentially compromised [Zaytsev ¶0035]; the detection component 308 may classify the severity level for the filtered activity depending on the activity pattern type, based on whether that particular activity pattern type is a stronger indication of attack. That is, an activity pattern with explicit threat data showing obvious suspicious activity pattern on a remote system may be classified as a high severity level, while an activity pattern with inferred threat data showing signs of suspicious activity pattern may be classified as a medium severity level [Zaytsev ¶ 0078]; The analysis component 310 determines a fidelity score for each of the host device 200 based at least in part on the filtered behavioral events from the detection component 308, the time period of the observed activity pattern, and the classification of severity level. If the fidelity score is above a predetermined severity threshold, an alert for an analyst may be generated for further analysis … the fidelity score for a host device may be based on the severity level of the filtered behavioral events associated with the host device, such that if even one of the behavioral events is classified as high severity level, the fidelity score may be set to a value higher than the predetermined severity threshold … In some examples, the analysis component 310 may increase a first fidelity score on a first host device by at least a portion of a second fidelity score of a second host device that is acting remotely on the first host device. Additionally, and/or alternatively, host devices with “interesting” remoting behavioral events between them may be grouped together into a group of behavioral events and a fidelity score may be determined for the group. The group fidelity score may be based on the highest fidelity score for any one device in the group, or may be based on the cardinality of the set of filtered behavioral events associated with all the devices in the group. [Zaytsev ¶ 0081]; The mitigation component 312 may generate alerts for an analyst to further investigate a possible attack on a host device 200 or generate notifications of interesting behavioral events that need further analysis. Additionally, to help draw attention to high severity level behavioral events or activity pattern groups, the mitigation component 312 may establish a threat alert priority scheme to help prioritize the presentation of behavioral events and alerts. The threat alert priority scheme may be based on the fidelity score, severity level, alert timeline, or any combination thereof. For example, the behavioral events and alerts may be ranked according to their severity level, followed by fidelity scores, so that the behavioral events and alerts with highest severity level are presented first, sorted by the highest fidelity scores first; then the next severity level is presented, sorted by the highest fidelity scores first… The visualization component 314 may enable an analyst, who is associated with the security service system, to view notifications of observed behavioral events, alerts pertaining to the host device 200 that have been compromised, and make decisions regarding appropriate responses to those behavioral events and alerts [Zaytsev ¶ 0082-0083]). Ladnai and Zaytsev are analogous art because they are from the same field of endeavor of security alerts. Therefore, based on Ladnai in view of Zaytsev, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Zaytsev to the system of Ladnai in order to indicate a severity level of the event so as to prioritize making decisions for and responding to higher severity security events that may involve cross-machine activities or groups of devices. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 2: Ladnai in view of Zaytsev teach all the limitations of claim 1. Furthermore, Ladnai discloses wherein the contextual information associated with the alert (when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security) information from the data recorder may be analyzed [Ladnai ¶ 0084, ¶ 0092, ¶ 0095-0096, ¶ 0113]; The data recorder 320 may monitor and record activity related to the objects 312 and events 314 occurring on the endpoint 310 … stored in a data log [Ladnai ¶ 0092]; the data log 322 may include data from a single endpoint 310, or from a number of endpoints 310 [Ladnai ¶ 0101]) indicates a severity of the alert (the detection component 308 may classify the severity level for the filtered activity depending on the activity pattern type, based on whether that particular activity pattern type is a stronger indication of attack. That is, an activity pattern with explicit threat data showing obvious suspicious activity pattern on a remote system may be classified as a high severity level, while an activity pattern with inferred threat data showing signs of suspicious activity pattern may be classified as a medium severity level [Zaytsev ¶ 0078]; The analysis component 310 determines a fidelity score for each of the host device 200 based at least in part on the filtered behavioral events from the detection component 308, the time period of the observed activity pattern, and the classification of severity level. If the fidelity score is above a predetermined severity threshold, an alert for an analyst may be generated for further analysis … the fidelity score for a host device may be based on the severity level of the filtered behavioral events associated with the host device, such that if even one of the behavioral events is classified as high severity level, the fidelity score may be set to a value higher than the predetermined severity thresh old [Zaytsev ¶ 0081]; The mitigation component 312 may generate alerts for an analyst to further investigate a possible attack on a host device 200 or generate notifications of interesting behavioral events that need further analysis. Additionally, to help draw attention to high severity level behavioral events or activity pattern groups, the mitigation component 312 may establish a threat alert priority scheme to help prioritize the presentation of behavioral events and alerts. The threat alert priority scheme may be based on the fidelity score, severity level, alert timeline, or any combination thereof. For example, the behavioral events and alerts may be ranked according to their severity level, followed by fidelity scores, so that the behavioral events and alerts with highest severity level are presented first, sorted by the highest fidelity scores first; then the next severity level is presented, sorted by the highest fidelity scores first… The visualization component 314 may enable an analyst, who is associated with the security service system, to view notifications of observed behavioral events, alerts pertaining to the host device 200 that have been compromised, and make decisions regarding appropriate responses to those behavioral events and alerts [Zaytsev ¶ 0082-0083]), and wherein the group of entities is selected based on the contextual information (selecting a second set of logical locations different from the first set of logical locations in response to an observed event graph for the sequence of events [Ladnai ¶ 0012, ¶ 0149-0150]).
As per claim 3: Ladnai in view of Zaytsev teaches all the limitations of claim 1. Furthermore, Ladnai discloses wherein the contextual information associated with the alert indicates a risk to the at least one electronic device (when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security), information from the data recorder may be analyzed (e.g., starting at the trigger event) [Ladnai ¶ 0084, ¶ 0095-0096]; The security event may be any beacon or trigger event … an event that is related to network security, computer security, data security, data leakage, data exposure, or any other actual potential security issue … the security event may include an actual comprise to a network, an endpoint or a computer system such as the detection of malware or any other threat detection [Ladnai ¶ 0113, ¶ 0112]; detecting a security event associated with one of the number of computing objects may trigger further analysis of other causally related computing objects on an endpoint to identify a cause of the security event [Ladnai ¶ 0120]; generating an event graph. The event graph may be generated in response to detecting the security event e.g., using the data log from the data recorder … include the sequence of events causally relating the number of computing objects, and more specifically, the sequence of events and computer objects causally associated with the object(s) that triggered the detected security event [Ladnai ¶ 121]), and wherein the adapting of the amount of data collected comprises increasing the amount of data collected in response to a higher risk to the at least one electronic device (adding one or more of the plurality of logical locations to the first set of logical locations in response to a detected increase in security risk [Ladnai ¶ 0012-0013, ¶ 0009, ¶ 0149]; monitoring may be adapted to a current security context, e.g., by adding more monitoring points or decreasing filtering (e.g., to gather more data at each point) when the security state worsens or there is a perceived increase in security risk [Ladnai ¶ 0145, ¶ 0147]).
As per claim 5: Ladnai in view of Zaytsev teaches all the limitations of claim 1. Furthermore, Ladnai discloses wherein the contextual information associated with the alert indicates a uniqueness of an anomaly indicated by the alert (the beacon or trigger event on the endpoint 310 may signal an unusual behavior that is known to commonly appear concurrently with the detection of malware … when the beacon or trigger event is a suspicious behavior, the data log 322 may be analyzed differently than when the beacon or trigger event is a confirmed malicious behavior [Ladnai ¶ 0096]), and wherein the adapting of the amount of data collected is based on the uniqueness of the anomaly (a series of events/processes related to the detected event that may be uploaded for execution/analysis. This analysis may thus include executing this series of events/processes in the same order to determine a threat level for the endpoint 310 [Ladnai ¶ 0100]; Once a root cause has been identified as described above, the event graph proximal to the root cause can be used to detect malware based on the emergence of a similar or identical event graph during malware monitoring [Ladnai ¶ 0145]; adapting the monitored locations according to a security state of the endpoint so that more or less computing resources can be used as necessary or appropriate according to the current state of risk [Ladnai ¶ 0149]).
As per claim 6: Ladnai in view of Zaytsev teaches all the limitations of claim 5. Furthermore, Ladnai discloses wherein the uniqueness of the anomaly is based on a pattern of one or more entities giving rise to the alert (the beacon or trigger event on the endpoint 310 may signal an unusual behavior that is known to commonly appear concurrently with the detection of malware … when the beacon or trigger event is a suspicious behavior, the data log 322 may be analyzed differently than when the beacon or trigger event is a confirmed malicious behavior [Ladnai ¶ 0096]; A data recorder stores endpoint activity on an ongoing basis as sequences of events that causally relate computer objects such as processes and files, and patterns within this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time [Ladnai ¶ 0009]; comparing the event graph to other patterns of events that show a causal relationship among computing objects that is suggestive or indicative of malicious activity [¶ 0157, ¶ 0087-0092]).
As per claim 9: Ladnai in view of Zaytsev teaches all the limitations of claim 1. Furthermore, Ladnai discloses wherein the instructions upon execution cause the system to: classify the alert, wherein the contextual information comprises a type of the alert produced by the classifying (Filtering of the data may be dependent upon the type of security event that is detected … security event type [Ladnai ¶ 0122]; the cause identification rule may associate the cause of the security event with a combination that includes a first process invoking a second process and providing data to the second process … A cause identification rule may specify a particular type of invocation relationship between two processes, or multiple types of invocation, or any relationship between two processes [Ladnai ¶ 0130]; traversing the event graph forward from an identified or presumed cause of the security event [Ladnai ¶ 0132]).
As per claim 10: Ladnai in view of Zaytsev teaches all the limitations of claim 1. Furthermore, Ladnai discloses wherein the alert is generated for a first electronic device (when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security) information from the data recorder may be analyzed [Ladnai ¶ 0084, ¶ 0092, ¶ 0095-0096, ¶ 0113]), and the adapting of the amount of data collected is of data in a second electronic device different from the first electronic device (The plurality of logical locations may include at least one endpoint separate from the first endpoint [Ladnai ¶ 0012, ¶ 0007, Examiner’s Note: adapting data collection at another device]; The processor may be further configured to adjust the set of logical locations by adding a new logical location, removing an existing logical location, or changing a level of filtering at one of the set of logical locations according to a security state of the endpoint [Ladnai ¶ 0013, ¶ 0012, ¶ 0122, ¶ 0145]; the logical locations may be any corresponding locations of diagnostic interest that might be accessed or used by the computing objects within the computing environment … In one aspect, this may include logical locations separate from the endpoint, such as locations on a second physical endpoint separate from the first endpoint, or a website, file server, mail server, or other remote resource [Ladnai ¶ 0146, ¶ 0149]).
As per claim 11: Ladnai in view of Zaytsev teaches all the limitations of claim 10. Furthermore, Ladnai discloses wherein the contextual information comprises contextual information associated with the first electronic device (The data recorder 320 may monitor and record activity related to the objects 312 and events 314 occurring on the endpoint 310 … stored in a data log [Ladnai ¶ 0092]; the data log 322 may include data from a single endpoint 310, or from a number of endpoints 310 [Ladnai ¶ 0101]).
As per claim 12: Ladnai in view of Zaytsev teaches all the limitations of claim 11. Furthermore, Ladnai discloses wherein the adapting of the amount of data collected is performed by the system that is part of a cloud service (the data recorder 320 and the monitoring facility 330 and the analysis facility may also or instead be realized as remote services instantiated on a virtual appliance, a public or private cloud, or the like, any of which may be coupled to the endpoint 310 through the data network 350 [Ladnai ¶ 0085, ¶ 0093-0094, ¶ 0097-0098, Fig. 1, Fig. 3]; A data recorder stores endpoint activity on an ongoing basis as sequence of events that causally relate computer objects such as processes and files, and patterns with this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time [Ladnai, ¶ 0009, ¶ 0094, abstract, Fig. 3, Fig. 6, adjust monitoring and data collection]) communicatively coupled to a plurality of electronic devices including the first and second electronic devices (any of which may be coupled to the endpoint 310 through the data network 350 [Ladnai ¶ 0085]; The plurality of logical locations may include at least one endpoint separate from the first endpoint [Ladnai ¶ 0012, Examiner’s Note: adapting data collection at another device]; monitoring activity for one or more endpoints and recording the activity in a data recorder or the like [Ladnai ¶ 0084]; this may include logical locations separate from the endpoint, such as locations on a second physical endpoint separate from the first endpoint [Ladnai ¶ 0146]).
As per claim 13: Ladnai in view of Zaytsev teaches all the limitations of claim 1. Furthermore, Ladnai discloses wherein the adapting of the amount of data collected is based on an intelligence context specified by the contextual information (excluding at least one of the plurality of logical locations associated with a known, good process [Ladnai ¶ 0012]; selecting logical locations may including adapting the monitoring based on observed properties within a computing environment. For example, computing objects such as files or processes may be explicitly labeled with information about reputation, exposure to external networks, usage history, security status, and so forth … These and other techniques may be usefully employed to label computing objects in any manner useful for evaluating a security state to adapt the monitoring processes contemplated herein [Ladnai ¶ 0150]).
As per claim 14: Ladnai in view of Zaytsev teaches all the limitations of claim 1. Furthermore, Ladnai discloses wherein the entities comprise any or some combination of processes, objects, resources, and users (The data recorder 320 may monitor and record activity related to the objects 312 and events 314 occurring on the endpoint 310 [Ladnai ¶ 0092]; The monitoring facility 330 may work in conjunction with the data recorder 320 to instrument the endpoint 310 so that any observable events 314 by or involving various objects 312 can be monitored and recorded [Ladnai ¶ 0094]; The one or more computing objects may include one or more types of computing objects selected from a group consisting of a data file, a process, an application, a registry entry, a network address, and a peripheral device [Ladnai ¶ 0012, ¶ 0087-0088, ¶ 0091, ¶ 0104]; A peripheral 222 may include any device used to provide information to or receive information from the computing deice 200 … or other device that might be employed by the user 230 to provide input to the computing device 210 [Ladnai ¶ 0079]; the events may include human interactions such as keyboard strokes, mouse clicks or other input and output [Ladnai ¶ 0102]).
As per claim 15: Ladnai discloses a security system comprising:
one or more processors (the computing device 210 may include a processor 212 [Ladnai ¶ 0071-0072, Fig. 2]); and
a non-transitory storage medium storing instructions executable on the one or more processors to (The memory 214 may store information within the computing device 210 … any volatile or non-volatile memory … memory 214 may store program instructions [Ladnai ¶ 0071, ¶ 0073, Fig. 2]):
monitor operations in at least one electronic device in which entities are started, created, or modified (monitoring activity for one or more endpoints and recording the activity in a data recorder or the like … The data recorder may collect information about device activity, such as file creation, process creations, registry changes, memory injections, and so forth [Ladnai ¶ 0084, ¶ 0008, ¶ 0005, Fig. 3]; a monitoring facility [Ladnai ¶ 0085, Fig. 3]; The data recorder 320 may monitor and record activity related to the objects 312 and events 314 occurring on the endpoint 310 [Ladnai ¶ 0092]; The monitoring facility 330 may work in conjunction with the data recorder 320 to instrument the endpoint 310 so that any observable events 314 by or involving various objects 312 can be monitored and recorded [Ladnai ¶ 0094]; the endpoint 310 may include any number of computing objects 312 which may for example be processes … files or data … or any other computing objects … data, process, file or combination of these [Ladnai ¶ 0087-0088]);
generate an alert based on the monitoring, the alert being associated with a group of entities (when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security) information from the data recorder may be analyzed [Ladnai ¶ 0084]; activity of the endpoint 310 may be stored in a data log 33 … Thus, the data log 322 may include a continuous feed of events 314. When an event 314 is detected that is a beacon or a trigger event (such as a file detection, a malicious traffic detection, or the like), the data log 322 may be saved and transmitted to an analysis facility 340 or the like for analysis [Ladnai ¶ 0092, Fig. 3; Examiner’s Note: beacon or trigger event is interpreted as an alert]; detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system [Ladnai ¶ 0095-0096]; detecting a security event associated with one of the number of computing objects on the first endpoint … traversing an event graph based on the sequence of events in reverse order from the one of the computing objects associated with the security event to one or more preceding ones of the computing objects [Ladnai ¶ 0008, Examiner’s Note: event from the detection is associated with other events and objects, a graph of entities as the object causing the security event is part of a sequence of objects]; Security events may also or instead be caused by a certain combination of events or combinations of events and computing objects [Ladnai ¶ 0130]); and
adapt an amount of data collected based on contextual information associated with the alert (A data recorder stores endpoint activity on an ongoing basis as sequence of events that causally relate computer objects such as processes and files, and patterns with this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time [Ladnai, ¶ 0009, ¶ 0094, abstract, Fig. 3, Fig. 6, adjust monitoring and data collection]), wherein the adapting of the amount of data collected comprises determining whether to include or exclude data associated with a subset of the group of entities based on a type of relationship of the subset to the group of entities, [wherein the type of relationship is based on a severity of the alert] (detecting a security event associated with one of the number of computing objects on the first endpoint [Ladnai ¶ 0008, ¶ 0120]; excluding at least one of the plurality of logical locations associated with a known, good process [Ladnai ¶ 0012]; a number of computing objects at a plurality of logical locations within a computing environment on the endpoint, selecting a set of logical locations from the plurality of logical locations, recording a sequence of events causally relating the number of computing objects at the set of logical locations, creating an event graph based on the sequence of events, evaluating a security state of the endpoint based on the event graph, adjusting the set of logical locations by adding a new logical location, removing an existing logical location, or changing a level of filtering at one of the set of logical locations according to the security state of the endpoint [Ladnai ¶ 0010]; excluding at least one of the plurality of logical locations associated with a known, good process [Ladnai ¶ 0012]; selecting a second set of logical locations different from the first set of logical locations in response to an observed event graph for the sequence of events … adding one or more of the plurality of logical locations in response to a detected increase in security risk … removing one of the plurality of logical locations from the first set of logical locations in response to detected decrease in security .. filtering one or more of the events in the sequence of events according to reputation [Ladnai ¶ 0012]; monitor a number of causal relationships among a number of computing objects at a plurality of logical locations within a computing environment related to the endpoint … recording a sequence of events causally relating the number of computing objects at the first set of logical locations… The processor may be further configured to adjust the set of logical locations by adding a new logical location, removing an existing logical location, or changing a level of filtering at one of the set of logical locations according to a security state of the endpoint [Ladnai ¶ 0013]; when a beacon or trigger event is detected (e.g., an event pertinent to computer or network security), information from the data recorder may be analyzed (e.g., start at the trigger event) to determine a root cause and to determine affected computing objects … An event graph may be generated showing connected events that are causally related to the detected event [Ladnai ¶ 0084, ¶ 0088-0089, ¶ 0091, ¶ 0121, ¶ 0132, Fig. 3]; a series of events/processes related to the detected event that may be uploaded for execution/analysis [Ladnai ¶ 0100]; monitoring may be adapted to a current security context [Ladnai ¶ 0145-0149, ¶ 0159, Fig. 6]), wherein the relationships comprise a causal relationship based on a chain of directly related entities including the entity associated with the alert (a first endpoint, a data recorder instrumented to monitor a number of causal relationships among a number of computing objects on the first endpoint and to record a sequence of events casually relating the number of computing objects [Ladnai ¶ 0008]; detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system [Ladnai ¶ 0095-0096]; detecting a security event associated with one of the number of computing objects on the first endpoint … traversing an event graph based on the sequence of events in reverse order from the one of the computing objects associated with the security event to one or more preceding ones of the computing objects [Ladnai ¶ 0008, Examiner’s Note: event from the detection is associated with other events and objects, a graph of entities as the object causing the security event is part of a sequence of objects]; Security events may also or instead be caused by a certain combination of events or combinations of events and computing objects [Ladnai ¶ 0130]; the event graph 500 may be stored in any suitable data structure or combination of data structures suitable for capturing the chain of events and objects in a manner that preserves causal relationships for use in forensics and malware detection as contemplated herein [Ladnai ¶ 0134]), and wherein determining whether to include or exclude comprises excluding data associated with the subset of the entities in response to determining that the subset of the entities has no direct relationship to the chain of directly related entities (The event graph 500 may include one or more computing objects or events that are not located on a path between the security event 502 and the root cause 504. These computing objects or events may be filtered or 'pruned' from the event graph 500 when performing a root cause analysis or an analysis to identify other computing objects affected by the root cause 504 or the security event 502 [Ladnai ¶ 0140, Examiner’s Note: objects or events that are not located on a path between the security event and the root cause which are then pruned]; the method 400 may include traversing the event graph forward from an identified or presumed cause of the security event to identify one or more other ones of the computing objects affected by the cause. In this manner, an analysis of each of the computing objects in the event graph may be conducted by working forward from the root cause to other causally dependent computing objects that might be compromised or otherwise affected by the root cause. This may include labeling or otherwise identifying the potentially compromised objects, e.g. for remediation or further analysis. A pruning step may also be employed, e.g. where any computing objects that are not causally dependent on the root cause in some way are removed from the event graph [Ladnai ¶ 0132]; variety of filtering techniques may be usefully employed. For example, certain types of objects or events may be removed from an event graph for specific trigger events, or certain groups of events may be condensed into a single event, such as all normal activity that occurs when a user logs into an endpoint. Similarly, computing objects that are too remote, either within the event graph or timewise, may be pruned and removed, particularly if they have a known, low diagnostic significance. Thus, the event graph may be filtered and condensed in a variety of manners to obtain a useful snapshot of events optimized for root cause analytics. Filtering of the data may be dependent upon the type of security event that is detected. Filtering of the data may adjust the level of detail included in the event graph based on memory limits, user parameters, security event type, or any other object metrics or inputs. In an aspect, the data is filtered based on reputation or the like, e.g., of computing objects included therein. For example, if an application has a good reputation, the application may not include a high level of detail associated therewith in a filtered version of the data log [Ladnai ¶ 0122]; evaluating a security state of the endpoint based on the event graph, such as by applying a malware detection rule to the event graph … comparing current event graph to other patterns of events that show a causal relationship among computing objects that is suggestive or indicative of malicious activity [Ladnai ¶ 0157, Fig. 6]; adjusting the set of logical locations according to the security state of the endpoint ... removing an existing logical location … changing a level of filtering at one of the set of logical locations according to the security state of the endpoint [Ladnai ¶ 0159]).
Ladnai discloses the claimed subject matter as discussed above but does not explicitly disclose wherein the type of relationship is based on a severity of the alert. However, Zaytsev teaches wherein the type of relationship is based on a severity of the alert (the detection component 308 may classify the severity level for the filtered activity depending on the activity pattern type, based on whether that particular activity pattern type is a stronger indication of attack. That is, an activity pattern with explicit threat data showing obvious suspicious activity pattern on a remote system may be classified as a high severity level, while an activity pattern with inferred threat data showing signs of suspicious activity pattern may be classified as a medium severity level [Zaytsev ¶ 0078]; The analysis component 310 determines a fidelity score for each of the host device 200 based at least in part on the filtered behavioral events from the detection component 308, the time period of the observed activity pattern, and the classification of severity level. If the fidelity score is above a predetermined severity threshold, an alert for an analyst may be generated for further analysis … the fidelity score for a host device may be based on the severity level of the filtered behavioral events associated with the host device, such that if even one of the behavioral events is classified as high severity level, the fidelity score may be set to a value higher than the predetermined severity thresh old [Zaytsev ¶ 0081]; The mitigation component 312 may generate alerts for an analyst to further investigate a possible attack on a host device 200 or generate notifications of interesting behavioral events that need further analysis. Additionally, to help draw attention to high severity level behavioral events or activity pattern groups, the mitigation component 312 may establish a threat alert priority scheme to help prioritize the presentation of behavioral events and alerts. The threat alert priority scheme may be based on the fidelity score, severity level, alert timeline, or any combination thereof. For example, the behavioral events and alerts may be ranked according to their severity level, followed by fidelity scores, so that the behavioral events and alerts with highest severity level are presented first, sorted by the highest fidelity scores first; then the next severity level is presented, sorted by the highest fidelity scores first… The visualization component 314 may enable an analyst, who is associated with the security service system, to view notifications of observed behavioral events, alerts pertaining to the host device 200 that have been compromised, and make decisions regarding appropriate responses to those behavioral events and alerts [Zaytsev ¶ 0082-0083]). Ladnai and Zaytsev are analogous art because they are from the same field of endeavor of security alerts. Therefore, based on Ladnai in view of Zaytsev, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Zaytsev to the system of Ladnai in order to indicate a severity level of the event so as to prioritize making decisions for and responding to higher severity security events. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 16: Ladnai in view of Zaytsev teaches all the limitations of claim 15. Furthermore, Ladnai discloses wherein the adapting of the amount of data collected comprises excluding the data associated with the subset (A data recorder stores endpoint activity on an ongoing basis as sequence of events that causally relate computer objects such as processes and files, and patterns with this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time [Ladnai, ¶ 0009, ¶ 0094, abstract, Fig. 3, Fig. 6, adjust monitoring and data collection]; excluding at least one of the plurality of logical locations associated with a known, good process [Ladnai ¶ 0012]) in response to: the contextual information indicating any of the following: a lower severity of the alert, a lower risk of the alert (removing one of the plurality of locations from the first set of logical locations in response to a detected decrease in security risk [Ladnai ¶ 0012]; adjusting the set of logical locations according to the security state of the endpoint ... removing an existing logical location … changing a level of filtering at one of the set of logical locations according to the security state of the endpoint [Ladnai ¶ 0159]), a lower uniqueness of the alert, or a lower frequency of the alert.
As per claim 17: Ladnai discloses all the limitations of claim 15 above. The limitations of claim 17 are substantially similar to claim 2 above, and therefore the claim is likewise rejected.
As per claim 18: Ladnai in view of Zaytsev teaches all the limitations of claim 15. The limitations of claim 18 are substantially similar to claim 3 above, and therefore the claim is likewise rejected.
As per claim 19: Ladnai in view of Zaytsev teaches all the limitations of claim 15 above. The limitations of claim 19 are substantially similar to claim 5 above, and therefore the claim is likewise rejected.
As per claim 20: Ladnai in view of Zaytsev teaches all the limitations of claim 15 above. The limitations of claim 20 are substantially similar to claim 15 above, and therefore the claim is likewise rejected.
Claims 4 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Ladnai in view of Zaytsev further in view of AGRANONIK et al. (U.S. PGPub No. 2023/0344860; hereinafter “AGRANONIK”).
As per claim 4: Ladnai in view of Zaytsev teach all the limitations of claim 3. Furthermore, Ladnai discloses wherein the risk to the at least one electronic device is based on (The security event may be any beacon or trigger event … an event that is related to network security, computer security, data security, data leakage, data exposure, or any other actual potential security issue … the security event may include an actual comprise to a network, an endpoint or a computer system such as the detection of malware or any other threat detection [Ladnai ¶ 0113, ¶ 0112]; detecting a security event associated with one of the number of computing objects may trigger further analysis of other causally related computing objects on an endpoint to identify a cause of the security event [Ladnai ¶ 0120]) [a quantity of alerts occurring in the at least one electronic device in a time interval].
Ladnai in view of Zaytsev discloses the claimed subject matter as discussed above but does not explicitly disclose a quantity of alerts occurring in the at least one electronic device in a time interval. However, AGRANONIK teaches a quantity of alerts occurring in the at least one electronic device in a time interval (FIG. 13 shows a data pipeline 1300 for the org level incrimination, which combines org level anomaly detection with supervised learning. The pipeline represents a supervised learning approach to finding org level ransomware incidents using alerts. This approach looks at types of alerts and at the velocity of the alert across the organization using time series. Grouping 1302 may reduce data volume substantially, e.g., by 95% in some cases. One kind of grouping 1302 is by alert time and distinct machine count, and another is by wall clock time and distinct machine count. Guardrail filtering may require, e.g., at least five distinct machines for data to pass forward to anomaly detection 904. Anomaly detection 904 in this example uses time series on distinct machine counts per alert per hour. Selection 1306 may then filter by forwarding only data from an X hour window before the apparent anomaly, e.g., with X=1, 2, or 3. Data may be reduced by taking only rows with anomalies [AGRANONIK ¶ 0109, ¶ 0139, See table line 27, if Count(C) > T5 or distinct(C) > T6 -> Report org level ransomware incident, where A = all alerts in orgAlerts in window of X days]). Ladnai in view of Zaytsev and AGRANONIK are analogous art because they are from the same field of endeavor of security alerts. Therefore, based on Ladnai in view of Zaytsev further in view of AGRANONIK, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of AGRANONIK to the system of Ladnai in view of Zaytsev in order to improve responses by using the quantity of the alerts in a time window as a measure for further security incident alerts. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 7: Ladnai in view of Zaytsev all the limitations of claim 6. Furthermore, Ladnai discloses wherein the anomaly (the beacon or trigger event on the endpoint 310 may signal an unusual behavior that is known to commonly appear concurrently with the detection of malware … when the beacon or trigger event is a suspicious behavior, the data log 322 may be analyzed differently than when the beacon or trigger event is a confirmed malicious behavior [Ladnai ¶ 0096]) is more unique if [a quantity of occurrence] of the pattern detected in the at least one electronic device (the endpoint 310 [Ladnai ¶ 0096, Fig. 3]) is lower (an unusual behavior that is known to commonly appear concurrently with the detection of malware [Ladnai ¶ 0096]).
Ladnai in view of Zaytsev discloses the claimed subject matter as discussed above but does not explicitly disclose a quantity of occurrence. However, AGRANONIK teaches a quantity of occurrence (FIG. 13 shows a data pipeline 1300 for the org level incrimination, which combines org level anomaly detection with supervised learning. The pipeline represents a supervised learning approach to finding org level ransomware incidents using alerts. This approach looks at types of alerts and at the velocity of the alert across the organization using time series. Grouping 1302 may reduce data volume substantially, e.g., by 95% in some cases. One kind of grouping 1302 is by alert time and distinct machine count, and another is by wall clock time and distinct machine count. Guardrail filtering may require, e.g., at least five distinct machines for data to pass forward to anomaly detection 904. Anomaly detection 904 in this example uses time series on distinct machine counts per alert per hour. Selection 1306 may then filter by forwarding only data from an X hour window before the apparent anomaly, e.g., with X=1, 2, or 3. Data may be reduced by taking only rows with anomalies [AGRANONIK ¶ 0109, ¶ 0139, See table line 27, if Count(C) > T5 or distinct(C) > T6 -> Report org level ransomware incident, where A = all alerts in orgAlerts in window of X days]). Ladnai in view of Zaytsev and AGRANONIK are analogous art because they are from the same field of endeavor of security alerts. Therefore, based on Ladnai in view of Zaytsev in view of AGRANONIK, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of AGRANONIK to the system of Ladnai in view of Zaytsev in order to improve responses by using the quantity of the alerts in a time window as a measure for further security incident alerts. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ladnai in view of Zaytsev in view MONASTYRSKY et al. (U.S. PGPub No. 2018/0365416; hereinafter “MONASTYRSKY”).
As per claim 8: Ladnai in view of Zaytsev teach all the limitations of claim 1. Furthermore, Ladnai discloses wherein the contextual information associated with the alert indicates [a frequency of occurrence of an anomaly] indicated by the alert (The data recorder 320 may monitor and record activity related to the objects 312 and events 314 occurring on the endpoint 310 … stored in a data log [Ladnai ¶ 0092]; the data log 322 may include data from a single endpoint 310, or from a number of endpoints 310 [Ladnai ¶ 0101]), and wherein the adapting of the amount of data collected is based on (the method may further include adding one or more of the plurality of logical locations to the first set of logical locations in response to a detected increase in security risk [Ladnai ¶ 0012, ¶ 0149-0150]; adapting the monitored locations according to a security state of the endpoint so that more or less computing resources can be used as necessary or appropriate according to the current state of risk [Ladnai ¶ 0149]) [the frequency of occurrence of the anomaly].
Ladnai in view of Zaytsev discloses the claimed subject matter as discussed above but does not explicitly disclose a frequency of occurrence of an anomaly; the frequency of occurrence of the anomaly. However, MONASTYRSKY teaches a frequency of occurrence of an anomaly (the operating system of the computing device during execution of a software process [¶ 0008]; determining a popularity of the formed convolution of the detected at least one event by polling a database containing data relating to a frequency of a plurality of detected events occurring in a plurality of client devices [¶ 0008, ¶ 0045-0046, ¶ 0036, ¶ 0045-0046, Fig. 1]; the frequency of the plurality of detected events comprises at least one of a total number of the plurality of detected events at a current moment of time when the at least one event is detected and a total number of client devices each experiencing the detected at least one event at the current moment of time [¶ 0015]; the polling of the database comprises at least one of polling of a global database associated with a first plurality of client devices within all accessible subnetworks and polling of a local data associated with a second plurality of client devices within a single subnetwork of devices [¶ 0016]); the frequency of occurrence of the anomaly (the operating system of the computing device during execution of a software process [¶ 0008]; determining a popularity of the formed convolution of the detected at least one event by polling a database containing data relating to a frequency of a plurality of detected events occurring in a plurality of client devices [¶ 0008, ¶ 0045-0046, ¶ 0036, ¶ 0045-0046, Fig. 1]; the frequency of the plurality of detected events comprises at least one of a total number of the plurality of detected events at a current moment of time when the at least one event is detected and a total number of client devices each experiencing the detected at least one event at the current moment of time [¶ 0015]; the polling of the database comprises at least one of polling of a global database associated with a first plurality of client devices within all accessible subnetworks and polling of a local data associated with a second plurality of client devices within a single subnetwork of devices [¶ 0016]). MONASTYRSKY and the instant application are analogous art because they are from the same field of endeavor of malicious software detection. Therefore, based on Ladnai in view of Zaytsev in view of MONASTYRSKY, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of MONASTYRSKY to the system of Ladnai in view of Zaytsev in order to detect new techniques of exploitation of vulnerabilities given the frequency of events occurring across a plurality of devices (In other words, events from the operating system include anything "outside" of the program that can affect how the program behaves. It should be appreciated that such events can occur at any time while the program is running, in almost any order [¶ 0031]; an "anomalous" event is an identified manifestation of a certain condition of an operating system, a service or a network indicating the occurrence of a previously unknown situation. In a particular instance, an anomalous event is a secure event-an identified manifestation of a certain condition of a system, a service or a network indicating a possible violation of the information security policy or a failure of defensive measures, or the occurrence of a previously unknown state which may have a relation to security [¶ 0032]; Existing detection technologies are in fact capable of detecting the actual exploiting of a vulnerability with the use of known techniques and mechanisms, but unfortunately these methods are not able to detect and prevent new techniques of exploitation of vulnerabilities that employ new principles and mechanisms of exploitation [¶ 0005]; In view of these new solutions, there remains a need to detect a deviation in the functioning of a computer system from normal operation, which might indicate that the system has been attacked by a technique of exploiting a vulnerability in the software. The solving of this problem would make it possible to move away from the techniques of exploitation of vulnerabilities themselves, which are changing and improving, to focus on external symptoms of an attack, which remain the same when the techniques change [¶ 0006]; In other words, the popularity is being considered for the frequency of a plurality of detected events that correspond to the detected event of the client device 100 to determine how often the event is occurring in the set of the plurality of devices, for example [¶ 0045]. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES P MOLES whose telephone number is (703)756-1043. The examiner can normally be reached M-F 8:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jung Kim can be reached at (571) 272-3804. 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.
/JAMES P MOLES/Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494