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 12/24/2025 has been entered.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant argues that the combination of Noeth, Ettema, and Hartrell does not teach “threat management facility identifying additional data pertaining to the malware threat that is stored in the data recorder and was previously excluded by the filter from the filtered event stream [and] requesting the additional data stored by the data recorder including the one or more changes to the registry of system settings by non-system processes caused by the root cause and occurring during the window of time after the root cause and before detection of the predetermined security state on the endpoint" as recited in claim 1.” In response, it is noted that [0014] and [0038] of Hartrell identifying a root cause based on obtaining event snapshot data for analysis: “ten computer system users visit a web site using their personal computers… Each of the ten computer systems become infected with a known spyware application, served by the web site… provides a snapshot of the last five minutes and subsequent five minutes of local system and network activity to a centralized data store. The malware analysis system then normalizes the snapshot data on the centralized data store, and conducts commonality analysis on the ten provided snapshots to find any recurring activities. The malware analysis system performs the commonality analysis and discovers that each of these ten computer systems visited the same web site within one minute prior to the infection;” “the malware analysis system can provide a snapshot of the last ten minutes of the monitored activities (e.g., local system activity, network activity, etc.) prior to the detection of the infection. This snapshot may be referred to as a "pre-infection snapshot." In some embodiments, the malware analysis system can provide the snapshot of the activities to a remote (e.g., centralized) data store. The snapshot of the activities can then be analyzed to determine the "root cause" or source of the infection (i.e., the activities that led to the infection), including, for example, how the infected computer system was discovered, how the infected computer system was accessed, what operating system objects were manipulated, and the like.” The cited portions of Hartrell further include requesting additional information within the time window of the root cause: “malware analysis system may request additional information regarding monitored activities during the same time period from other security event sources, such as, by way of example, egress firewalls, and receive the additional snapshots from each of these sources. The malware analysis system can then perform further commonality analysis on the newly provided snapshots.” The cited portions then disclose remediation: “malware analysis system may alert the system operator of all ten infected computer systems to the pattern, and provide a recommendation to block this web site at their organization's egress points to prevent future infections. In addition, malware analysis system may alert the system operator of the several other system systems that may be infected with the spyware or other malware, since these other computer systems also visited or were contacted by the known "bad" web site.” As such, the applied prior art teaches monitoring activities on computer systems, obtaining snapshots for analysis, determining a root cause, and obtaining additional information from around the determined time window.
Additionally, at least [0029], [0044]-[0045], [0057], and [0067] of Noeth describe sending log information to, e.g., a cloud store, for analysis. Additionally, [0034], [0040], and [0069] of Noeth concern adjusting a filter responsive to analysis while at least [0019] and [0037]-[0039] of Hartrell disclose the monitored activities including registry changes by processes.
As such, the applied combination of references is considered to teach the amended claim language.
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.
Claim(s) 1, 6, 10-21, 23-25, and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Noeth (US 2018/0307833 A1) in view of Hartrell (US 2007/0150957 A1) and Ettema (US 2018/0332005 A1).
Regarding claim 1, Noeth discloses: A computer program product comprising computer executable code embodied in a non-transitory computer readable medium that, when executing on one or more computing devices, performs the steps of:
instrumenting an endpoint (e.g., user computing devices 20 in one or more subnets 12 in FIG. 1 of Noeth) managed by a threat management facility (e.g., security event processing system 14 in FIG. 1 of Noeth) for an enterprise network (e.g., [0003] and [0021] of Noeth concerning networks such as those in FIG. 1 being business/enterprise networks) with a local agent (driver and agent on a host as in [0030] and [0037] of Noeth) to detect a plurality of types of changes to a registry of system settings for an operating system on the endpoint (the driver and agent detect changes to registry settings as in [0068] of Noeth);
Refer to at least [0025], [0030]-[0031], [0042], [0044], [0068], and [0133] of Noeth with respect to obtaining telemetry information including network traffic and events such as registry changes by the driver and agent on the host. The driver and agent “conduct forensic processes, e.g., accessing memory, file, registry… to gather data” and create a “local data store of gathered information and sends telemetry data to cloud store… can send regular telemetry events or urgent notifications/alert messages to the cloud data store” as in [0042]-[0045] of Noeth.
creating an event stream from the local agent including each type of change to the registry of system settings detected on the endpoint; storing the event stream in a data recorder (e.g., memory in FIG. 1 and 6; [0055] of Noeth) on the endpoint;
Refer to at least [0044]-[0045], [0057], and [0069] of Noeth with respect to the driver and agent recording obtained telemetry information for sending it to the security event processing system.
processing the event stream with a filter at the endpoint to provide a filtered event stream including a subset of the types of changes to the registry of system settings;
Refer to at least [0005], [0025], [0031]-[0034], [0040], [0066], and [0068]-[0070] of Noeth with respect to a filter implemented by the driver and agent, and associated with the telemetry information. For instance, the driver part performs filtering and as in [0032]-[0034] of Noeth; while the agent part “appl[ies] the threat-classification criteria to the report of the network packet and the forensic record” and “may apply various criteria to determine whether the resulting aggregate information indicates a potential attack is occurring, and in some cases report this information into the cloud” in [0005] and [0067] of Noeth; where the security event processing system may “instruct agents to… adjust criteria” as in [0070] of Noeth.
transmitting the filtered event stream to the threat management facility;
Refer to at least [0029], [0044]-[0045], [0057], and [0067] of Noeth with respect to the driver and agent sending the obtained telemetry information to the security event processing system.
processing the filtered event stream at the threat management facility to evaluate a security state of the endpoint;
Refer to at least [0048]-[0052], [0070], and [0084] of Noeth with respect to the security event processing system performing security analysis on the obtained telemetry information.
in response to a predetermined security state indicating a malware threat, (i) identifying additional data previously excluded by the filter (i.e., data not previously sent as part of the telemetry—e.g., [0098] of Noeth) from the filtered event stream, and (iv) requesting the additional data stored by the data recorder;
Refer to at least [0048], [0050], and [0070] of Noeth with respect to the security event processing system detecting anomalies, pattern matches, policy violations, and/or other indications of malware. Responsive to the detection, the security event processing system tasks the offending system/agent for more corroborating evidence/data.
correlating the additional data with the malware threat;
Refer to at least [0025], [0048], and [0067] of Noeth with respect to the security event processing system aggregating, consolidating, and dynamically adjusting analyses on hosts based information obtained.
Refer to at least [0092] of Noeth with respect to an example where the security event processing system determines an indication of malware, requests corroborating evidence/data, and uses the received corroborating evidence/data to identify a hacker and provide instructions for remediation.
in response to correlating the additional data with the malware threat, transmitting, to the endpoint, an adjustment to the filter on the endpoint for use in filtering the event stream that is transmitted to the threat management facility to evaluate the security state of the endpoint, the adjustment associated with at least one of the types of changes in the additional data correlated with the malware threat;
Refer to at least [0025], [0046], [0050], [0053], and [0070] of Noeth with respect to the security event processing system tasking remediation to the driver and agent via the agent, where the remediation may include adjustments to the filter as in [0034], [0040], and [0069] of Noeth.
further in response to correlating the additional data with the malware threat, transmitting a second adjustment to one or more other filters on one or more other endpoints managed by the threat management facility, the second adjustment based on the adjustment transmitted to the endpoint and the second adjustment controlling the one or more other filters on the one or more other endpoints to communicate the types of changes in the additional data correlated with the malware threat; and
Refer to at least [0025], [0050], [0061], [0070], and [0084] of Noeth with respect to the security event processing system tasking plural agents (and respective drivers) with remediation based on its analyses. As per above, the remediation may include adjustments to the filter as in [0034], [0040], and [0069] of Noeth.
Refer to at least [0096] of Noeth with respect to an example where the security event processing system sending tasks to plural agents responsive to an analysis.
selecting events for a second event stream on a second endpoint of the one or more other endpoints based on the second adjustment for transmission to the threat management facility to facilitate detection by the threat management facility of the malware threat on the second endpoint.
Refer to at least [0032]-[0034], [0066], and [0092] of Noeth with respect to hosts modifying what telemetry information is obtained based on security event processing system tasks.
Noeth does not specify: wherein identifying additional data comprises identifying additional data pertaining to the malware threat that is stored in the data recorder and was previously excluded by the filter from the filtered event stream, (ii) wherein identifying the additional data includes identifying a root cause of the predetermined security state that occurred before the predetermined security state and is causally related to the predetermined security state, (iii) wherein identifying the additional data further includes identifying one or more changes to the registry of system settings by non-system processes caused by and occurring during a window of time after the root cause and before detection of the predetermined security state on the endpoint; requesting the additional data further including the one or more changes to the registry of system settings by non-system processes caused by the root cause and occurring during the window of time after the root cause and before detection of the predetermined security state on the endpoint; the adjustment being such that the filter, after the adjustment, captures in the filtered event stream the at least one of the types of changes associated with the additional data including changes to the registry of system settings by non-system processes, among the changes to the registry of system settings on the endpoint. However, Noeth in view of Hartrell discloses: (ii) wherein identifying the additional data includes identifying a root cause of the predetermined security state that occurred before the predetermined security state and is causally related to the predetermined security state,
Refer to at least [0014] of Hartrell with respect to “analy[sis] to determine the "root cause" or source of the infection (i.e., the activities that led to the infection), including, for example, how the infected computer system was discovered, how the infected computer system was accessed, what operating system objects were manipulated, and the like.”
(iii) wherein identifying the additional data further includes identifying one or more changes to the registry of system settings by non-system processes (e.g., “process id, user security context, logical storage identity from which data originated, logical storage identity where the change occurred, network sources such as uniform resource locator (URL) or internet protocol (IP) address, the API call used to make the change” in [0019] of Hartrell) caused by and occurring during a window of time after the root cause and before detection of the predetermined security state on the endpoint;
Refer to at least [0019] and [0037]-[0038] of Hartrell with respect to, e.g., “runtime monitoring of the operating system resources for changes to the file system, common file formats, configurations (registry)… or any other operating system object… monitor component may be configured to record information regarding the monitored activity… Upon receiving the notification, the system activity monitor component creates and provides a time-bounded snapshot of activities that occurred before and/or after the notification of infection to the other components of the malware analysis system.”
requesting the additional data further including the one or more changes to the registry of system settings by non-system processes caused by the root cause and occurring during the window of time after the root cause and before detection of the predetermined security state on the endpoint.
Refer to at least [0038] of Hartrell, where “malware analysis system may request additional information regarding monitored activities during the same time period from other security event sources, such as, by way of example, egress firewalls, and receive the additional snapshots from each of these sources. The malware analysis system can then perform further commonality analysis on the newly provided snapshots. For example, the malware analysis system may discover additional computer systems that have visited the same web site, as well as several other computer systems that have been contacted by the web site in return.” According to the cited portions of Hartrell, the root cause may be, e.g., “discover[ing] that each of these ten computer systems visited the same web site within one minute prior to the infection” as in [0038]; and the monitored activities include registry changes as in [0019] and [0037]-[0038].
The teachings of Hartrell likewise concern collecting and analyzing endpoint security information, as well as remediation. As such, they are considered to be within the same field of endeavor and combinable.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth to further implement obtaining snapshots of information relevant to a suspected infection and performing root cause analysis for at least the reasons specified in [0003] of Hartrell (i.e., helping to better assess the cause and scope of malware).
Although Hartrell discusses filtering in [0021] and [0035], Noeth-Hartrell does not fully specify: the adjustment being such that the filter, after the adjustment, captures in the filtered event stream the at least one of the types of changes associated with the additional data including changes to the registry of system settings by non-system processes, among the changes to the registry of system settings on the endpoint. However, Noeth-Hartrell in view of Ettema discloses: the adjustment being such that the filter, after the adjustment, captures in the filtered event stream the at least one of the types of changes associated with the additional data including changes to the registry of system settings by non-system processes, among the changes to the registry of system settings on the endpoint.
Refer to at least [0138] of Ettema with respect to a malicious event analysis triggering collection of all instrumented data collected from hosts to deliver all host-based and network-based artifacts that might be present, such as modified files, Windows registry changes, network requests, behavioral summary, etc., for each host that was “touched” by the attacker. As per at least [0066] of Ettema, attackers include APTs or other advanced threats (e.g., malicious software can include any malicious computer code or executable program, such as active content, executable code, and scripts).
The teachings of both Ettema likewise concern collecting and analyzing endpoint security information, as well as remediation. As such, they are considered to be within the same field of endeavor and combinable.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth-Hartrell to further specify collection of additional instrumented data including all registry changes on hosts touched by an attacker during an attack window, for at least the purpose of improving detection and signature accuracy (i.e., having more data allows for identification of finer distinctions between malicious and non-malicious patterns).
Regarding independent claim 6, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claim 10, it is rejected for substantially the same reasons as claim 1 above (i.e., receiving the telemetry information at the security event processing system—e.g., [0048]-[0053] of Noeth).
Regarding claim 11, Noeth-Hartrell-Ettema discloses: The method of claim 6 further comprising storing an unfiltered event stream on the data recorder at the endpoint, the unfiltered event stream including additional ones of the plurality of types of changes to the registry of system settings.
Refer to at least [0042], [0068], and [0133] of Noeth with respect to storing a forensic record concerning a registry state and accesses.
Refer to at least [0138] of Ettema with respect to forensics report comprising all windows registry changes.
This claim would have been obvious for substantially the same reasons as claim 6 above.
Regarding claim 12, it is rejected for substantially the same reasons as claim 11 above (i.e., the citations and obviousness rationale).
Regarding claim 13, Noeth-Hartrell-Ettema discloses: The method of claim 6 wherein processing the filtered event stream includes searching for potential malicious activity on the endpoint.
Refer to at least [0048], [0084], and [0092] of Noeth with respect to the security event processing system analyzing received host information for malicious activity.
Regarding claim 14, Noeth-Hartrell-Ettema discloses: The method of claim 6 wherein processing the filtered event stream includes searching for a security exposure on the endpoint.
Refer to at least [0135] of Ettema with respect to techniques for determining which client devices or other endpoints have been exposed to the malware (e.g., received network communications for a compromised device(s)) such that these devices can be remediated using various malware remediation techniques.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth-Ettema to further determine malware exposure for endpoints during analysis for at least the purpose of prioritizing remediation for affected endpoints; and because exposed endpoints may provide additional malware information for further analysis (e.g., an attack having multiple vectors over a target network).
Regarding claim 15, Noeth-Hartrell-Ettema discloses: The method of claim 6 further comprising, when the filtered event stream shows that the security state of the endpoint is compromised, initiating a remedial action.
Refer to at least [0048], [0050], and [0070] with respect to the security event processing system initiating remedial actions.
Regarding claim 16, it is rejected for substantially the same reasons as claim 6 above (i.e., citations concerning analysis of obtained host information at the security event processing system).
Regarding claims 17-18, they are rejected for substantially the same reasons as claim 6 above (i.e., citations concerning dynamically adjusting analyses on hosts responsive to attacks detected on other hosts; the obviousness rationale).
Regarding independent claim 19, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claim 20, it is rejected for substantially the same reasons as claim 15 above.
Regarding claim 21, Noeth-Hartrell-Ettema discloses: The computer program product of claim 1 wherein the endpoint is further configured to periodically transmit a snapshot of aggregated, unfiltered data from the data recorder to the threat management facility for remote storage.
Refer to at least [0037] of Noeth with respect to periodic surveys of host information by the agent and driver, to send to the security event processing system.
Refer to at least [0114] of Ettema with respect to a periodic snapshot of a client device.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth-Ettema to further implement a periodic snapshot of host information for at least the purpose of keeping fresh configuration information at the security event processing system.
Regarding claim 23, Noeth-Hartrell-Ettema discloses: The computer program product of claim 1 wherein the threat management facility further includes a machine learning model for identifying potentially malicious activity on the endpoint based on the filtered event stream.
Refer to at least [0043] and [0048]-[0053] of Noeth with respect to a machine learning model for identifying malicious activity.
Regarding claim 24, it is rejected for substantially the same reasons as claim 1 above (e.g., [0025] and [0092] of Noeth; [0138] of Ettema; the obviousness rationale).
Regarding claims 25, it is substantially similar to claims 21, and is therefore likewise rejected.
Regarding claim 30, it is rejected for substantially the same reasons as claim 6 above (i.e., the citations to Noeth concerning the kernel driver and kernel-level monitoring—e.g., [0029] of Noeth).
Claim(s) 22 and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Noeth-Hartrell-Ettema as applied to claims 1, 6, 10-21, 23-25, and 30 above, and further in view of Milford (US 7,155,514 B1).
Regarding claim 22, Noeth-Hartrell-Ettema does not disclose: wherein the endpoint is further configured to delete records in the data recorder corresponding to the snapshot in order to free memory on the endpoint for additional recording. However, Noeth-Ettema in view of Milford discloses: wherein the endpoint is further configured to delete records in the data recorder corresponding to the snapshot in order to free memory on the endpoint for additional recording.
Refer to at least Col. 2, Ll. 12-14 of Milford with respect to overwriting old event log entries when the logs become full.
The teachings of Milford likewise concern event logs, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth-Hartrell-Ettema to further implement deleting telemetry information for the reasons discussed in the cited portion of Milford (i.e., to prevent storage becoming full and to free space).
Regarding claim 26, it is substantially similar to claim 22 above, and is therefore likewise rejected.
Claim(s) 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Noeth-Hartrell-Ettema as applied to claims 1, 6, 10-21, 23-25, and 30 above, and further in view of Shraim (US 2017/0243000 A1).
Regarding claim 29, Noeth-Hartrell-Ettema discloses: The method of claim 6, wherein the filtered event stream includes one or more events from a low-level kernel driver;
Refer to at least [0005] of Noeth with respect to the kernel driver for monitoring events. It further noted that Ettema also teaches kernel level hooks for monitoring as in [0028] and [0071].
Noeth-Hartrell-Ettema does not specify: installed in a kernel space of the endpoint during an operating system boot process. However, Noeth-Hartrell-Ettema in view of Shraim discloses: installed in a kernel space of the endpoint during an operating system boot process.
Refer to at least [0039] of Shraim with respect to dynamically loading a kernel-mode driver at startup to provide monitoring.
The teachings of Shraim likewise concern a kernel driver for security monitoring, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth-Hartrell-Ettema to further implement dynamically loading a kernel-mode driver at startup for at least the purpose of providing no traceable evidence of monitoring as described in [0039] of Shraim.
Claim(s) 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Noeth-Hartrell-Ettema as applied to claims 1, 6, 10-21, 23-25, and 30 above, and further in view of Bhave (US 2007/0143223 A1).
Regarding claim 31, Noeth-Hartrell-Ettema does not disclose: wherein requesting the additional data includes requesting data from a tamper protection cache stored in a kernel of the endpoint and protected against tampering by one or more tamper protection tools. However, Noeth-Hartrell-Ettema in view of Bhave discloses: wherein requesting the additional data includes requesting data from a tamper protection cache stored in a kernel of the endpoint and protected against tampering by one or more tamper protection tools.
Refer to at least [0050]-[0051] of Bhave with respect to a tamper-protected kernel memory cache; at least [0030] of Bhave with respect to requesting cache information.
The teachings of Bhave likewise concern computer security and kernel level protection, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Noeth-Hartrell-Ettema to further implement tamper protected cache memory for the kernel driver monitoring and reporting for at least the purpose of maintaining the integrity of reported data (e.g., so the threat cannot rewrite data reported for analysis).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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
/V.S/ Examiner, Art Unit 2432
Prosecution Insights