Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
2. NO restrictions warranted at initial time of filing for patent.
Priority
3. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. GB2214371.5, filed on 05/30/2022.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 01/27/2024, the submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Oath/Declaration
5. Applicant’s Oath was filed on 1/17/2024.
Drawings
6. Applicant’s drawings filed on 11/27/2024 has been inspected and is in compliance with MPEP 608.01.
Specification
7. Applicant’s specification filed on 11/27/2024 has been inspected and is in compliance with MPEP 608.02.
Claim Objections
8. NO objections warranted at initial time of filing for patent.
Remarks
9. Examiner request Applicant review relevant prior art under the conclusion of this office action.
Allowable Subject Matter
10. Claims 6, 9, 16-18 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The 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.
11. Claims 1-5, 7, 8, 10-15 and 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 8176527 hereinafter Njemanze in view of U.S. Publication No. 20230247048 hereinafter Samosseiko.
As per claim 1, Njemanze discloses:
A cybersecurity platform for detecting potential cybersecurity threats pertaining to a set of computer infrastructure (Col. 2 Lines 23-26 “A rules engine with support for time-based rules is disclosed. A method performed by the rules engine, comprises receiving security events generated by a number of network devices. The security events are aggregated. One or more time-based rules are provided to a RETE engine.”), the cybersecurity platform comprising:
event storage configured to receive and store multiple forms of telemetry pertaining to the set of computer infrastructure (Col. 2 Lines 58-64 “Described herein is a computer-based system for the identification and processing of security events from heterogeneous sources, including a correlation engine with support for time-based rules. The system (one embodiment of which is manifest as computer software), implements a method that comprises receiving security events generated by a number of network devices. The security events are aggregated.”),
in the form of structured telemetry events having a common data format, the multiple forms of telemetry having been processed into the structured telemetry events having the common data format based a plurality of predetermined telemetry data schemas (Col. 6 Lines 53-58 “Each of these agents receives the event information from its associated network device or application in that device's or application's native format and converts (or normalizes) the information to a common schema. This normalization allows for later storage of the event information in a format that can more readily be utilized by an analyst.”)
at least one memory storing computer-readable instructions, and at least one processor coupled to the at least one memory and configured to execute the computer-readable instructions (Col. 3 Lines 48-65),
which upon execution cause the at least one processor to implement:
a threat detection component operable to receive a configuration input, the threat detection component configurable based on the configuration input to apply a plurality of signature-based detection rules to the multiple forms of telemetry (Col. 4 Lines 19-22 “ Managers 14 are server-based components that further consolidate, filter and cross-correlate events received from the agents, employing a rules engine 18 and a centralized event database 20.” Col. 10 Lines 29-30 “Rules may be created at the manager 14 and/or at the consoles 16 using a flexible scripting language.”),
wherein the threat detection component is configured to apply the plurality of signature-based detection rules by executing a pattern recognition algorithm, based on the target pattern, on the target data field of each structured telemetry event having the target data field, and cause a detection output to be generated based on detecting the target pattern in the target data field of a structured telemetry event (Col. 12 Line 65 – Col. 13 Line 7 “RETE engine 430 implements the RETE algorithm which scales to many hundreds of rules while its performance is independent of the number of rules it considers. In operation, RETE engine 430 loads user-written rules, that are time-based and once the rule is active, engine 430 analyzes the events provided by memory manager 420 and generates a first stage meta-event which can result in the performance of an action in response to the correlated events. More specifically, the RETE engine 430, reports instances where the rules are satisfied.”)
Njemanze does not disclose:
wherein each signature-based detection rule is defined in the configuration input and comprises:
a reference to a target data field within the set of predetermined telemetry data schemas, and a target pattern indicative of a potential cybersecurity threat;
Samosseiko discloses:
wherein each signature-based detection rule is defined in the configuration input and comprises: a reference to a target data field within the set of predetermined telemetry data schemas, and a target pattern indicative of a potential cybersecurity threat (para 0191 “In general, the threat management facility may match the endpoint telemetry (e.g., detections) with the indicator of breach signatures or rules to create the first set of indicators. Each indicator of breach may include one or more fields, such as a name, a filter, a weight, a time (e.g., a specific time or range of times associated with underlying detections) and a description. Each indicator of breach may include indicia of one or more types of staging activity such as remote machine login attempts, changes to anti-malware software, lateral movement attempts, software installations, presence of low or unknown reputation files, and attempted access to low or unknown reputation network locations. A set of these indicators of breach may then collectively provide a signature for a specific malware tool, or otherwise be associated with a specific tool or type of malware tool, which facilitates useful forensic grouping of various types of activities by time and by type.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention a rules engine with support for time-based rules of Njemanze to include wherein each signature-based detection rule is defined in the configuration input and comprises: a reference to a target data field within the set of predetermined telemetry data schemas, and a target pattern indicative of a potential cybersecurity threat, as taught by Samosseiko.
The motivation would have been to detect sustained attempts at breach across an entity's entire network attack surface, and the ability to respond to this targeting with heightened security before an actual compromise occurs.
As per claim 2, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein the multiple forms of telemetry comprise at least two of the following forms of telemetry: network telemetry obtained via monitoring of network traffic within the set of computer infrastructure, endpoint telemetry collected using a plurality of endpoint agents executed on a plurality of endpoint devices of the set of computer infrastructure, and cloud telemetry pertaining to cloud-based infrastructure of the set of infrastructure, third-party telemetry comprising cybersecurity analysis results generated independently of the cybersecurity platform (Njemanze Col. 4 Lines 9-12 “Agents 12 are software programs that provide efficient, real-time (or near real-time) local event data capture and filtering from a variety of network security devices and/or applications.” Col. 10 Line 56-67 “In general, the rules may be designed to capture threats and attacks that are typical in large, diverse networks and may be organized to provide multiple lines of defense by detecting specific activities and grouping them according to level of threat: Reconnaissance zone transfer, port scan, protocol, scanning, etc. Suspicious illegal outgoing traffic, unusual levels of alerts from the same host, etc. Attack overflow, IDS evasion, virus, denial of service, etc. Successful compromise of a backdoor, root compromise, covert channel exploit, etc.”)
As per claim 3, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein each structured telemetry event includes one or more field keys identifying one or more data fields, and the reference to the target data has the form of a field name string, wherein the cybersecurity platform comprises: a mapping component configured to receive a field key or message topic from the threat detection component and return a corresponding field name string for comparing with the reference to the target data field (Njemanze Col. 7 Line 26-37 “Each of the agents 12 is configured to extract the relevant data from events reported by its associated network device/application and map that data to the corresponding common schema representation. For instance the Check Point firewall reports a target port as www-http, not as port 80 as is the case for most other network devices. Therefore an agent 12 associated with the Check Point firewall is configured with an appropriate lookup mechanism (e.g., a table) to ensure that "www-http" as reported by the firewall gets translated into "port 80" when the agent 12 reports the event to the manager 14.) and (Samosseiko para 0191 “Though Njemanze discloses data fields, Samosseiko each structured telemetry event includes one or more field keys identifying one or more data fields, and the reference to the target data has the form of a field name string. The motivation would have been to detect sustained attempts at breach across an entity's entire network attack surface, and the ability to respond to this targeting with heightened security before an actual compromise occurs).
As per claim 4, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 3, wherein each signature-based detection rule includes an indication of a pattern matching mode associated with the target pattern and the target data field; and wherein the mapping component is configured to return a field type associated with a field key, wherein responsive to identifying the target data field in a structured telemetry event, the threat detection component is configured to determine whether the pattern matching mode is compatible with a field type of the target data field (Njemanze Col. 10 Lines 19-28 “When incoming events match a particular rule's conditions and thresholds, causing a meta-event to be generated (step 44), the rule automatically fires the action that has been defined (step 46). Such actions can include, but are not limited to: executing a pre-determined command or script, logging the alert, sending the alert to the consoles 16, sending the alert to notification designees, setting custom severity levels for the alert based on cumulative activity, adding a source to a suspicious list or a target to a vulnerable list, and/or a combination of these actions.”) and (Samosseiko Fig. 14, para 0191 and 0194, Though Njemanze discloses data fileds, Samosseiko each structured telemetry event includes one or more field keys identifying one or more data fields. The motivation would have been to detect sustained attempts at breach across an entity's entire network attack surface, and the ability to respond to this targeting with heightened security before an actual compromise occurs).
As per claim 5, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 4, wherein the threat detection component is configured to indicate a plurality of type-specific callback functions to the mapping component, and the threat detection component is configured to return the field type implicitly by calling back a callback function specific to that field type Njemanze Col. 9 Line 66- Col. 8 “In other words, the rules engine 18 provides the ability to determine what type of incident is represented by a collection of events reported by a number of heterogeneous network devices and/or applications. Because the collected event data is normalized into a common event schema, correlation can be performed utilizing any field including, but not limited to, geography, device type, source, target, time thresholds, and/or event type. Based on alerts generated by the rules engine 18, operators are provided with a workflow for investigating these incidents.” Col. 13 Lines 38-40 “Although the functional blocks of a rules engine are depicted in one embodiment within rules engine 18, one or more of these functional blocks can be distributed in other systems.”) and (Samosseiko para 0007 “ The threat management facility may be configured by non-transitory computer executable code stored in a memory to perform the steps of receiving detections from the local security agents executing on the plurality of endpoints, each one of the detections including one of the customer identifiers associated with one of a number of customers, identifying a first set of indicators in the detections associated with use of a first malware tool on the plurality of endpoints, identifying a second set of indicators in the detections associated with use of a second malware tool on the plurality of endpoints, grouping the first and second sets of indicators by customer, identifying a progressive deployment of malware on an enterprise network for one of the customers based on a sequential use of the first malware tool and the second malware tool in a pattern indicating a malicious breach of the enterprise network;” Also see, para 0071, 0160, 0172 and 0191. There executable instructions within the threat facility must include function calls to map to each component with the proper fields type. Though Njemanze discloses data fields, Samosseiko threat detection component is configured to indicate a plurality of type-specific callback functions to the mapping component. The motivation would have been to detect sustained attempts at breach across an entity's entire network attack surface, and the ability to respond to this targeting with heightened security before an actual compromise occurs).
As per claim 7, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein each signature-based detection rule contains a triggering condition defined in terms of the target pattern and the target data field, wherein a detection output is generated responsive to determining that the triggering condition is satisfied by at least one structured telemetry event (Njemanze Col. 9 Lines 15-18 “Meta-events, in the context of the present invention, are instances of (usually) multiple individual event data elements (gathered from heterogeneous sources) that collectively satisfy one or more rule conditions such that an action is triggered.” Col. 10 Lines 19-28 “When incoming events match a particular rule's conditions and thresholds, causing a meta-event to be generated (step 44), the rule automatically fires the action that has been defined (step 46). Such actions can include, but are not limited to: executing a pre-determined command or script, logging the alert, sending the alert to the consoles 16, sending the alert to notification designees, setting custom severity levels for the alert based on cumulative activity, adding a source to a suspicious list or a target to a vulnerable list, and/or a combination of these actions.”)
As per claim 8, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 7, wherein each signature-based detection rule contains at least one detection output type indicator associated with the triggering condition (Njemanze Figs. 2 and 3, Col. 9 Lines 15-18 “Meta-events, in the context of the present invention, are instances of (usually) multiple individual event data elements (gathered from heterogeneous sources) that collectively satisfy one or more rule conditions such that an action is triggered.” Col. 10 Lines 19-28 “When incoming events match a particular rule's conditions and thresholds, causing a meta-event to be generated (step 44), the rule automatically fires the action that has been defined (step 46). Such actions can include, but are not limited to: executing a pre-determined command or script, logging the alert, sending the alert to the consoles 16, sending the alert to notification designees, setting custom severity levels for the alert based on cumulative activity, adding a source to a suspicious list or a target to a vulnerable list, and/or a combination of these actions.”)
As per claim 11, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 7, wherein at least one structured telemetry event contains multiple target patterns and/or references to multiple target data fields, and multiple triggering conditions associated with multiple detection output types, the multiple triggering conditions defined in terms of the multiple target patterns and/or the multiple target data fields (Njemanze Col. 6 Lines 53-58 “Each of these agents receives the event information from its associated network device or application in that device's or application's native format and converts (or normalizes) the information to a common schema. This normalization allows for later storage of the event information in a format that can more readily be utilized by an analyst.” and Col. 9 Line 66- Col. 8 “In other words, the rules engine 18 provides the ability to determine what type of incident is represented by a collection of events reported by a number of heterogeneous network devices and/or applications. Because the collected event data is normalized into a common event schema, correlation can be performed utilizing any field including, but not limited to, geography, device type, source, target, time thresholds, and/or event type. Based on alerts generated by the rules engine 18, operators are provided with a workflow for investigating these incidents.”) and (Samosseiko para 0185 and 0191, Though Subramanya discloses telemetry, Samosseiko wherein at least one structured telemetry event contains multiple target patterns and/or references to multiple target data fields, and multiple triggering conditions associated with multiple detection output types, the multiple triggering conditions defined in terms of the multiple target patterns and/or the multiple target data fields. The motivation would have been to detect sustained attempts at breach across an entity's entire network attack surface, and the ability to respond to this targeting with heightened security before an actual compromise occurs)..
As per claim 12, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein the signature-based detection rules are contained or referenced in a configuration file of the threat detection component (Njemanze Col. 4 Lines 19-22 “ Managers 14 are server-based components that further consolidate, filter and cross-correlate events received from the agents, employing a rules engine 18 and a centralized event database 20.” Col. 10 Lines 29-30 “Rules may be created at the manager 14 and/or at the consoles 16 using a flexible scripting language.”),
As per claim 13, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein the computer-readable instructions, upon execution further cause the at least one processor to implement at least one standardization component configured to receive unstructured telemetry and convert the unstructured telemetry to structured telemetry events based on at least one of the telemetry data schemas (Njemanze Col. 6 Lines 53-58 “Each of these agents receives the event information from its associated network device or application in that device's or application's native format and converts (or normalizes) the information to a common schema. This normalization allows for later storage of the event information in a format that can more readily be utilized by an analyst.” and Col. 9 Line 66- Col. 8 “In other words, the rules engine 18 provides the ability to determine what type of incident is represented by a collection of events reported by a number of heterogeneous network devices and/or applications. Because the collected event data is normalized into a common event schema, correlation can be performed utilizing any field including, but not limited to, geography, device type, source, target, time thresholds, and/or event type. Based on alerts generated by the rules engine 18, operators are provided with a workflow for investigating these incidents.”)
As per claim 14, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein at least some of the structured telemetry events are received from endpoint agents configured to collect telemetry and structure the collected telemetry based on at least one of the telemetry data schemas (Njemanze Col. 6 Lines 53-58 “Each of these agents receives the event information from its associated network device or application in that device's or application's native format and converts (or normalizes) the information to a common schema. This normalization allows for later storage of the event information in a format that can more readily be utilized by an analyst.” and Col. 9 Line 66- Col. 8 “In other words, the rules engine 18 provides the ability to determine what type of incident is represented by a collection of events reported by a number of heterogeneous network devices and/or applications. Because the collected event data is normalized into a common event schema, correlation can be performed utilizing any field including, but not limited to, geography, device type, source, target, time thresholds, and/or event type. Based on alerts generated by the rules engine 18, operators are provided with a workflow for investigating these incidents.”)
As per claim 15, Njemanze in view of Samosseiko discloses:
The cybersecurity platform of claim 1, wherein each signature-based detection rule includes an indication of a pattern matching mode associated with the target pattern and the target data field (Samosseiko para 0176 “As shown in step 1212, the method 1200 may include listening to objects 1212. This may include monitoring the event stream 1203, e.g., by monitoring metadata placed onto the event stream 1203 by a transformer using one or more registered schemas, to identify any relevant attributes, events, actions, or the like in the event stream 1203 that may be relevant to a function of one of the listeners..” Also, Fig. 14, 0185, 0189 and 0191. Though Njemanze discloses detection rule, Samosseiko wherein each signature-based detection rule includes an indication of a pattern matching mode associated with the target pattern and the target data field. The motivation would have been to detect sustained attempts at breach across an entity's entire network attack surface, and the ability to respond to this targeting with heightened security before an actual compromise occurs ).
As per claim 19, the implementation of the cybersecurity platform of claim 1 will execute claim 1. The claim is analyzed with respect to claim 1.
As per claim 20, the implementation of the cybersecurity platform of claim 1 will execute the non-transitory computer readable media (Njemanze Col. 3 Lines 48-65) of claim 1 will execute claim 1. The claim is analyzed with respect to claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Publication No. 20230222220 discloses on paragraph 0023 “For example, the mapping rules and/or order criteria 280 can include an extendable data-frame with information on potential system path format patterns and/or associated alias for each of the potential system path format patterns. In some examples, the mapping rules and/or order criteria 280 can include information on which patterns to prioritize when performing matching using the process chain mapping entity circuitry 210, as described in connection with FIGS. 3, 4, and/or 5. In some examples, the mapping rules and/or order criteria 280 can be based on empirical evidence derived from field telemetry (e.g., telemetry data received via a cloud server, including security-related information connected to file creations, timestamps, and/or any other data necessary for assessing targeted attacks via malware).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499
Prosecution Insights