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 .
Response to Arguments
2. Applicant’s arguments filed on, with respect to the U.S.C 103 rejection of claims 1-5, 7, 8, 10-15 and 19 and 20as being unpatentable over U.S. Patent No. 8176527 hereinafter Njemanze in view of U.S. Publication No. 20230247048 hereinafter Samosseiko have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of arguments.
Allowable Subject Matter
3. 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.
4. 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. Patent No. 7424744 hereinafter Wu.
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, and cause a detection output to be generated based on detecting the target pattern 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;
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
Wu 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 (Fig. 5, Col. 6 Lines 4-40 “FIG. 5 is a block diagram illustrating details of the signature classifier 45 of the intrusion detection system. The signature classifier 45 includes a first stage classifier 70, second stage classifier 72, flow table 74, and classification rules database 40. The classification rules are generated based on the type of signature entries in the signature database. The classification rules are driven from the signature database so that it will only deal with the flows that will be examined by the active signatures stored in the database. The classification rules may have the following format, for example:Flow-identity ->Action Flow-identity: <prototype type> <source ip address> <destination ip address> <source ip address, destination ip address> <source ip address, range of dest ip addresses> <range of source ip addresses, destination ip address> <range of source ip addresses, range of destination ip addresses> <source port number> <destination port number>
Action: [pass to signature engine] [drop] The following is an example for a SNORT type signature:
alter tcp any-source-ip-address any-source-port->192.5.49.200 80
The resulting classification rule is:
<destination-ip address=192.5.49.200, destination-port-number=80,
tcp>[pass to signature engine]
Similar signatures may be combined to generate a single classification rule.”)
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. 5 Lines 23-39 “Signatures (or patterns) of all known attacks are described in an abstract form and included within the signature database 42. These patterns are used to identify an intrusion. Additional signatures are identified by studying system audit information in order to find matching patterns of known system intrusions. In a similar manner indications of other attacks can be figured out. They are represented in a specified form and coded to the intrusion detection system. A signature analysis or pattern matching algorithm is used upon the packets, wherein the packets are compared to "attack signatures", or signatures of known policy violations or patterns of misuse. Signature engine 34 compares monitored traffic with attack signatures. Attack signatures can comprise, for example, a rules-based hierarchy of traffic signatures of known policy violations. The signature engine 34 compares packets from the network traffic with such attack signatures such that policy violations can be discovered.” Col. 6 Lines 41-62 “The signature classifier 45 groups packets into separate flows (e.g., TCP, UDP, or HTTP). Each identified flow may be handled differently by the signature engine to speed up the process. The signature classifier may be constructed with single or multiple stages. The signature classifier 45 shown in FIG. 5 performs a multi-stage classification process. The first stage of classification is based on a selected set of packet fields, such as destination address, protocol type, and destination port number. The second classification stage may be based on packet type or size (e.g., TCP flags or packet length). The table 74 supports efficient table lookups of appropriate actions associated with incoming packets. When a packet is captured and classified, the appropriate entry of the flow table 74 is retrieved in order to perform the associated action. The action options may include, for example, match the packet against a given subset of signatures, drop the packet, generate an alert, or drop the packet and update one or more fields of the flow table 74.”)
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 and
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, as taught by Wu.
The motivation would have been to reducing the amount of processing required for packet inspection to provide efficient signature based intrusion detection for high-speed networks (Wu Col. 2 Lines 32-35).
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 Wu 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 (Wu para 0191 "Though Njemanze discloses data fields, Wu 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 Wu 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 (Wu Col. 6 Lines 41-62 “The signature classifier 45 groups packets into separate flows (e.g., TCP, UDP, or HTTP). Each identified flow may be handled differently by the signature engine to speed up the process. The signature classifier may be constructed with single or multiple stages. The signature classifier 45 shown in FIG. 5 performs a multi-stage classification process. The first stage of classification is based on a selected set of packet fields, such as destination address, protocol type, and destination port number. The second classification stage may be based on packet type or size (e.g., TCP flags or packet length). The table 74 supports efficient table lookups of appropriate actions associated with incoming packets. When a packet is captured and classified, the appropriate entry of the flow table 74 is retrieved in order to perform the associated action. The action options may include, for example, match the packet against a given subset of signatures, drop the packet, generate an alert, or drop the packet and update one or more fields of the flow table 74.”) Though Njemanze discloses data fields, Wu each structured telemetry event includes one or more field keys identifying one or more data fields. The motivation would have been to reducing the amount of processing required for packet inspection to provide efficient signature based intrusion detection for high-speed networks (Wu Col. 2 Lines 32-35)).
As per claim 5, Njemanze in view of Wu 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.")
As per claim 7, Njemanze in view of Wu 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 Wu 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 Wu 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
(Wu Col. 6 Lines 41-62 “The signature classifier 45 groups packets into separate flows (e.g., TCP, UDP, or HTTP). Each identified flow may be handled differently by the signature engine to speed up the process. The signature classifier may be constructed with single or multiple stages. The signature classifier 45 shown in FIG. 5 performs a multi-stage classification process. The first stage of classification is based on a selected set of packet fields, such as destination address, protocol type, and destination port number. The second classification stage may be based on packet type or size (e.g., TCP flags or packet length). The table 74 supports efficient table lookups of appropriate actions associated with incoming packets. When a packet is captured and classified, the appropriate entry of the flow table 74 is retrieved in order to perform the associated action. The action options may include, for example, match the packet against a given subset of signatures, drop the packet, generate an alert, or drop the packet and update one or more fields of the flow table 74.”) Though Njemanze discloses telemetry, Wu 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 reducing the amount of processing required for packet inspection to provide efficient signature based intrusion detection for high-speed networks (Wu Col. 2 Lines 32-35)).
As per claim 12, Njemanze in view of Wu 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 Wu 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 Wu 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 Wu 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 (Wu Col. 5 Lines 23-39, Fig. 5, Col. 6 Lines 4-40, and Col. 6 Lines 41-62 “The signature classifier 45 groups packets into separate flows (e.g., TCP, UDP, or HTTP). Each identified flow may be handled differently by the signature engine to speed up the process. The signature classifier may be constructed with single or multiple stages. The signature classifier 45 shown in FIG. 5 performs a multi-stage classification process. The first stage of classification is based on a selected set of packet fields, such as destination address, protocol type, and destination port number. The second classification stage may be based on packet type or size (e.g., TCP flags or packet length). The table 74 supports efficient table lookups of appropriate actions associated with incoming packets. When a packet is captured and classified, the appropriate entry of the flow table 74 is retrieved in order to perform the associated action. The action options may include, for example, match the packet against a given subset of signatures, drop the packet, generate an alert, or drop the packet and update one or more fields of the flow table 74.”) Though Njemanze discloses detection rule, Wu 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 reducing the amount of processing required for packet inspection to provide efficient signature based intrusion detection for high-speed networks (Wu Col. 2 Lines 32-35)).
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
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