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 .
DETAILED ACTION
This final action is in response to amendment filed on 11/24/2025. In this amendment, claims 1, 8-9, 13, 18 and 20 are amended, claims 3-5 and 14-15 are canceled and claim 22-25 are added. Claims 1-2, 6-13 and 16-25 are pending, with claims 1, 13 and 20 being independent.
Response to Arguments
Objection to the Claims
Objections are withdrawn in view of amended claims.
Claim Rejections Under 35 U.S.C. § 103
Applicant’s arguments with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 of this title, 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.
Claims 1-2, 6-8, 13, 16-17, 20 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2020/0084088, Pub. Date: Mar. 12, 2020), in view of Zhou et al. (NPL: Behavior Based Anomaly Detection Model in SCADA System, Pub. Date: 2018), in view of Kozhaya et al. (US 2022/0131741, Pub. Date: Apr. 28, 2022).
As per claim 1, Zhu discloses a network management system (Zhu fig. 1 and para. [0024], FIG. 1 is a block diagram that illustrates components of the system, in accordance with one or more embodiments.) comprising:
a memory (Zhu fig. 7, Memory 706); and
one or more processors coupled to the memory (Zhu fig. 7, Processor 704 coupled to Memory 706) and configured to:
obtain data associated with one or more ports (Zhu para. [0044], The switch may even be queried periodically ... In Operation 440, the monitoring node may request status information about the target node. More specifically, the network device may provide information on the physical link connected to the target node such as whether the link is operational and how much traffic has traversed the link; Zhu para. [0048], An SNMP-enabled switch maintains a table that maps each switch port to the device connected to the switch port. The port/device mapping table can be used to discover which switch port provides the physical link that connects a particular device to the network. The switch can respond to queries for status of a physical link that corresponds to a cluster node) of a plurality of network devices (Zhu fig. 1, Network Device 110 [switch] connects to Node 120, 130 and 140 via physical links 150, 160 and 170 respectively), wherein the data of each port includes current network statistics of the port with respect to a client device (Zhu para. [0048], An SNMP-enabled switch maintains a table that maps each switch port to the device connected to the switch port. The port/device mapping table can be used to discover which switch port provides the physical link that connects a particular device to the network) physically connected to the port (Zhu fig. 1 and para. [0025], node 120 is physically connected to network device 110 by physical link 150; node 130 is physically connected to network device 110 by physical link 160; and node 140 is physically connected to network device 110 by physical link 160; Zhu para. [0057], A physical link is a physical medium connecting two or more physical nodes. Examples of links include a coaxial cable, an unshielded twisted cable, a copper cable, and an optical fiber);
identify at least one candidate client device connected to a particular port of a particular network device for which the current network statistics indicate an issue (Zhu para. [0044], the network device may provide information on the physical link connected to the target node such as whether the link is operational and how much traffic has traversed the link; Zhu para. [0046], the amount of traffic that traversed the physical link during the certain time interval may be compared against one or more thresholds. A deviation from an expected amount of traffic may raise an alert. For example, if no traffic has traversed the link during the interval, but the link is operational, the target node [candidate client device] may be hung; Zhu para. [0048], An SNMP-enabled switch maintains a table that maps each switch port to the device connected to the switch port), wherein the issue comprises a lack of network packets associated with the at least one candidate client device (Zhu para. [0050], if the switch port is known to be up but little or no traffic is transmitted or received, the device connected to the port is unable to process network packets, indicating that the node, not the network, is the problem);
output a notification of the anomalous behavior including identification information of the at least one candidate client device (Zhu para. [0022], If the link is down, the monitoring node may conclude with high probability that the target node is not available to participate in cluster tasks, and the monitoring node may share this information with other nodes in a consensus-based node eviction process).
Zhou does not explicitly disclose:
retrieve, for the at least one candidate client device, peer statistics associated with one or more peer client devices of a same device type as the at least one candidate client device, wherein the peer statistics comprise current network statistics collected over a window of time from the one or more ports of the plurality of network devices to which the one or more peer client devices are physically connected;
determine a historical deviation, wherein the historical deviation is based on a comparison of the current network statistics of the at least one candidate client device against historical baseline statistics, the historical baseline statistics being determined from the at least one candidate client device's own past behavior;
detect anomalous behavior based on an occurrence of the historical deviation;
determine a cause of the anomalous behavior based on whether the anomalous behavior of the at least one candidate device is anomalous to the one or more peer client devices based on a comparison of the current network statistics and the peer statistics; and
output a notification of the anomalous behavior including the cause of the anomalous behavior.
Zhou teaches:
retrieve, for the at least one candidate client device, peer information (Zhou pg. 3, fig. 4 and section 3 Framework for behavior-based anomaly detection mechanism: The basic anomaly detection steps include: information collection, uniquely entity determination, constructing three kinds of normal behavior baseline from different dimensions and using the baseline for anomaly detection) associated with one or more peer client devices of a same device type as the at least one candidate client device (Zhou pg. 3, section 3.3 Baseline construction: After each communication object is uniquely identified, combining the topological relations among different entities, we can construct a normal behavior baseline for each entity in the SCADA system. The establishment of normal behavior baseline is divided into three aspects: … Peer Baseline. It is based on the behavior of peer devices for analysis. Multiple devices in a SCADA system will perform the same functions. If there is a large difference in behavior between devices of the same type that perform the same function [same device type], they can be determined to be abnormal);
determine a historical deviation, wherein the historical deviation is based on a comparison of the current network statistics of the at least one candidate client device against historical baseline statistics, the historical baseline statistics being determined from the at least one candidate client device's own past behavior (Zhou pg. 3, fig. 5 and section 3.3 Baseline construction: After each communication object is uniquely identified, combining the topological relations among different entities, we can construct a normal behavior baseline for each entity in the SCADA system. The establishment of normal behavior baseline is divided into three aspects: (1) Historical Baseline. It is based on the notion that a device's role and function are relatively fixed, and therefore today's behavior and historical behavior should have obvious similarities. If there is inconsistency between the two, you can be judged as abnormal);
detect anomalous behavior based on an occurrence of the historical deviation (Zhou fig. 5, historical baseline[Wingdings font/0xE0] consistent with historical behavior pattern[Wingdings font/0xE0]NO[Wingdings font/0xE0]Alert and pg. 4, section 3.4, Anomaly detection: By building three behavioral baselines, you can quickly discover anomalous behavior);
determine a cause of the anomalous behavior (Zhou Fig. 5 and pg. 4, 5. Conclusion: Based on the collected information, we construct three different normal behavior baseline from multiple dimensions and use these to detect the attack. Experiments show that the proposed detection model can find fake attacks, data packet tampering attacks and logical sequential attacks well) based on whether the anomalous behavior of the at least one candidate device is anomalous to the one or more peer client devices based on a comparison of the current network behavior and the peer behavior (Zhou pg. 3, fig. 5 and section 3.3 Baseline construction: After each communication object is uniquely identified, combining the topological relations among different entities, we can construct a normal behavior baseline for each entity in the SCADA system. The establishment of normal behavior baseline is divided into three aspects: … Peer Baseline. It is based on the behavior of peer devices for analysis. Multiple devices in a SCADA system will perform the same functions. If there is a large difference in behavior between devices of the same type that perform the same function, they can be determined to be abnormal).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Zhu in view of Zhou for retrieving, for the at least one candidate client device, peer statistics associated with one or more peer client devices of a same device type as the at least one candidate client device, determining a historical deviation, wherein the historical deviation is based on a comparison of the current network statistics of the at least one candidate client device against historical baseline statistics, the historical baseline statistics being determined from the at least one candidate client device's own past behavior; detecting anomalous behavior based on an occurrence of the historical deviation and determining a cause of the anomalous behavior based on whether the anomalous behavior of the at least one candidate device is anomalous to the one or more peer client devices based on a comparison of the current network statistics and the peer statistics.
One of ordinary skill in the art would have been motived because it offers the advantage of detecting abnormally based on different normal behavior baselines (see Zhou pg. 3, section 3.3 Baseline construction)
Zhu-Zhou does not explicitly disclose:
wherein the peer statistics comprise current network statistics collected over a window of time from the one or more ports of the plurality of network devices to which the one or more peer client devices are physically connected;
output a notification of the anomalous behavior including the cause of the anomalous behavior
Kozhaya teaches:
the peer statistics comprise current network statistics collected over a window of time (Kozhaya table 1: statistic of port A with respect connection with Switch A [peer device]; Kozhaya para. [0013], At each device, such as at a node or a switch, frames are monitored to determine certain information [This indicates the monitoring is for current traffic]; Kozhaya para. [0063-0064], network devices (DANs) are expected to multicast supervision frames on a periodical basis (e.g. every 2 seconds), DANs supporting PRP and HSR gather statistics on the traffic received over each port, e.g., total number of received frames (CntReceivedA, CntReceivedB), number of received frames with wrong network tag (identifier) (CntWrongLanA, CntWrongLanB) etc., amongst others … The table is filled with values relative to frames exchanged within a time-window of a duration typically a multiple of the period at which supervision frames are sent) from the one or more ports of the plurality of network devices to which the one or more peer client devices are physically connected (Kozhaya fig. 1, Device 1 (DAN) physically connects to Switch A [peer device] via port A and para. [0011], A node may be a wired communication device, and in case of the redundant networks the node typically is a doubly attached node (DAN). In other words, the node is connected to two separate networks and the same information is communicated in the two separate networks (e.g. LAN A and LAN B) through separate ports (e.g. port A and port B));
output a notification of the anomalous behavior including the cause of the anomalous behavior (Kozhaya para. [0091], Situation 3 as shown in FIG. 711: In this case, the network manager detects misconfigurations and a misconfiguration alert is triggered and the network manager can notify the operator that either DAN1 or DAN2 has their ports inversely connected, i.e., port A to LAN B and port B to LAN A).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Kozhaya for the peer statistics comprise current network statistics collected over a window of time from the one or more ports of the plurality of network devices to which the one or more peer client devices are physically connected and outputting a notification of the anomalous behavior including the cause of the anomalous behavior.
One of ordinary skill in the art would have been motived because it offers the advantage of increases the accuracy of identifying wrong cabling (Kozhaya para. [0111]).
As per claim 2, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu also discloses wherein the anomalous behavior associated with the at least one candidate client device comprises an inability of the at least one candidate client device to communicate with the plurality of network devices at an optimal level (Zhu para. [0019], If an amount of data received on a network device port connected to a target cluster node falls below a threshold value, then the target cluster node may be classified as a failed node and evicted from the cluster; Zhu para. [0025], Node Cluster 100 comprises a three-node cluster including Node 120, Node 130, and Node 140 communicating with each other through Network Device 11; Zhu para. [0026], When the physical link goes down, the node connected to the link cannot communicate with the rest of the cluster).
As per claim 6, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu also discloses wherein to identify the at least one candidate client device, the one or more processors are configured to:
periodically analyze the current network statistics of the ports of the plurality of network devices during the window of time (Zhu fig. 4, Send a first query to a network device requesting network statistics for network traffic going to/from the target node at 440 and Send a second query to a network device requesting network statistics for network traffic going to/from the target node at 450 and para. [0044], The switch may even be queried periodically …. in Operation 450, the monitoring node may wait a certain interval, then issue a second query to the network device for determining how much traffic has traversed the link … In Operation 460, the difference in the statistics returned in the second response as compared to the first response is calculated to provide an indication of how much traffic traversed the physical link during the certain time interval; Zhu para. [0034], a monitoring node may monitor any number of target nodes); and
identify the at least one candidate client device connected to the particular port of the particular network device (Zhu para. [0019], If a target cluster node within a cluster is no longer connected to or responsive on a corresponding network device port, then the target cluster node may be classified as a failed node and evicted from the cluster. If an amount of data received on a network device port connected to a target cluster node falls below a threshold value, then the target cluster node may be classified as a failed node and evicted from the cluster) based on a value of received packets at the particular port (Zhu para. [0022], If the link is up, then traffic statistics provided by the switch may indicate how much data was transmitted by and received from the target node over the link during a certain interval of time; Zhu para. [0050], if the switch port is known to be up but little or no traffic is transmitted or received, the device connected to the port is unable to process network packets, indicating that the node, not the network, is the problem) and from the at least one candidate client device being equal to zero during the window of time (Zhu para. [0046], if no traffic has traversed the link during the interval, but the link is operational, the target node may be hung).
As per claim 7, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu also discloses wherein the current network statistics of each of the ports (Zhu para. [0044], The switch may even be queried periodically or otherwise, without detection of any triggering event. In Operation 440, the monitoring node may request status information about the target node. More specifically, the network device may provide information on the physical link connected to the target node such as whether the link is operational and how much traffic has traversed the link; Zhu para. [0048], An SNMP-enabled switch maintains a table that maps each switch port to the device connected to the switch port. The port/device mapping table can be used to discover which switch port provides the physical link that connects a particular device to the network. The switch can respond to queries for status of a physical link that corresponds to a cluster node) of the plurality of network devices (Zhu fig. 1 and para. [0025], node 120 is physically connected to network device 110 by physical link 150; node 130 is physically connected to network device 110 by physical link 160; and node 140 is physically connected to network device 110 by physical link 160) include one or more of a value of received packets, a value of sent packets (Zhu para. [0026], The status information may also include statistical information regarding the amount of traffic that has been send/ received over the physical link), an indication that the client device is physically connected to the port, an indication that the port has traffic, a medium access control (MAC) address of the client device physically connected to the port, or a device type of the client device physically connected to the port.
As per claim 8, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu also discloses wherein one or more features of the current network statistics, the historical baseline statistics, and the peer statistics for the at least one candidate client device comprise one or more of:
a duration for which the current network statistics of the particular port of the particular network device to which the at least one candidate client device is physically connected are below a minimum threshold;
a current value of sent packets from the particular port to the at least one candidate client device (Zhu para. [0019], If an amount of data received on a network device port connected to a target cluster node falls below a threshold value, then the target cluster node may be classified as a failed node; Zhu para. [0026], The status information may also include statistical information regarding the amount of traffic that has been send/ received over the physical link);
a ratio of a historical baseline value of received packets at the particular port to a historical baseline value of sent packets from the particular port;
a ratio of the current value of sent packets to the historical baseline value of sent packets; or
a ratio of an average value of received packets at the ports of the plurality of network devices from the peer client devices of the same device type as the at least one candidate client device to the historical baseline value of sent packets.
Per claims 13 and 16-17, they do not teach or further define over the limitations in claims 1 and 6-7 respectively. As such, claims 13 and 16-17 are rejected for the same reasons as set forth in claims 1 and 6-7 respectively.
Per claim 20, it does not teach or further define over the limitations in claim 1. As such, claim 20 is rejected for the same reasons as set forth in claim 1.
As per claim 23, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhou also discloses wherein the cause of the anomalous behavior is a single device when the anomalous behavior is anomalous to one or more peer devices (Zhou pg. 3, section 3.3 Baseline construction: After each communication object is uniquely identified, combining the topological relations among different entities, we can construct a normal behavior baseline for each entity in the SCADA system. The establishment of normal behavior baseline is divided into three aspects: … Peer Baseline. It is based on the behavior of peer devices for analysis. Multiple devices in a SCADA system will perform the same functions. If there is a large difference in behavior between devices of the same type that perform the same function, they can be determined to be abnormal).
Similar rationale in claim 1 is applied.
As per claim 24, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhou also discloses wherein the cause of the anomalous behavior is a device type when the anomalous behavior is non-anomalous to the one or more peer devices (Zhou pg. 3, fig. 5, detecting normal behavior of an entity and section 3.3 Baseline construction: After each communication object is uniquely identified, combining the topological relations among different entities, we can construct a normal behavior baseline for each entity in the SCADA system. The establishment of normal behavior baseline is divided into three aspects: Peer Baseline. It is based on the behavior of peer devices for analysis. Multiple devices in a SCADA system will perform the same functions. If there is a large difference in behavior between devices of the same type that perform the same function, they can be determined to be abnormal. [Fig.5 and page 3 indicate that anomaly detected after behavior consistent with peer behavior patter [non-anomalous with behavior of devices of the same type], indicates that anomaly occurs for all devices of the same type]).
Similar rationale in claim 1 is applied.
Claims 9-10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2020/0084088, Pub. Date: Mar. 12, 2020), in view of Zhou et al. (NPL: Behavior Based Anomaly Detection Model in SCADA System, Pub. Date: 2018), in view of Kozhaya et al. (US 2022/0131741, Pub. Date: Apr. 28, 2022), in view of Keld et al. (US 2022/0201023, Pub. Date: Jun. 23, 2022).
As per claim 9, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu does not explicitly disclose wherein to detect the anomalous behavior of the at least one candidate client device, the one or more processors are configured to:
apply one or more features of the current network statistics and the peer statistics for the at least one candidate client device to a machine learning model as input;
receive, as output from the machine learning model, a behavior score associated with the at least one candidate client device; and
detect the anomalous behavior of the at least one candidate client device with respect to one or both of the historical baseline statistics associated with the at least one candidate client device or the peer statistics associated with the peer client devices based on the behavior score exceeding a threshold value.
Kels teaches:
apply the one or more features of the current network statistics and the peer statistics for the at least one candidate client device (Kels fig. 5 and para. [0053], behavioral information is received from a first device and a second device in a network; Keld para. [0025], Behavioral information generally refers to computing-device behavior or activity, which may include any information that indicates the health or status of a computing device and its software. For example, battery health, network connection status, metadata, statistical data about the telemetry of the device or its software (e.g., device A received 20 MBs of information from device B at time X), cloud configuration status, etc. Behavioral information may be comprised of health information of a device and its software and/or observation data of a device from other neighboring devices connected within a network segment) to a machine learning model as input (Kels fig. 5 and para. [0053], based on determining that the third device has the inactive operational status based on the received behavioral information form the first device and the second device and base on each indication form the first device and the second device, an abnormality score is generated for the third device using detection logic. Although not shown for clarity, in some embodiments using anomaly detection logic comprises a trained machine-learning model; Kels para. [0048], It is contemplated that any suitable supervised machine-learning model or algorithm such as, but not limited to, a neural network, logistic regression … Training data utilized in supervised learning to train the model(s) or logic may include labeled training data, which may be derived from previous, historical incidents or simulated incidents. As a result of having a trained machine learning model, embodiments are able to learn the normal reporting patterns of devices within a network which enables the trained machine-learning model to efficiently and accurately predict when a device is dysfunctional or exhibiting abnormal behavior);
receive, as output from the machine learning model, a behavior score associated with the at least one candidate client device (Kels fig. 5 and para. [0053], an abnormality score is generated for the third device using detection logic); and
detect the anomalous behavior of the at least one candidate client device with respect to one or both of the historical baseline statistics associated with the at least one candidate client device or the peer statistics associated with the peer client devices based on the behavior score exceeding a threshold value (Kels fig. 5 and para. [0053], At step 506, it is determined that the abnormality score exceeds an anomaly threshold; Kels para. [0044], any suitable combination of portions of method 300 may be implemented into various components of abnormal behavior detector 210 such that abnormal device behavior within an enterprise network is identified by analyzing behavioral information of a dysfunctional device through analysis of behavioral information reported by the dysfunctional device's neighbors and, using a trained machine-learning model or other anomaly detection logic, scoring the behavioral information to determine whether the score exceeds an anomaly threshold).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Kels for applying the one or more features of the current network statistics and the peer statistics for the at least one candidate client device to a machine learning model as input; receiving, as output from the machine learning model, a behavior score associated with the at least one candidate client device; and detecting the anomalous behavior of the at least one candidate client device with respect to one or both of the historical baseline statistics associated with the at least one candidate client device or the peer statistics associated with the peer client devices based on the behavior score exceeding a threshold value.
One of ordinary skill in the art would have been motived because it offers the advantage of providing efficiently and accurately prediction about exhibiting abnormal behavior of device (Kels para. [0017]).
As per claim 10, Zhu-Zhou-Kozhaya-Kels discloses the system according to claim 9, as set forth above, Zhu-Kels also discloses wherein the machine learning model is generated using supervised machine learning techniques to train a regression algorithm based on historic time series data (Kels para. [0048], It is contemplated that any suitable supervised machine-learning model or algorithm such as, but not limited to, a neural network, logistic regression … Training data utilized in supervised learning to train the model(s) or logic may include labeled training data, which may be derived from previous, historical incidents or simulated incidents. As a result of having a trained machine learning model, embodiments are able to learn the normal reporting patterns of devices within a network which enables the trained machine-learning model to efficiently and accurately predict when a device is dysfunctional or exhibiting abnormal behavior) of the ports of the plurality of network devices (Zhu fig. 1 and para. [0025], node 120 is physically connected to network device 110 by physical link 150; node 130 is physically connected to network device 110 by physical link 160; and node 140 is physically connected to network device 110 by physical link 160).
Similar rationale in claim 9 is applied.
As per claim 18, Zhu-Zhou-Kozhaya discloses the method according to claim 13, as set forth above, Zhu does not explicitly disclose wherein detecting the anomalous behavior of the at least one candidate client device comprises:
applying one or more features of the current network statistics, the historical baseline statistics, and the peer statistics for the at least one candidate client device to a machine learning model as input;
receiving, as output from the machine learning model, a behavior score associated with the at least one candidate client device; and
detecting the anomalous behavior of the at least one candidate client device with respect to one or both of the historical baseline statistics associated with the at least one candidate client device or the peer statistics associated with the peer client devices based on the behavior score exceeding a threshold value.
Kels teaches:
applying the one or more features of the current network statistics, the historical baseline statistics (Kels para. [0048], Training data utilized in supervised learning to train the model(s) or logic may include labeled training data, which may be derived from previous, historical incidents or simulated incidents. As a result of having a trained machine learning model, embodiments are able to learn the normal reporting patterns of devices within a network which enables the trained machine-learning model to efficiently and accurately predict when a device is dysfunctional or exhibiting abnormal behavior; Kels para. [0049], an administrator may configure a pre-determined rule, included in the anomaly detection logic, indicating benign or malicious behavior, such as a specific feature value of the behavioral, device, or network environment information. In an embodiment, heuristics, rules, or other logic may be learned, automatically set, or configured, from historic data such as past incidents of detected malicious or benign activity (e.g., a malware attack or hacking event representing malicious activity, or a system upgrade representing benign activity)), and the peer statistics for the at least one candidate client device (Kels fig. 5 and para. [0053], behavioral information is received from a first device and a second device in a network; Keld para. [0025], Behavioral information generally refers to computing-device behavior or activity, which may include any information that indicates the health or status of a computing device and its software. For example, battery health, network connection status, metadata, statistical data about the telemetry of the device or its software (e.g., device A received 20 MBs of information from device B at time X), cloud configuration status, etc. Behavioral information may be comprised of health information of a device and its software and/or observation data of a device from other neighboring devices connected within a network segment) to a machine learning model as input (Kels para. [0037], using a machine-learning model trained on data corresponding to various types of anomalies, embodiments generate an abnormality score for aggregated behavioral information received from the neighboring devices);
receiving, as output from the machine learning model, a behavior score associated with the at least one candidate client device (Kels fig. 5 and para. [0053], an abnormality score is generated for the third device using detection logic); and
detecting the anomalous behavior of the at least one candidate client device with respect to one or both of the historical baseline statistics associated with the at least one candidate client device or the peer statistics associated with the peer client devices based on the behavior score exceeding a threshold value (Kels fig. 5 and para. [0053], At step 506, it is determined that the abnormality score exceeds an anomaly threshold; Kels para. [0044], any suitable combination of portions of method 300 may be implemented into various components of abnormal behavior detector 210 such that abnormal device behavior within an enterprise network is identified by analyzing behavioral information of a dysfunctional device through analysis of behavioral information reported by the dysfunctional device's neighbors and, using a trained machine-learning model or other anomaly detection logic, scoring the behavioral information to determine whether the score exceeds an anomaly threshold).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Kels for applying the one or more features of the current network statistics, the historical baseline statistics, and the peer statistics for the at least one candidate client device to a machine learning model as input; receiving, as output from the machine learning model, a behavior score associated with the at least one candidate client device; and detecting the anomalous behavior of the at least one candidate client device with respect to one or both of the historical baseline statistics associated with the at least one candidate client device or the peer statistics associated with the peer client devices based on the behavior score exceeding a threshold value.
One of ordinary skill in the art would have been motived because it offers the advantage of providing efficiently and accurately prediction about exhibiting abnormal behavior of device (Kels para. [0017]).
Claims 11 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2020/0084088, Pub. Date: Mar. 12, 2020), in view of Zhou et al. (NPL: Behavior Based Anomaly Detection Model in SCADA System, Pub. Date: 2018), in view of Kozhaya et al. (US 2022/0131741, Pub. Date: Apr. 28, 2022), in view of Agrawal et al. (US 2022/0294715, Filed date: Mar. 9, 2021).
As per claim 11, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu does not explicitly disclose wherein to output the notification, the one or more processors are configured to output the notification of the anomalous behavior via one or more of a user interface, Application Programming Interface (API), webhook, or email for display on a user interface device of an administrator associated with the particular network device to which the at least one candidate client device is physically connected.
Agrawal teaches:
the one or more processors are configured to output the notification of the anomalous behavior via one or more of a user interface, Application Programming Interface (API) (Agrawal para. [0037], WAN accessible service 130 may notify the embedded system 150 of device 145 that anomaly conditions and/or a new version of an appropriate trained machine learning model are available for download by the device; Agrawal para. [0037], The API 335 may enable the host processing device 325 to send commands and/or data to and receive commands and/or data from communication module 350; Agrawal para. [0075], FIG. 3 is a block diagram of an example device 305 having a remotely accessible embedded system 315. The device 305 may include any of the aforementioned types of devices having an embedded system, and in one embodiment corresponds to a device 145 of FIG. 1), webhook, or email for display on a user interface device of an administrator associated with the particular network device to which the at least one candidate client device is physically connected.
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Agrawal for the one or more processors are configured to output the notification of the anomalous behavior via one or more of a user interface, Application Programming Interface (API), webhook, or email for display on a user interface device of an administrator associated with the particular network device to which the at least one candidate client device is physically connected.
One of ordinary skill in the art would have been motived because it offers the advantage of informing user about the issue so that the user can take appropriate action accordingly (see Agrawal para. [0037]).
As per claim 21, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu does not explicitly disclose wherein the one or more processors are configured to send a command to reconfigure the at least one candidate client device to at least one of change a parameter setting or install a different software version.
Agrawal teaches:
one or more processors are configured to send a command to reconfigure the at least one candidate client device to at least one of change a parameter setting or install a different software version (Agrawal para. [0025], In instances where the embedded system 150 cannot connect directly to WAN accessible service 130 (e.g., as a result of first time use of device 145, due to a problem with the version of the firmware component installed on embedded system 150, etc.), WAN accessible service may use the session with remote control application 120 as a proxy for communicating with, and delivering firmware updates to, embedded system 150).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Agrawal for sending a command to reconfigure the at least one candidate client device to at least one of change a parameter setting or install a different software version.
One of ordinary skill in the art would have been motived because it offers the advantage of providing enhanced capabilities or correcting software errors (Agrawal para. [0024]).
Claims 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2020/0084088, Pub. Date: Mar. 12, 2020), in view of Zhou et al. (NPL: Behavior Based Anomaly Detection Model in SCADA System, Pub. Date: 2018), in view of Kozhaya et al. (US 2022/0131741, Pub. Date: Apr. 28, 2022), in view of Srinivas et al. (US 2006/0150008, Pub. Date: Jul. 6, 2006), in view of Hayashi et al. (US 2018/0165143, Pub. Date: Jun. 14, 2018).
As per claim 12, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu also teaches the particular port to which the at least one candidate client device is physically connected (Zhu fig. 1 and para. [0025], node 120 is physically connected to network device 110 by physical link 150; node 130 is physically connected to network device 110 by physical link 160; and node 140 is physically connected to network device 110 by physical link 160; Zhu para. [0048], An SNMP-enabled switch maintains a table that maps each switch port to the device connected to the switch port. The port/device mapping table can be used to discover which switch port provides the physical link that connects a particular device to the network).
Zhu does not explicitly disclose:
wherein the one or more processors are configured to send an automated restart command to the particular network device to restart the particular port, and
output the notification in response to continued detection of the anomalous behavior of the at least one candidate client device after the restart of the particular port of the particular network device.
Srinivas teaches:
the one or more processors are configured to send an automated restart command to restart the particular port (Srinivas para. [0064], If the expert diagnostic agent 312 decides that corrective action (block 880) is possible, the rules database 316 sends a request for a tool 328 to the tools suite 336. The request for a tool 328 may contain a reference to the identified port and a request to restart the port).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Srinivas for the one or more processors are configured to send an automated restart command to the particular network device to restart the particular port to which the at least one candidate client device is physically connected.
One of ordinary skill in the art would have been motived because it offers the advantage of performing corrective action (see Srinivas para. [0064]).
Zhu-Srinivas does not explicitly disclose:
the one or more processors are configured to output the notification in response to continued detection of the anomalous behavior of the at least one candidate client device after the restart of the particular port of the particular network device.
Hayashi teaches:
the one or more processors are configured to output the notification in response to continued detection of the anomalous behavior of the at least one candidate client device after performing corrective action (Hayashi para. [0004], if a fault, an error, or the like occurs again in the device after the maintenance work, the occurrence of the fault, the error, or the like is notified to the management device or the like).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Hayashi for outputting the notification in response to continued detection of the anomalous behavior of the at least one candidate client device after the restart of the particular port of the particular network device.
One of ordinary skill in the art would have been motived because it offers the advantage of informing management device so that the management device can take action accordingly.
Per claim 19, it does not teach or further define over the limitations in claim 12. As such, claim 19 is rejected for the same reasons as set forth in claim 12.
Claims 22 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2020/0084088, Pub. Date: Mar. 12, 2020), in view of Zhou et al. (NPL: Behavior Based Anomaly Detection Model in SCADA System, Pub. Date: 2018), in view of Kozhaya et al. (US 2022/0131741, Pub. Date: Apr. 28, 2022), in view of Panse at al. (US 2023/0131894, Filed: Oct. 21, 2021)
As per claim 22, Zhu-Zhou-Kozhaya discloses the system according to claim 1, as set forth above, Zhu does not explicitly disclose wherein the historical baseline statistics are seasonally-aware based on seasonality data.
Panse teaches:
the historical baseline information are seasonally-aware based on seasonality data ([Per specification of examined application, para. 48 indicates seasonality data may include data regarding time of day]. Panse para. [0071], the baseline metrics for each DCN to be analyzed are calculated at the beginning of a time period and stored until they need to be updated. For instance, if a 30-day baseline period is used and this changes each day, then the baseline metrics are recalculated at the beginning of each day and stored for the entire day).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Zhu in view of Panse for the historical baseline statistics are seasonally-aware based on seasonality data.
One of ordinary skill in the art would have been motived because it offers the advantage of identifying a particular computer node as a threat (see Panse Abstract).
Per claim 25, it does not teach or further define over the limitations in claim 22. As such, claim 25 is rejected for the same reasons as set forth in claim 22.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lemberg et al. (US 20230033647) Method And System For Evaluating Peer Groups For Comparative Anomaly;
Savalle et al. (US 20210360059) Detection Of Isolated Changes In Network Metrics Using Smart-Peering;
Das et al. (US 20190182278) Method For Protecting IOT Devices From Intrusions By Performing Statistical Analysis.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINH NGUYEN whose telephone number is (571)272-4487. The examiner can normally be reached Monday-Friday: 7:30 AM - 5:30 PM. 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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/VINH NGUYEN/Examiner, Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights