DETAILED ACTION
The objection to the drawing is withdrawn based on amendments filed 03/17/2026.
The objection to the specification is withdrawn based on amendments filed 03/17/2026.
The 112(f) interpretation is withdrawn based on amendments filed 03/17/2026.
The 112(b) rejection is withdrawn based on amendments filed 03/17/2026.
Claims 2, 11, 13, and 15 are canceled.
Claims 21-24 are new.
Claims 1, 3-10, 12, 14, 16-24 are pending.
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 .
Response to Arguments
Applicant's arguments filed 03/17/2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument to claim 1 that Pi cannot implement the interception, Examiner agrees, therefore, the rejection in view of Rooyakkers, Pi, and Budampati is withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Bladow and Pi.
Regarding applicant’s argument that the combination of Rooyakkers, Pi, and Budampati, this argument is moot because Examiner does not rely upon Rooyakkers or Budampati in the new ground(s) of rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was 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.
Claim(s) 1, 4, 10, 12, 14, 18, and 20-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20220368711 A1 to Bladow et al. (Bladow) in view of WO 2018208715 A1 to Pi et al. (Pi).
Regarding claim 1, Bladow teaches a security monitoring system for monitoring low-level network communications of an industrial control environment, comprising: a worker node comprising: a network switch positioned on a network line between a process device associated with the industrial control environment and an industrial control device such that all low-level network communications from the process device to the industrial control device pass through the network switch, or an Internet of Things (IoT) device operably coupled to a port mirroring switch (Bladow [0032], e.g., a monitoring device 172 may be connected to equipment 170 in the participant OT network 120 that provides the monitoring device 172 access to network traffic. The equipment 170 may be an active device or a passive network device. In some embodiments, the equipment 170 includes a switch that includes a switched port analyzer (SPAN) port), the port mirroring switch positioned on the network line between the process device associated with the industrial control environment and the industrial control device such that all low-level network communications from the process device to the industrial control device pass through the port mirroring switch (Bladow Fig. 1 and [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location…… the equipment 170 may be a network tap. A network tap is a system that monitors events on a local network. For example, a network tap may send all passing traffic to the monitoring device 172; Note monitoring device may be placed between physical process devices 130 and intelligent devices 140) and are mirrored by the port mirroring switch on a mirroring port of the port mirroring switch (Bladow [0032], e.g., The monitoring device 172 is coupled to the SPAN port such that the switch sends a mirrored copy of network traffic passing through the switch to the monitoring device 172), the IoT device positioned at a same layer as the port mirroring switch and operably coupled to the mirroring port (Bladow Fig. 1 and [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location; Note monitoring device may be placed between physical process devices 130 and intelligent devices 140), the worker node configured to: intercept a signal as a low-level network communication from the process device to the industrial control device (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location… the equipment 170 may be a network tap. A network tap is a system that monitors events on a local network. For example, a network tap may send all passing traffic to the monitoring device 172), decode operational data from the signal based on a library of supported industrial protocols (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120), and detect a traffic pattern deviation within the decoded operational data using a [machine learning (ML)] model trained on known normal traffic pattern data by determining at least one abnormal communication in one of the industrial protocols based on at least a structure of the supported industrial protocol (Bladow [0038], e.g., The telemetry processing system 202 may include a threat detection module 210; [0039], e.g., The threat detection module 210 analyzes the telemetry data 218 to identify vulnerabilities, anomalies, intrusions, or other security threats in the OT network. In some embodiments, the threat detection module 210 uses detection rule data 220 to analyze the telemetry data 218…… A security event rule may describe how to detect a threat signature, a configuration change (e.g., a new certificate, a new source IP), anomaly detection (e.g., sensor readings that deviate from a baseline), network traffic patterns, or other characteristics associated with a security threat), send the decoded operational data over a wireless network interface (Bladow [0045], e.g., The reporting module 214 provides sanitized telemetry data 238 generated by the sanitization module 212 to the community threat intelligence system 206…… In some embodiments, the reporting module 214 is authorized to establish a direct, outgoing connection to the community threat intelligence system 306 over the Internet); at least one processor (Bladow [0098], e.g., FIG. 6 is a block diagram that illustrates a computer system 600 upon which an embodiment may be implemented…… one or more hardware processors 604) and at least one memory operably coupled to the at least one processor (Bladow [0099], e.g., The computer system 600 also includes one or more units of main memory 606); and instructions (Bladow [0100], e.g., The computer system 600 may further include one or more units of read-only memory (ROM) 608 or other static storage coupled to the bus 602 for storing information and instructions for the processor/s 604) that, when executed by the at least one processor, cause the at least one processor to implement a gateway node (Bladow [0046], e.g., The community threat intelligence system 206) configured to: receive the decoded operational data via the wireless network interface (Bladow [0046], e.g., The community threat intelligence system 206 receives and processes sanitized telemetry data 238 from a set of telemetry sanitization systems 208 deployed in a set of OT networks (e.g. participant OT network 120)), and respond to a security threat in the industrial control environment detected in the decoded operational data (Bladow [0047], [0049], e.g., The community threat intelligence system 206 may include a sanitized data receiving module 230, a threat analysis module 232…… For example, the threat intelligence data 240 may describe one or more techniques for detecting a security threat and/or one or more countermeasures for addressing a detected security threat).
Bladow does not explicitly teach, but Pi teaches the model being a machine learning model (Pi [0029], e.g., a correlation unit 401 may include… a modeling module 413…… The modeling module 413 may generate models (e.g., machine learning models) based on historical process variable data, user data, or a combination of both, to establish expected or predicted process behavior against which current realtime data can be compared).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Bladow with the teachings of Pi with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit increasing the robustness, efficiency, and effectiveness of intrusion detection systems (Pi [0006], e.g., Data may be collected from multiple software agents placed at different levels of the control network, which may autonomously activate and execute data collection, and in some instances, transform the data from a fieldbus protocol to a communication protocol that is more conducive to correlative analysis. Hence, the embodiments of the present disclosure enable the intrusion detection system to be more robust, efficient, and effective than conventional means).
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow further teaches wherein the worker node is a relay node (Bladow [0032], e.g., a monitoring device 172 may be connected to equipment 170…… the equipment 170 includes a switch) and intercepting the intercepting the signal comprises the IoT device collecting a copy of the signal via the mirroring port (Bladow [0032], e.g., The monitoring device 172 is coupled to the SPAN port such that the switch sends a mirrored copy of network traffic passing through the switch to the monitoring device 172), and the worker node comprising the IoT device is further configured to detect the security threat but not block the low-level network communications from the process device to the industrial control device (Bladow [0032], e.g., The equipment 170 may be an active device or a passive network device).
Regarding claim 10, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow further teaches wherein the worker node is further configured to, after decoding the operational data (Bladow [0033], e.g., For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120): pre-process the operational data to select certain operational data packets (Bladow [0037], e.g., the telemetry data 218 may include processed OT network traffic and/or metadata generated by the monitoring device/s 272).
Bladow does not explicitly teach, but Pi teaches to pack the selected certain operational data packets into a transfer protocol (Pi [0022], e.g., translate the extracted data to a protocol (e.g., Ethernet)), and the transfer protocol being different than a protocol of the operational data (Pi [0012], e.g., PLC data to Ethernet based data).
The motivation to combine is the same as that of claim 1.
Regarding claim 12, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow further teaches wherein the gateway node is further configured to identify a risk pattern [and quantify a risk level] within the decoded operational data based on an [AI machine learning (ML)] model trained on streaming packet data (Bladow [0039], e.g., The threat detection module 210 analyzes the telemetry data 218 to identify vulnerabilities, anomalies, intrusions, or other security threats in the OT network. In some embodiments, the threat detection module 210 uses detection rule data 220 to analyze the telemetry data 218…… A security event rule may describe how to detect a threat signature, a configuration change (e.g., a new certificate, a new source IP), anomaly detection (e.g., sensor readings that deviate from a baseline), network traffic patterns, or other characteristics associated with a security threat).
Bladow does not explicitly teach, but Pi teaches identify a quantify a risk level within the decoded operational data based on a model (Pi [0031], e.g., a correlation unit may perform a correlation of an anomaly detected by network-based intrusion detection with an anomaly detected during a host- based intrusion detection…… Such a correlation may be used for adding a level of confidence to a detected anomaly as validation that the anomaly relates to an intrusion detection, such as a cyber attack), and the model being a AI machine learning (ML) model (Pi [0029], e.g., a correlation unit 401 may include… a modeling module 413…… The modeling module 413 may generate models (e.g., machine learning models) based on historical process variable data, user data, or a combination of both, to establish expected or predicted process behavior against which current realtime data can be compared).
The motivation to combine is the same as that of claim 1.
Regarding claim 14, the claim recites a method of the system of claim 1, and is similarly analyzed.
Regarding claim 18, the claim recites a method of the system of claim 4, and is similarly analyzed.
Regarding claim 20, Bladow teaches A system for monitoring low-level network communications of an industrial control environment, comprising: at least one network switch (Bladow [0032], e.g., the equipment 170 includes a switch) positioned on a communication channel between a process device associated with the industrial control environment and a control system (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location) such that all low-level network communications from the process device to the control system pass through the network switch, or an Internet of Things (IoT) device operably coupled to a port mirroring switch, the port mirroring switch positioned on the network line between the process device associated with the industrial control environment and the industrial control device such that all low-level network communications from the process device to the industrial control device pass through the port mirroring switch and are mirrored by the port mirroring switch on a mirroring port of the port mirroring switch, the IoT device positioned at a same layer as the port mirroring switch and operably coupled to the mirroring port (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location. For example, a monitoring device 172 may be connected to equipment 170 in the participant OT network 120 that provides the monitoring device 172 access to network traffic. The equipment 170 may be an active device or a passive network device. In some embodiments, the equipment 170 includes a switch that includes a switched port analyzer (SPAN) port…… As an alternative or addition, the equipment 170 may be a network tap. A network tap is a system that monitors events on a local network. For example, a network tap may send all passing traffic to the monitoring device 172), the at least one network switch or IoT device configured to: capture a stream of control system packets from the process device (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location), decode the control system packets (Bladow [0033], e.g., a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120), preprocess the decoded control system packets to determine a subset of the decoded control system packets (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data).
Bladow does not explicitly teach, but Pi teaches to pack the subset of the [decoded] control system packets into a transfer protocol (Pi [0022], e.g., translate the extracted data to a protocol (e.g., Ethernet)), the transfer protocol being different than a protocol of the stream of control system (Pi [0012], e.g., PLC data to Ethernet based data).
The motivation to combine is the same as that of claim 1.
Pi does not explicitly teach, but Bladow teaches the control system packets being decoded (Bladow [0033], e.g., a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120).
Regarding claim 21, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow further teaches wherein determining at least one abnormal communication in one of the supported industrial protocols based on at least a structure of the supported industrial protocol comprises learning an initial connectivity pattern from the known normal traffic pattern data (Bladow [0039], e.g., The detection rule data 220 may include one or more security event rules that define when telemetry data 218 potentially indicates a security threat. A security event rule may be generated based on a known threat that has been discovered and characterized by analysts. In some embodiments, a security event rule may be generated by the community threat intelligence system 206 based on the automated and/or manual analysis of sanitized telemetry data 238 from a community of participant OT networks. A security event rule may describe how to detect a threat signature, a configuration change (e.g., a new certificate, a new source IP), anomaly detection (e.g., sensor readings that deviate from a baseline), network traffic patterns, or other characteristics associated with a security threat) and determining a deviation in the initial connectivity pattern (Bladow [0039], e.g., A security event rule may also be based on the detection of behavior associated with a security threat (e.g., a traffic pattern indicative of multiple logins, a brute force attack, or an ICMP sweep)).
Regarding claim 22, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow further teaches wherein the worker node operates between a field devices layer (Level 0) and a process control layer (Level 1) (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location…… the equipment 170 may be a network tap. A network tap is a system that monitors events on a local network. For example, a network tap may send all passing traffic to the monitoring device 172) and the gateway node (Bladow [0036], e.g., The community threat intelligence system 206) operates at a control network layer (Level 3) or a corporate network layer (Level 4) or Internet DMZ layer (Level 5) (Bladow Fig. 1, e.g., Community Threat Intelligence System is connected to a firewall which provides a connection through the DMZ).
Regarding claim 23, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow further teaches a first worker node as a visibility node (Bladow [0031], e.g., One or more monitoring devices 172-174 may be deployed in a participant OT network 120), wherein the port mirroring switch is the network switch (Bladow [0032], e.g., a monitoring device 172 may be connected to equipment 170…… the equipment 170 includes a switch that includes a switched port analyzer (SPAN) port); and a second worker node as a relay node as the IoT device (Bladow [0031], e.g., One or more monitoring devices 172-174 may be deployed in a participant OT network 120; [0032], e.g., a monitoring device 172 may be connected to equipment 170).
Regarding claim 24, most of the limitations of this claim have been noted in the rejection of claim 14. Bladow further teaches wherein the port mirroring switch is the network switch (Bladow [0032], e.g., a switch that includes a switched port analyzer (SPAN) port) and the intercepting the signal from the process device (Bladow [0032], One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location), the decoding the operational from the signal (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120), and the detecting the traffic pattern is executed at the IoT device (Bladow [0039], e.g., The threat detection module 210 analyzes the telemetry data 218 to identify vulnerabilities, anomalies, intrusions, or other security threats in the OT network).
Claim(s) 3 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bladow in view of Pi, and in further view of US 20190238470 A1 to Schwindt. (Schwindt).
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow teaches wherein the worker node is a visibility node and the visibility node comprising the network switch (Bladow [0032], e.g., The equipment 170 may be an active device or a passive network device. In some embodiments, the equipment 170 includes a switch)
Bladow and Pi does not explicitly teach, but Schwindt teaches to block at least one packet in the signal at the network switch (Schwindt [0113], e.g., If the communication packet is classified as malicious, the network switch drops the communication packet at (608)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Bladow and Pi with the teachings of Schwindt with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of preventing malicious data from being routed into the system (Schwindt [0032], e.g., Additionally, models configured to generate process behavioral classifications for communication packets can identify potentially malicious activity associated with otherwise valid communication packets…… The network switch can intelligently route and/or generate a control action based on the predicted outcome of routing a communication packet. Such techniques provide for more efficient and safe operation of the industrial control systems. Security breaches, including intrusions into networks of the systems, can be identified such that communication packets are not routed in an effort to avoid the potential adverse consequences).
Regarding claim 17, most of the limitations of this claim have been noted in the rejection of claim 14. Bladow and teaches wherein the network switch intercepts the signal (Bladow [0032], e.g., The equipment 170 may be an active device or a passive network device. In some embodiments, the equipment 170 includes a switch…… One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location).
Bladow and Pi does not explicitly teach, but Schwindt teaches blocking at least one packet in the signal at the network switch (Schwindt [0113], e.g., If the communication packet is classified as malicious, the network switch drops the communication packet at (608)).
The motivation to combine is the same as that of claim 3.
Claim(s) 5-9, 16, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bladow in view of Pi, and in further view of US 20250036103 A1 to Mills et al. (Mills).
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow and Pi do not explicitly teach but Mills teaches wherein the security monitoring system is implemented as an application container group (Mills [0026], e.g., Embodiments of the present disclosure are generally directed toward industrial automation systems that implement container technologies…… industrial automation system may include a container orchestration system in an operational technology (OT) network), and wherein the gateway node includes an application container of the application container group (Mills [0054-0055], e.g., The SaaS/FaaS platform 108 provided by the edge gateway device 82 may include platforms…… The edge gateway device 82 may communicate via the network 84 to access a software application and/or to log the data in a database 106).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Bladow and Pi with the teachings of Mills with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of improving a quality of results being produced by the operations of the containers-such as an accuracy of a prediction made by the container (Mills [0026], e.g., the container orchestration system may aid collecting and analyzing data from OT devices. Containers include packages of software that may include various elements needed to run in one or more software environments. As a result, containers may be deployed as individual software modules that perform specific operations or functions on the data provided to the respective container. Deploying a container closer to a data source may enable more direct, unprocessed access to data from the data source, which may improve a quality of results being produced by the operations of the containers-such as an accuracy of a prediction made by the container).
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 5. Bladow teaches wherein the worker node is a visibility node and the visibility node comprising the network switch (Bladow [0032], e.g., In some embodiments, the equipment 170 includes a switch) [includes a second application container of the application container group], and wherein the signal is intercepted (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location) and decoded [by a containerized network analyzer of the second application container] (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120).
Bladow and Pi do not explicitly teach, but Mills teaches a second application container of the application container group (Mills [0040], e.g., the container orchestration system 24 may include a cluster of computing devices, computing systems, or container nodes…… container nodes 30 may be implemented by the industrial control systems 12, such that they appear as worker nodes; [0038], e.g., it should be noted that containers refer to technology for packaging an application along with its runtime dependencies. That is, containers include applications that are decoupled from an underlying host infrastructure).
The motivation to combine is the same as that of claim 5.
Bladow and Pi in view of Mills do not explicitly teach operational data being intercepted and decoded by a containerized network analyzer of the second application container, however, Mills teaches that containers being deployed to field devices executed by local controllers, OT device etc. (Mills [0073], e.g., a container orchestration system 24 may determine to deploy one or more containers to one or more lower hierarchy devices of the industrial automation system 10…… Containers deployed to the field network level 122 may be executed by local controller circuitry of respective sensors, actuators, OT device, or the like). Bladow teaches monitoring devices, placed between process devices and control devices (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location), that intercept and decodes network communications (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120). Therefore, through the combination of Mills’ application containers running on the Bladow’s monitoring devices, the claim is rendered obvious.
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 5. Bladow further teaches wherein the worker node is a relay node and the relay node comprising the IoT device (Bladow [0032], e.g., a monitoring device 172 may be connected to equipment 170… In some embodiments, the equipment 170 includes a switch that includes a switched port analyzer (SPAN) port. The monitoring device 172 is coupled to the SPAN port such that the switch sends a mirrored copy of network traffic passing through the switch to the monitoring device 172) [includes a second application container of the application container group], and wherein the signal is intercepted (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location) and decoded [by a containerized network analyzer of the second application container] (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120).
Bladow and Pi do not explicitly teach, but Mills teaches a second application container of the application container group (Mills [0040], e.g., the container orchestration system 24 may include a cluster of computing devices, computing systems, or container nodes…… container nodes 30 may be implemented by the industrial control systems 12, such that they appear as worker nodes; [0038], e.g., it should be noted that containers refer to technology for packaging an application along with its runtime dependencies. That is, containers include applications that are decoupled from an underlying host infrastructure).
The motivation to combine is the same as that of claim 5.
Bladow and Pi in view of Mills do not explicitly teach operational data being intercepted and decoded by a containerized network analyzer of the second application container, however, Mills teaches that containers being deployed to field devices executed by local controllers, OT device etc. (Mills [0073], e.g., a container orchestration system 24 may determine to deploy one or more containers to one or more lower hierarchy devices of the industrial automation system 10…… Containers deployed to the field network level 122 may be executed by local controller circuitry of respective sensors, actuators, OT device, or the like). Bladow teaches monitoring devices, placed between process devices and control devices (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location), that intercept and decodes network communications (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120). Therefore, through the combination of Mills’ application containers running on the Bladow’s monitoring devices, the claim is rendered obvious.
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 5. Bladow and Pi do not explicitly teach, but Mills teaches wherein the application container group is isolated using system-level virtualization (Mills [0038], e.g., it should be noted that containers refer to technology for packaging an application along with its runtime dependencies. That is, containers include applications that are decoupled from an underlying host infrastructure (e.g., operating system))
The motivation to combine is the same as that of claim 5.
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 1. Bladow and Pi do not explicitly teach, but Mills teaches wherein the [security monitoring] system is implemented as a virtual machine (Mills [0028-0029], e.g., an industrial automation device may be virtualized at a lower level…… Virtualized industrial automation devices may include sensors, control systems, or the like. Containers may refer to OT network-based containerized applications, IT network-based containerized applications, cloud-orchestrated containerized applications…… by using virtualized devices, various containerized applications may be presented to the industrial control system as physical IO or automation controllers) and wherein the gateway node is hosted on a public cloud platform or physical platform (Mills [0054], e.g., The network 84 may be any suitable wired or wireless network, such as a network enabled by the Internet or a cloud-based network. The network 84 may be an off-premise network used by the computing device 76 to transmit data to the edge gateway device 82).
The motivation to combine is the same as that of claim 5.
Mills does not explicitly teach, but Bladow teaches a security monitoring system (Bladow [0020], e.g., This document generally describes systems, methods, devices, and other techniques for community threat intelligence for operational technology networks).
Regarding claim 16, most of the limitations of this claim have been noted in the rejection of claim 14. wherein the signal is intercepted (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location) and decoded [by a containerized network analyzer of an application container] (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120).
Bladow and Pi do not explicitly teach, but Mills teaches a second application container of the application container group (Mills [0040], e.g., the container orchestration system 24 may include a cluster of computing devices, computing systems, or container nodes…… container nodes 30 may be implemented by the industrial control systems 12, such that they appear as worker nodes; [0038], e.g., it should be noted that containers refer to technology for packaging an application along with its runtime dependencies. That is, containers include applications that are decoupled from an underlying host infrastructure).
The motivation to combine is the same as that of claim 5.
Bladow and Pi in view of Mills do not explicitly teach operational data being intercepted and decoded by a containerized network analyzer of the second application container, however, Mills teaches that containers being deployed to field devices executed by local controllers, OT device etc. (Mills [0073], e.g., a container orchestration system 24 may determine to deploy one or more containers to one or more lower hierarchy devices of the industrial automation system 10…… Containers deployed to the field network level 122 may be executed by local controller circuitry of respective sensors, actuators, OT device, or the like). Bladow teaches monitoring devices, placed between process devices and control devices (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location), that intercept and decodes network communications (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120). Therefore, through the combination of Mills’ application containers running on the Bladow’s monitoring devices, the claim is rendered obvious.
Regarding claim 19, most of the limitations of this claim have been noted in the rejection of claim 16. Bladow further teaches the network switch or the IoT device [includes a second application container] (Bladow [0032], e.g., In some embodiments, the equipment 170 includes a switch), wherein the signal is intercepted (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location) and decoded [by a containerized network analyzer of the second application container] (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120).
Bladow and Pi do not explicitly teach, but Mills teaches a second application container of the application container group (Mills [0040], e.g., the container orchestration system 24 may include a cluster of computing devices, computing systems, or container nodes…… container nodes 30 may be implemented by the industrial control systems 12, such that they appear as worker nodes; [0038], e.g., it should be noted that containers refer to technology for packaging an application along with its runtime dependencies. That is, containers include applications that are decoupled from an underlying host infrastructure).
The motivation to combine is the same as that of claim 5.
Bladow and Pi in view of Mills do not explicitly teach operational data being intercepted and decoded by a containerized network analyzer of the second application container, however, Mills teaches that containers being deployed to field devices executed by local controllers, OT device etc. (Mills [0073], e.g., a container orchestration system 24 may determine to deploy one or more containers to one or more lower hierarchy devices of the industrial automation system 10…… Containers deployed to the field network level 122 may be executed by local controller circuitry of respective sensors, actuators, OT device, or the like). Bladow teaches monitoring devices, placed between process devices and control devices (Bladow [0032], e.g., One or more monitoring devices 172-174 may be deployed at any location in the participant OT network 120 to collect network traffic passing through the respective location), that intercept and decodes network communications (Bladow [0033], e.g., A monitoring device 172-174 may process the network traffic to generate telemetry data. For example, a monitoring device 172-174 may perform deep packet inspection of communications sent in accordance with various industrial protocols to extract telemetry data related to the operation of the participant OT network 120). Therefore, through the combination of Mills’ application containers running on the Bladow’s monitoring devices, the claim is rendered obvious.
Conclusion
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 pm ET.
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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/LAWRENCE TRUONG/Examiner, Art Unit 2434
/ALI SHAYANFAR/Supervisory Patent Examiner, Art Unit 2434
Prosecution Insights