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 2/23/2026 has been entered.
Response to Amendment
This communication is in response to the RCE and amendment filed on 2/23/2026. The Examiner acknowledges amended claims 1-20. No claims have been cancelled or added. Claims 1-20 are pending and claims 1-20 are rejected. Claims 1 and 12 is/are independent.
The objection to claims 13-20 is withdrawn.
The rejection(s) of claims under 35 U.S.C. § 112 are withdrawn in view of Applicant's amendments.
Response to Arguments
Applicant's arguments filed 2/23/2026 have been fully considered but they are not persuasive.
Regarding claim 1, applicant argues (see Remarks, page 7, para. 2 through page 8 para. 42) that:
VENKATRAMANI does not disclose or suggest one or more features of claim 1. For example, VENKATRAMANI does not disclose or suggest ''wherein the baseline measurement includes one or more expected measurements of the component with respect to the environment conditions," as recited in claim 1, amended as proposed.
VENKATRAMANI is directed to ''to security in enterprise, cloud, and internet of things (IoT) environments and more specifically to collecting connection and application execution information while tracking the users and machines involved'' (paragraph 0002 of VENKATRAMANI). At paragraph 0139, VENKATRAMANI states that ''when the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records)." This section of VENKATRAMANI further states that in ''many embodiments, the set of baseline signatures is built by counting (e.g., keeping a running count) of incoming records that match in a number of attributes."
At paragraph 0144, VENKATRAMANI states that ''[w]hen the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database." At paragraph 0145, VENKATRAMANI states that ''incoming activity record(s) are compared (528) against the set of baseline signatures."
Without acquiescing that the baseline signature of VENKATRAMANI correspond to the baseline measurement, VENKATRAMANI does not disclose or suggest that the baseline signature is a measurement of a component or a system. In fact, VENKATRAMANI specifically states that ''the set of baseline signatures is built by counting ... incoming records." VENKATRAMANI specifically states that the baseline signature is a count of occurrence of incoming records, not any measurement performed on a component or on a system.
Accordingly, VENKATRAMANI does not disclose or suggest ''wherein the baseline measurement includes one or more expected measurements of the component with respect to the environment conditions," as recited in claim 1, amended as proposed.
Independent claim 12 recites features similar to the above features of claim 1.
Accordingly, independent claims 1 and 12 and the claims dependent thereon are not anticipated by VENKATRAMANI.
Accordingly, Applicant respectfully requests that the Examiner reconsider and withdraw the rejection of claims 1-5, 8, 12-14, 16, and 17 under 35 U.S.C. § 102(a)(l).
Examiner respectfully disagrees.
Examiner submits that Venkatramani et al. U.S. Publication 20170163666 (hereinafter “Venkatramani”) discloses limitations of claim 1, including:
detecting, based on comparing the sensor data, that the sensor data differs from the baseline measurement by a threshold amount,
wherein the baseline measurement is based on environmental conditions,
wherein the baseline measurement includes one or more expected measurements
of the component with respect to the environmental conditions, and
wherein the sensor data includes one or more actual measurements of the component with respect to the environmental conditions;
Claim 1 recites environmental conditions but environmental conditions is not defined in the specification. Activity data can disclose environmental conditions because that is what is happening in the environment that the sensor is collecting data in; system activity information at Venkatramani para. 42 can disclose environmental conditions; environmental conditions can be disclosed by any activity or setting, or configuration/attribute data related to, for example, network elements and machines at Venkatramani para. 35 and shown in Venkatramani figure 1A. The presence of device or component activity (such as that displayed in Venkatramani figure 1) is also part of the environmental conditions.
What does measurements as recited in claim 1 mean? Is it physical dimensions or visual characteristics or measuring the mean time between occurrences in activities performed by a component, e.g., to define a bell curve distribution? Under broadest reasonable interpretation measurements can read on the measuring of time-related characteristics of activities performed by a component such as how often a component transmits a message or how often a component drops a packet. Para. 42 of Venkatramani states “A system including enterprise servers 102 and client devices 104 to be monitored and a collector server 106 in accordance with embodiments of the invention is illustrated in FIG. 1A. Each enterprise server 102 may have a network connectivity and application execution sensor installed to collect network and/or application information and forward it to the collector server 106.” The network and/or application information that is collected by the sensor can disclose data that is measured, including data that is collected over time and analyzed over time. The enterprise servers that are each monitored with a respective sensor can disclose a component.
Applicant argues that “VENKATRAMANI does not disclose or suggest that the baseline signature is a measurement of a component or a system. In fact, VENKATRAMANI specifically states that ''the set of baseline signatures is built by counting ... incoming records." Applicant ignores the context and the purpose of counting the incoming records. Applicant quotes a line from para. 139 of the Venkatramani reference, which states, in part:
Venkatramani [0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records). In many embodiments, the set of baseline signatures is built by counting (e.g., keeping a running count) of incoming records that match in a number of attributes. The activity record(s) are entered (508) into the connection and application execution monitoring database. Each activity record includes a number of attributes, such as those described further above. In many embodiments, an activity record includes a common part and a unique part. The common part includes attributes that are also part of baseline signatures. The unique part includes attributes that are not part of baseline signatures (such as time and date stamp of a communication or application event).
Venkatramani at para. 140 further clarifies why the incoming records are being counted, which is to determine the signatures that qualify as baseline signature (Venkatramani signatures are a collection of attributes and attributes can be values measuring characteristics of component activities):
Venkatramani [0140] Several embodiments utilize a reference count to determine the significance of a particular signature. If the session signature attributes of a new incoming activity record matches any existing signature, then the reference count of the signature is incremented by one. Otherwise a new signature will be created, with reference count set to one, and added to the set of signatures maintained by the collector. When the count of a particular signature reaches a threshold number, the set of attributes is then saved as a baseline signature. Other criteria for becoming a baseline signature may be utilized in accordance with embodiments of the invention, such as considering other information indicative of whether a connection or application activity is legitimate, receiving user input whether the activity record is legitimate or suspicious, the count of the signature associated with a particular entity in comparison to similar signatures associated with other entities in a group to which that entity belongs, and/or utilizing a security policy specified for particular attributes.
Para. 139 of Venkatramani discloses that the activity records that describe component activities are collected, and the common part attributes become part of the baseline signatures. These common part attributes describe common activity characteristics of the components. Para. 140 of Venkatramani then discloses that not all signatures occur in sufficient quantities (e.g., the count) to qualify as a baseline signature, and there is a threshold requirement before a signature becomes a baseline signature. They count the number of matches from incoming activity records (that describe activity characteristics of a component), and increment the counts for a signature every time there is matching session signature attributes for the incoming activity record. The baseline signature is thereby chosen from the signatures based on counting the most often seen session signature attributes, and session signature attributes depend on the activity characteristics including measurements performed on components.
The measurement as claimed under broadest reasonable interpretation can be the number of repetitions of particular activities performed by a component. The measurement can read on the values of attributes that are collected in the activity records received. See Venkatramani Para. 3 which states “comparing, using the collector server, the first activity record to a set of baseline signatures, where each baseline signature includes a second set of attributes, each attribute having a particular value and each baseline signature being unique in the combination of values of its attributes,”
In other words, Venkatramani discloses that sensor data include detected values from activity data, para. 23; such sensor data is separately collected for generating Venkatramani baseline and also subsequent comparison with the baseline; session signature is a collection of session attributes (para. 70) which includes distribution over time (para. 78); and the session signatures become baseline signatures as described at para. 140 “When the count of a particular signature reaches a threshold number, the set of attributes is then saved as a baseline signature”, which means that the attributes have been seen often enough that they should become part of the baseline; the attributes are a measurement of the component because “Certain attributes may utilize a range (e.g., time period within a day, week, month, etc.) or an interval of repeating (e.g., day of the week, month, etc.).” as described at para. 145, meaning that attribute describes how the component is repeating itself; measuring component activity is within the scope of the broadest reasonable interpretation of measurements of the component recited in the claim. Therefore, Applicant’s argument that “VENKATRAMANI does not disclose or suggest that the baseline signature is a measurement of a component or a system” cannot succeed and Venkatramani discloses the limitations of time 1.
Examiner has considered Applicant's remarks to the extent that they may be applicable to independent claim 12 and finds them unpersuasive for the same reasons as claim 1.
Regarding applicant’s arguments with respect to the dependent claims, the dependent claims inherit their respective limitations from the respective independent claims, and are therefore rejected for the same reasons as the respective independent claims.
Accordingly, Applicant's argument is not persuasive with respect to the rejection under the cited art, and the rejection is maintained.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-5, 8, 12-14, and 16-17 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Venkatramani et al. U.S. Publication 20170163666 (hereinafter “Venkatramani”).
As per claim 1, Venkatramani discloses A method [methods for detecting and responding to security threats, para. 20] for using sensors [ each enterprise server has sensor, para. 42] to detect potential security risks, [detecting an anomaly condition, para. 144]comprising:
tracking, [monitored by sensor, para. 42] via a sensor, [ first connection and application execution sensor, para. 3] a component [enterprise servers 102 and client devices 104 to be monitored, para. 42; application executing on the server, para. 42] of a system; [system for application execution signature and connection lineage tracing, para. 42; system including enterprise servers 102, para. 42]
Venkatramani [0042] Components of a system for application execution signature and connection lineage tracing in accordance with embodiments of the invention can include software applications and/or modules that configure a server or other computing device1 to perform processes as will be discussed further below. A system including enterprise servers 102 and client devices 104 to be monitored and a collector server 106 in accordance with embodiments of the invention is illustrated in FIG. 1A. Each enterprise server 102 may have a network connectivity and application execution sensor installed to collect network and/or application information and forward it to the collector server 106.
comparing [alert when activity record differs from baseline signatures, para. 3; comparing records with baseline, para. 145] sensor data [a first piece of activity data including a first set of attributes, each attribute having a particular value, para. 3; collect network and/or application information, para. 42; new incoming activity data, para. 144] from the sensor with a baseline measurement associated with the component;
Venkatramani [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures.
[an alert when the values of the attributes of the second activity record differ from all baseline signatures in the set of baseline signatures by at least a predetermined threshold, para. 3
]
detecting, based on comparing the sensor data, [activity data from one or more connectivity and application execution sensors, para. 144] that the sensor data differs from the baseline measurement [incoming activity record(s) are compared against the set of baseline signatures, para. 145] by a threshold amount, [ by more than a predetermined number of attributes, para. 145; the time is within the time period, para. 145; by a distance measure, para. 145]
wherein the baseline measurement is based on environmental conditions;
[
Claim 12 recites environmental conditions but environmental conditions is not defined in the specification. Activity data can disclose environmental condition because that is what is happening in the environment that the sensor is collecting data in; system activity information at Venkatramani para. 42 can disclose environmental condition; environmental conditions can be disclosed by any activity or setting, or configuration/attribute data related to, for example, network elements and machines at Venkatramani para. 35 and shown in figure 1A; See application activity, para. 140.
]
Venkatramani [0070] End-end sessions include both user-application sessions and application-application sessions. A session signature is a collection of session attributes that uniquely characterize sessions having a common behavior, which includes information such as, but not limited to: [0078] distribution over time (e.g., a configurable period or range such as time of day, days, weeks months, or repeat period such as day of the week)
[0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records). In many embodiments, the set of baseline signatures is built by counting (e.g., keeping a running count) of incoming records that match in a number of attributes. The activity record(s) are entered (508) into the connection and application execution monitoring database.
[0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. A process for detecting an anomaly condition using baseline signatures in accordance with embodiments of the invention is illustrated in FIG. 5B. The process 520 includes receiving (522) a new incoming piece of activity data from one or more connectivity and application execution sensors. Where multiple collectors are involved in generating activity data, the information may come from one or more collectors. Context information is received (524) and combined (526) with the activity data to form an activity record (e.g., session record and/or application execution record).
Venkatramani [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior. Larger deviations from matching the baseline signatures can indicate an anomalous condition. Certain attributes may utilize a range (e.g., time period within a day, week, month, etc.) or an interval of repeating (e.g., day of the week, month, etc.). A match can similarly be made in such cases, e.g., if the time is within the time period or if the date falls on that day of the week. In several embodiments of the invention, an alert is generated (530) if an incoming record in detection mode does not match any baseline signature by more than a predetermined number of attributes and/or differs from all baseline signatures by more than a predetermined number of attributes.
wherein the baseline measurement [ baseline measurement is generated (para. 139) by examining the received activity records of computing components and when sufficient records meet a threshold then they form the baseline measurement ] includes one or more expected measurements [ sensor data include detected values from activity data, para. 23; such sensor data is used both for generating Venkatramani baseline and also subsequent comparison with the baseline; session signature is a collection of session attributes (para. 70) which includes distribution over time (para. 78); and the session signatures become baseline signatures as described at para. 140 “When the count of a particular signature reaches a threshold number, the set of attributes is then saved as a baseline signature”, which means that the attributes have been seen often enough that they should become part of the baseline; the attributes are a measurement of the component because “Certain attributes may utilize a range (e.g., time period within a day, week, month, etc.) or an interval of repeating (e.g., day of the week, month, etc.).” as described at para. 145, meaning that attribute describes how the component is repeating itself; measuring component activity is within the scope of the broadest reasonable interpretation of measurements of the component recited in the claim] of the component with respect to the environmental conditions, and
wherein the sensor data includes one or more actual measurements [values of attributes of activity data received from sensor, para. 23] of the component with respect to the environmental conditions;
[0023] In yet another additional embodiment, a collector server for detecting suspicious activity in a network and a computer server system, includes a processor, a network interface, and memory including a collector application, where the processor is directed by the collector application to receive, from a first connection and application execution sensor, a first piece of activity data including a first set of attributes, each attribute having a particular value, combine a first set of context information with the first piece of activity data to generate a first activity record, compare the first activity record to a set of baseline signatures, where each baseline signature includes a second set of attributes, each attribute having a particular value and each baseline signature being unique in the combination of values of its attributes, increment a count of a first matching baseline signature from the set of baseline signatures when the first activity record has the same values for all attributes in the first matching baseline signature, receive at a collector server, from a second connection and application execution sensor, a second piece of activity data including a third set of attributes, each attribute having a particular value, combine a second set of context information with the second piece of activity data to generate a second activity record, and generate an alert when the values of the attributes of the second activity record differ from all baseline signatures in the set of baseline signatures by at least a predetermined threshold number of attributes.
Para. 35 threats are often introduced into the environment (including, but not limited to, users, machines, applications, and/or network elements)
Venkatramani Para. 42 Each enterprise server 102 may have a network connectivity and application execution sensor installed to collect network and/or application information and forward it to the collector server 106. In some embodiments, an enterprise or other environment that includes large numbers of servers is monitored by multiple collector servers where each collector server forms a cluster with sensors associated with it. For a monitored session where both ends are monitored servers with associated sensors, but are associated with different collectors, the two collectors exchange sensor information they received respectively so that they both have complete system activity information at both ends. In several embodiments, the network connectivity and application execution sensor is implemented within the server to enable monitoring of the server kernel as the server system executes application software.0135] The collected activity data, which can include network and/or application information, also referred to as session records and application execution records, can be sent (404) to the collector server periodically.
flagging, [generating, using the collector server, an alert, para. 3; generate alert para. 145] based on detecting that the sensor data differs from the baseline measurement by the threshold amount, [incoming record not matching baseline signature by more than a predetermined number of attributes, para. 145; when values differ from baseline signatures, para. 3] the sensor data as indicating a potential security risk; [detecting an anomaly condition using baseline signatures, para. 144; detecting security threats, para. 3]
[0003] Systems and methods for detecting and responding to security threats using application execution and connection lineage tracing in accordance with embodiments of the invention are disclosed. In one embodiment, a process for detecting suspicious activity in a network and in a computer server system includes receiving at a collector server, from a first connection and application execution sensor, a first piece of activity data including a first set of attributes, each attribute having a particular value, combining, using the collector server, a first set of context information with the first piece of activity data to generate a first activity record, comparing, using the collector server, the first activity record to a set of baseline signatures, … generating, using the collector server, an alert when the values of the attributes of the second activity record differ from all baseline signatures in the set of baseline signatures by at least a predetermined threshold number of attributes.
[0042] Components of a system for application execution signature and connection lineage tracing in accordance with embodiments of the invention can include software applications and/or modules that configure a server or other computing device to perform processes as will be discussed further below. A system including enterprise servers 102 and client devices 104 to be monitored and a collector server 106 in accordance with embodiments of the invention is illustrated in FIG. 1A. Each enterprise server 102 may have a network connectivity and application execution sensor installed to collect network and/or application information and forward it to the collector server 106.
Venkatramani [0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. A process for detecting an anomaly condition using baseline signatures in accordance with embodiments of the invention is illustrated in FIG. 5B. The process 520 includes receiving (522) a new incoming piece of activity data from one or more connectivity and application execution sensors. Where multiple collectors are involved in generating activity data, the information may come from one or more collectors. Context information is received (524) and combined (526) with the activity data to form an activity record (e.g., session record and/or application execution record).
[0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior. Larger deviations from matching the baseline signatures can indicate an anomalous condition. Certain attributes may utilize a range (e.g., time period within a day, week, month, etc.) or an interval of repeating (e.g., day of the week, month, etc.). A match can similarly be made in such cases, e.g., if the time is within the time period or if the date falls on that day of the week. In several embodiments of the invention, an alert is generated (530) if an incoming record in detection mode does not match any baseline signature by more than a predetermined number of attributes and/or differs from all baseline signatures by more than a predetermined number of attributes.
Venkatramani [0150] Baselines may be maintained per user, group, and crowd and continuously adjusted (e.g., using a rolling average). A connection lineage signature together with networking information about the associated connection (e.g., envelope information) can represent a comprehensive profile for a network connection record seen in enterprise networks. A baseline for a pristine environment, without malware presence, can be built by collecting all the network connections running in the enterprise network during a learning period
performing an automated corrective action on the component based on flagging the sensor data [receive connectivity information from connectivity and application execution sensors …Using the collected information, the collector server system within the threat detection and response system can identify potential threats, para. 45] as indicating the potential security risk,
wherein performing the automated corrective action includes at least one of:
shutting down the system to prevent the potential security risk,
modifying system settings of the system to prevent the potential security risk, or [quarantining a machine, process, application, and/or user associated with a detected security threat, para. 45]
changing a function [quarantining a machine, process, application, and/or user associated with a detected security threat, para. 45] of the system to prevent the potential security risk.
As per claim 2, the rejection of claim 1 is incorporated herein.
Venkatramani discloses wherein the baseline measurement is established based on previously tracking [during the learning period, para. 150]the component with the sensor.
Venkatramani Para. 45 Comparison data can be received from user-defined policies and a signature and baseline database built through unsupervised learning.
Para. 150 A baseline for a pristine environment, without malware presence, can be built by collecting all the network connections running in the enterprise network during a learning period
[0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records).
As per claim 3, the rejection of claim 1 is incorporated herein.
Venkatramani discloses establishing one or more baselines for the component corresponding, respectively, with one or more system functions. [system functions disclosed by Sessions, application execution, para. 39, 139, 144]
Venkatramani [0039] The collected information (including connection and/or application execution information) can be referred to as activity data, where each piece of activity data includes values for each of a predefined set of attributes (metadata) that describes a particular connection or aspect of application execution.
[0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. A process for detecting an anomaly condition using baseline signatures in accordance with embodiments of the invention is illustrated in FIG. 5B. The process 520 includes receiving (522) a new incoming piece of activity data from one or more connectivity and application execution sensors. Where multiple collectors are involved in generating activity data, the information may come from one or more collectors. Context information is received (524) and combined (526) with the activity data to form an activity record (e.g., session record and/or application execution record).
As per claim 4, the rejection of claim 3 is incorporated herein.
Venkatramani discloses wherein a baseline of the one or more baselines is based on a workload being executed by the system. [As described in para. 139, the baselines are generated from the activity records and activity records are generated based on the sensor data, para. 144; since the baseline signatures are built by counting incoming records that match, the bigger the workload, the more matching incoming records there will be, influencing the baseline signatures being built, and therefore baseline signatures are based on the workload]
Venkatramani [0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records). In many embodiments, the set of baseline signatures is built by counting (e.g., keeping a running count) of incoming records that match in a number of attributes. The activity record(s) are entered (508) into the connection and application execution monitoring database. Each activity record includes a number of attributes, such as those described further above
[0038] AE-CLT filtering can use information collected on connections and executing applications to generate baseline signatures that are used to match attributes of subsequent connections and application execution trees to determine if they are likely normal operation or an anomalous condition. I
As per claim 5, the rejection of claim 3 is incorporated herein.
Venkatramani discloses wherein the one or more baselines are established using an AI (artificial intelligence) system.
Venkatramani [0045] Comparison data can be received from user-defined policies and a signature and baseline database built through unsupervised learning.
[0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records)
As per claim 8, the rejection of claim 1 is incorporated herein.
Venkatramani discloses wherein the threshold amount [predetermined threshold, para. 3] is based on the component [monitored servers, para. 125; enterprise servers 102 and client devices 104 to be monitored, para. 42; application executing on the server, para. 42; the application that is executing, para. 139]of the system.
para. 3 an alert when the values of the attributes of the second activity record differ from all baseline signatures in the set of baseline signatures by at least a predetermined threshold number of attributes.
Venkatramani [0125] While in detection mode, sensors installed in monitored servers continue capturing information about the running applications (at regular intervals or continuously), just like during the learning period, and forward the collected stack traces to the collector for comparison. If a count or percentage of mismatched samples increase beyond a threshold, computed over some time period or across an ensemble of many servers, then alert or other notice can be generated for further triaging and analysis.
As per claim 12, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1. The claim does not require the first system and the second system to be different systems under a broadest reasonable interpretation.
Claim 12 also recites, and Venkatramani discloses,
A first system [system for application execution signature and connection lineage tracing, para. 42; system including enterprise servers 102, para. 42; server system processors, para. 42 ] for using sensors to detect potential security risks, the first system comprising: [sensor installed to collect network and/or application information and forward it to the collector server 106, para. 42; enforcement actions in response to detection of a security threat, para. 48]
a sensor configured to monitor a component [application]of a second system; [system for application execution signature and connection lineage tracing, para. 42; system including enterprise servers 102, para. 42; server system processors, para. 42; the claim does not require the first system and the second system to be different systems ] and [sensor installed to collect network and/or application information and forward it to the collector server 106, para. 42;
a processor communicatively coupled to the sensor and configured to: [server system processors, para. 42; Traffic to a specific server can be mirrored to a connectivity and application execution sensor for analysis. In this way, connectivity monitoring can be performed in circumstances where application servers do not support connectivity and application execution sensor applications, para. 42; processor 202, para. 49
]
Venkatramani [0049] A server hosting a connectivity and application execution sensor application in accordance with embodiments of the invention is conceptually illustrated in FIG. 2A. The server 200 includes a processor 202
track, via the sensor, the component of the second system [(see rejection of claim 1) system for application execution signature and connection lineage tracing, para. 42; system including enterprise servers 102, para. 42; the claim does not require the first system and the second system to be different systems].
Furthermore, the amended limitations are rejected as follows
(basically rejected in the same way as claim 1):
wherein the baseline measurement is based on at least one of environmental conditions or system workloads of the second system,
[
Claim 12 recites environmental conditions but environmental conditions is not defined in the specification. Activity data can disclose environmental condition because that is what is happening in the environment that the sensor is collecting data in; system activity information at Venkatramani para. 42 can disclose environmental condition; environmental conditions can be disclosed by any activity or setting, or configuration/attribute data related to, for example, network elements and machines at Venkatramani para. 35 and shown in figure 1A; See application activity, para. 140.
]
[0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records). In many embodiments, the set of baseline signatures is built by counting (e.g., keeping a running count) of incoming records that match in a number of attributes. The activity record(s) are entered (508) into the connection and application execution monitoring database.
[0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. A process for detecting an anomaly condition using baseline signatures in accordance with embodiments of the invention is illustrated in FIG. 5B. The process 520 includes receiving (522) a new incoming piece of activity data from one or more connectivity and application execution sensors. Where multiple collectors are involved in generating activity data, the information may come from one or more collectors. Context information is received (524) and combined (526) with the activity data to form an activity record (e.g., session record and/or application execution record).
Venkatramani [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior. Larger deviations from matching the baseline signatures can indicate an anomalous condition. Certain attributes may utilize a range (e.g., time period within a day, week, month, etc.) or an interval of repeating (e.g., day of the week, month, etc.). A match can similarly be made in such cases, e.g., if the time is within the time period or if the date falls on that day of the week. In several embodiments of the invention, an alert is generated (530) if an incoming record in detection mode does not match any baseline signature by more than a predetermined number of attributes and/or differs from all baseline signatures by more than a predetermined number of attributes.
wherein the baseline measurement [ baseline measurement is generated (para. 139) by examining the received activity records of computing components and when sufficient records meet a threshold then they form the baseline measurement ] includes an expected measurement [ sensor data include detected values from activity data, para. 23;such sensor data is used both for generating Venkatramani baseline and also subsequent comparison with the baseline] of the second system with respect to the at least one of the environment conditions [environmental conditions can be disclosed by any activity or setting, or configuration/attribute data related to network elements and machines at para. 35; application activity, para. 140] or the system workloads of the second system, and
wherein the sensor data includes one or more actual measurements [values of attributes of activity data received from sensor, para. 23] of the component with respect to the at least one of the environment conditions [environmental conditions can be disclosed by any activity or setting, or configuration/attribute data related to network elements and machines at para. 35; application activity, para. 140] or the system workloads of the second system;
As per claim 13, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
As per claim 14, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
As per claim 16, the rejection of claim 12 is incorporated herein.
Venkatramani discloses wherein the sensor is configured to monitor multiple components of the second system. [There is no requirement in the claim that the first system and the second system are different; Sensor is monitoring the server kernel, the server system, the application software, the network connectivity para. 42
Venkatramani [0042] A system including enterprise servers 102 and client devices 104 to be monitored and a collector server 106 in accordance with embodiments of the invention is illustrated in FIG. 1A. Each enterprise server 102 may have a network connectivity and application execution sensor installed to collect network and/or application information and forward it to the collector server 106. …the network connectivity and application execution sensor is implemented within the server to enable monitoring of the server kernel as the server system executes application software. …, the connectivity and application execution sensor application may collect envelope information about network connections that are established to or from the server on which the application is executing or, in the case of a separate connection monitoring appliance, other servers or machines that the appliance is monitoring. I
As per claim 17, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 8, and is/are rejected for the reasons detailed with respect to claim 8. Furthermore, there is no requirement in the claim that the first system and the second system are different.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 wa
s 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 6 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venkatramani in view of Binion et al. U.S. Publication 20150112731 (hereinafter “Binion”).
As per claim 6, the rejection of claim 1 is incorporated herein.
However, Venkatramani does not expressly disclose wherein flagging the sensor data as indicating the potential security risk includes storing the sensor data in memory along with an indication that the sensor data may be associated with the potential security risk.
Binion discloses storing sensor data in memory and storing a risk indicator in memory, the risk indicator generated from the sensor data
[0035] In some embodiments, the data generated by data analysis unit 54 and stored in memory 56 (e.g., data reflecting risk indicators corresponding to respective time periods) is automatically sent to interface 60 for transmission to the insurer's computer system 1
[0043] The risk determination unit 80 may be configured to analyze the vehicle data stored in memory 72 using one or more of these correlation models in order to determine one or more risk indicators.
Para. 122 In this embodiment, the method 400 further stores the received sensor data in a memory, and the risk indicator is determined based not only on the operational data, but also the stored sensor data (e.g., in a manner similar to that discussed above in connection with method 360 of FIG. 9).
[0034] Additionally, or alternatively, data analysis unit 54 may process data collected by data collection unit 50 and stored in memory 52, and store results relating to that processing in memory 56. In one such embodiment, data analysis unit 54 processes external sensor data and/or subsystem data substantially in real-time (e.g., as the data is collected by data collection unit 50) in order to generate risk indicators reflecting the level of risk associated with the conditions or environment in which the vehicle is driven, and/or the operation of the vehicle, during different time periods… Once each risk indicator is generated for a particular time period, the risk indicator may be stored in memory 56
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatramani with the technique for storing sensor data in memory and storing a risk indicator in memory, the risk indicator generated from the sensor data of Binion to include wherein flagging the sensor data as indicating the potential security risk includes storing the sensor data in memory along with an indication that the sensor data may be associated with the potential security risk.
One of ordinary skill in the art would have made this modification to improve the ability of the system to maintain a record of sensor data that poses a security risk. The system of the primary reference can be modified to store sensor data as well as risk indicators generated from the stored sensor data.
As per claim 15, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 6, and is/are rejected for the reasons detailed with respect to claim 6.
Claim 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venkatramani in view of Bailey et al. U.S. Publication 20110154497 (hereinafter “Bailey”).
As per claim 7, the rejection of claim 1 is incorporated herein.
However, Venkatramani does not expressly disclose further comprising sending a notification identifying the potential security risk, wherein the notification includes the sensor data
Bailey discloses agents sending risk variable with sensor data to a mediator
[0104] Sensor(s) 216 can sense data communicated via communication interface 202 so that TM agent 108a and/or trust mediator 116 can perform traffic analysis on the data. In particular, sensor(s) 216 intercepts data and examines it to determine patterns which may be used to deduce information associated with the data. Trust mediator 116 uses this sensor data and/or risk variables to compute the probability that a particular transaction will be fraudulent. For example, trust mediator 116 may compare patterns determined for data communicated via communication interface 202 to patterns known to be associated with malicious software.
[0083] Systems 100 and 200 may contain numerous types of sensors that sense corresponding types of physical quantities and/or data to provide trust mediator 116 with as complete a set of inputs as possible for computing risk. Regardless of the type of sensor, each sensor provides sensor data to one or more of TM agents 108a-108f, and the sensor data is converted into a signal that is stored in a corresponding risk variable, which in turn is communicated to trust mediator 116. At block 406, processor 204 updates risk variable(s) stored in storage 210 based on sensor data received from sensor(s) 216. Sub-process 416 is then repeated so as to maintain up-to-date risk variable(s) in storage 210.
Bailey [0046] In the example shown in FIG. 2, storage device 210 stores data and/or instructions corresponding to one or more sensor(s) 216 as well data and/or instructions corresponding to TM agent 108a. Processor 204 may copy portions of the instructions corresponding to sensor 216 and/or TM agent 108a from storage device 210 to main memory 206 for execution by processor 204. Each sensor 216 measures a physical quantity and converts it into sensor data that is stored as a corresponding risk variable by TM agent 108a in storage device 210. As described in further detail below with respect to FIG. 4, TM agent 108a communicates the risk variable to trust mediator 116, based on data reporting instructions received from trust mediator 116.
[The risk variable includes the sensor data as disclosed in para.83]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatramani with the technique for sending risk variable with sensor data of Bailey to include further comprising sending a notification identifying the potential security risk, wherein the notification includes the sensor data.
One of ordinary skill in the art would have made this modification to improve the ability of the system to report security risk while including some sensor data for the recipient to make independent decisions. The system of the primary reference can be modified to process the sensor data to indicate risk and sensor data and transmit the processed data which includes sensor data.
Claims 9-11 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venkatramani in view of Wei et al. U.S. Publication 20210382989 (hereinafter “Wei”).
As per claim 9, the rejection of claim 1 is incorporated herein.
However, Venkatramani does not expressly disclose wherein the sensor is tracking a temperature of the component,
wherein the baseline measurement includes an expected temperature of the component,
and
wherein the sensor data includes an actual temperature of the component.
Wei discloses using a temperature sensor to track temperature and adding an expected temperature to a baseline measurement.
[0012] Briefly described, aspects of the present invention relate to a system and a method that enable multilevel consistency check for a cyber attack detection in an automation and control system. An intelligent plant floor network sensor (IPFNS) is configured to detect potential cyber attacks on a plant floor network. The intelligent plant floor network sensor (IPFNS) connects to all plant floor automation devices via Ethernet,
[0048] As seen in FIG. 5, it illustrates temperature sensor measurement readings on different devices 410 in accordance with an exemplary embodiment of the present invention. One sensor measurement on different devices 410 may be different, even they are sensed by the IPFNS 407 at the same time. As shown in FIG. 5, a temperature sensor collects temperature measurement continuously and sends the value to the PLC 211 every 10 milliseconds, the PLC 211 sends the measurement value to the HMI 410(1), via the Industrial Router 410(5) to the HMI 410(1) every 200 milliseconds and the HMI 410(1) sends the measurement value to the Log Server 410(3) every 1 second.
[0049] At moment t4, assume that the IPFNS 407 reads temperature readings on the I/O 410(6), the PLC 211, the HMI 410″(1) and the Log Server 410(3) at the same time. The readings are different—T4, T3, T2 and T1 are readings of the same temperature sensor on the I/O 410(6), the PLC 211, the HMI 410(1) and the Log Server 410(3), respectively. And they are readings on the I/O 410(6) at different moments t4, t3, t2 and t1, respectively. Therefore, there is “unsync” issue of the same sensor 407 readings on different devices 410. Furthermore, the IPFNS 407 cannot read all readings on different devices 410 at the same time, usually it reads them sequentially. Thus, this even makes those readings more “unsync”.
[0050] The following method addresses this “unsync” issue. Before comparing these analog readings of the same sensor 407 measurement on different devices 410—1) use the reading in the PLC 211 as a baseline, since all control comes from the PLC 211; 2) use a previous reading (10 milliseconds ago) of I/Os 410(6-7); 3) use the previous reading and readings in the HMI 410(1) and calculate a current reading by extrapolating; and 4) use the previous reading and readings in the Log Server 410(3) and calculate a current reading by extrapolating.
[0051] When these readings, including calculated ones, are compared, a threshold is used to decide the readings of this sensor 407 is normal or abnormal. For instance, the method can take advantage of production process domain knowledge that the temperature of this product cannot be changed 2° C. in one second. Then the method may set the threshold of comparison to 0.5°
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatramani with the technique for using a temperature sensor to track temperature and adding an expected temperature to a baseline measurement of Wei to include
wherein the sensor is tracking a temperature of the component,
wherein the baseline measurement includes an expected temperature of the component,
and
wherein the sensor data includes an actual temperature of the component.
One of ordinary skill in the art would have made this modification to improve the ability of the system to track the temperature of a component, in order to detect and facilitate preventing overheating. The system of the primary reference can be modified to utilize temperature sensors to check the temperature of components of the system.
As per claim 10, the rejection of claim 1 is incorporated herein.
However, Venkatramani does not expressly disclose wherein the component is configured to provide supervisory control and data acquisition (SCADA) data.
Rondeau discloses utilizing SCADA for sensor applications
Rondeau [0026] The present disclosure provides a passive, non-networked, non-operably connected, wireless security solution providing a PHY-based security augmentation for IoT, IIoT, ICS/SCADA, and other wireless sensor applications. Primary protection is provided through Distinct Native Attribute (DNA) fingerprinting methods that have been developed and demonstrated in support of providing both pre-attack system defense and post-attack forensic analysis. Use of the term “distinct native attribute” (DNA) is consistent with [Ref. 14: Cob] and embodies the coloration of signal responses that is induced by the intrinsic physical attributes of the device producing the signal. Fingerprinting methods supported by the invention include Radio Frequency DNA (RF-DNA) [Ref. 15: Rei, Ref. 16: Tal], Wired Signal DNA (WS-DNA) [Ref. 17: Lop] and Constellation Based DNA (CB-DNA) [Ref. 1: Ron1] processes that represent the historical timeline of related DNA discoveries and demonstrations. All methods presented here are utilized by the invention.
[0029] WS-DNA work in [Ref. 17: Lop] adopted TD fingerprinting methods from [Ref. 15: Rei] and SB-FSK fingerprinting methods from [Ref. 16: Tal] to extend PHY-based DNA fingerprinting development and demonstration using field device Wired Signal DNA (WS-DNA) features. The WS-DNA features were extracted from Highway Addressable Remote Transducer (HART) signals used in ICS/SCADA applications and the MDA processing augmented with a Random Forest (RndF) classifier to identify the most relevant fingerprint features required to achieve a given level of discriminability.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatramani with the technique for utilizing SCADA for sensor applications of Rondeau to include wherein the component is configured to provide supervisory control and data acquisition (SCADA) data.
One of ordinary skill in the art would have made this modification to improve the ability of the system to provide improved accuracy and precision in data collection and analysis, to facilitate real-time monitoring to detect abnormalities in performance. The system of the primary reference can be modified to utilize SCADA for sensor applications.
As per claim 11, the rejection of claim 1 is incorporated herein.
However, Venkatramani does not expressly disclose wherein the component is an internet of things (IoT) device.
Rondeau discloses detecting rogue control of IoT devices
Rondeau [0028] Rogue detection assessments in [Ref. 16: Tal] were conducted for an authorized network of Insteon IoT home automation devices, with attacking rogue devices including both 1) the most challenging case using like-manufacturer, like-model Insteon devices, and 2) the least challenging case using dissimilar-manufacturer YARD Stick One software defined radio (SDR) devices—this SDR choice was motivated by related Insteon cyberattack demonstrations that resulted in unprotected (no RF-DNA discrimination) wireless Insteon devices being errantly controlled by a rogue device. The attacking rogue devices were digitally programmed to present false bit-level IDs for authorized Insteon devices and an attack deemed successful if the rogue device could functionally control the unprotected targeted end point device. SB-FSK features were superior to TD features, with the most challenging case results including better than 95% rogue detection and 100% rogue detection achieved for the less challenging SDR attacks.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatramani with the technique for detecting rogue control of IoT devices of Rondeau to include wherein the component is an internet of things (IoT) device.
One of ordinary skill in the art would have made this modification to improve the ability of the system to detect rogue control of IoT devices. The system of the primary reference can be modified to detecting rogue control of IoT devices, in order to eliminate the threat from the IoT devices under rogue control.
As per claim 18, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 9, and is/are rejected for the reasons detailed with respect to claim 9.
As per claim 19, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 10, and is/are rejected for the reasons detailed with respect to claim 10.
As per claim 20, the rejection of claim 12 is incorporated herein.
However, Venkatramani does not expressly disclose wherein the component is an internet of things (IoT) device, and wherein the system is a SCADA system.
Rondeau discloses a component is an internet of things (IoT) device, and the system is a SCADA system.
[0026] The present disclosure provides a passive, non-networked, non-operably connected, wireless security solution providing a PHY-based security augmentation for IoT, IIoT, ICS/SCADA, and other wireless sensor applications. Primary protection is provided through Distinct Native Attribute (DNA) fingerprinting methods that have been developed and demonstrated in support of providing both pre-attack system defense and post-attack forensic analysis. Use of the term “distinct native attribute” (DNA) is consistent with [Ref. 14: Cob] and embodies the coloration of signal responses that is induced by the intrinsic physical attributes of the device producing the signal. Fingerprinting methods supported by the invention include Radio Frequency DNA (RF-DNA) [Ref. 15: Rei, Ref. 16: Tal], Wired Signal DNA (WS-DNA) [Ref. 17: Lop] and Constellation Based DNA (CB-DNA) [Ref. 1: Ron1] processes that represent the historical timeline of related DNA discoveries and demonstrations. All methods presented here are utilized by the invention.
[0029] WS-DNA work in [Ref. 17: Lop] adopted TD fingerprinting methods from [Ref. 15: Rei] and SB-FSK fingerprinting methods from [Ref. 16: Tal] to extend PHY-based DNA fingerprinting development and demonstration using field device Wired Signal DNA (WS-DNA) features. The WS-DNA features were extracted from Highway Addressable Remote Transducer (HART) signals used in ICS/SCADA applications and the MDA processing augmented with a Random Forest (RndF) classifier to identify the most relevant fingerprint features required to achieve a given level of discriminability.
Rondeau [0028] Rogue detection assessments in [Ref. 16: Tal] were conducted for an authorized network of Insteon IoT home automation devices, with attacking rogue devices including both 1) the most challenging case using like-manufacturer, like-model Insteon devices, and 2) the least challenging case using dissimilar-manufacturer YARD Stick One software defined radio (SDR) devices—this SDR choice was motivated by related Insteon cyberattack demonstrations that resulted in unprotected (no RF-DNA discrimination) wireless Insteon devices being errantly controlled by a rogue device. The attacking rogue devices were digitally programmed to present false bit-level IDs for authorized Insteon devices and an attack deemed successful if the rogue device could functionally control the unprotected targeted end point device. SB-FSK features were superior to TD features, with the most challenging case results including better than 95% rogue detection and 100% rogue detection achieved for the less challenging SDR attacks.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatramani with the technique for utilizing SCADA for sensor applications of Rondeau to include wherein the component is configured to provide supervisory control and data acquisition (SCADA) data.
One of ordinary skill in the art would have made this modification to improve the ability of the system to provide improved accuracy and precision in data collection and analysis, to facilitate real-time monitoring to detect abnormalities in performance. A system of the primary reference can be modified to utilize SCADA for sensor applications.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOWARD H LOUIE whose telephone number is (571)272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM EST.
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 W. Kim can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
1 Emphasis is additional throughout.
Prosecution Insights