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
In the remarks filed on 06/09/2026. The applicant amended claims 1,7 and 8 are amended. No claims were added.
With respect to claim objections:
Applicant’ claim amendments and remarks filed on 06/09/2026 have been fully considered and does overcome the claim objections as presented in the non-final office action filed 03/11/2026. Therefore, the objection have been withdrawn.
With respect to 112(b) rejections:
Applicant’ claim amendments and remarks filed on 06/09/2026 have been fully considered and partially overcome for claims 1,7, 8 but do not fully overcome the 112(b) rejections as presented in the non-final office action filed 03/11/2026.
With respect to 35 U.S.C. § 103 rejections:
Applicant's arguments filed on 06/09/2026 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 6-8, with respect to the rejection (s) of independent claims 1,7 and 8 have been fully considered.
Applicant argues that Pfitzmann changes security zone classification to account for observed network flows whereas claim 1 uses established classification to identify an improper flow and changes of the flow but are moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new 103 ground of rejection relies on new references in combination as presented below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-8 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1,7 and 8 recite the limitation “identifying any previously unknown paths across a first identified subnet and a second identified subnet, wherein the first identified subnet belongs to a first determined security zone, and the second identified subnet belongs to a second determined security zone as a covert path” is indefinite because “previously unknown” lacks objective boundaries. Although the claims have been amended to clarify that network connections or communication path are assessed to determine whether given network connection includes the recited path, the amendments do not provide an objective boundary for determining when path is “previously unknown”. Examiner suggest applicant to clarify the scope of the claims. The claims do not identify the entity to which the path was previously unknown such as central OT security server, network administrator, or another network management system, or the information or baseline against which the path is determined to be unknown, such as security policy information, network flow data etc., and the relevant temporal reference for “previously” , such as before receipt of the IP configuration data, before identification of the subnets or security zones, before particular monitoring cycle etc., The additional recitation that the path extends across the first and second identified subnets but does not establish what makes the path “previously unknown”. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
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.
Claims 1- 4, 6, 7, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Pfitzmann (US 20110131628 A1) in view of Lloyd (US 8479257 B1) in further view of Allen (US 20170054748 A1).
Regarding claim 1, Pfitzmann teaches s method for in operational technology (OT) security monitoring using a central OT security monitoring server, the method comprising:
receiving internet protocol (IP) configuration data of network connections among an OT network and an information technology (IT) network connected to the OT network from a data collector connected to the OT network at the security monitoring server (Pfitzmann, methods for automatically discovering security zone information in enterprise networks (i.e., OT +IT network), [0002]… by comparing enterprise security policy with observed connectivity as given by a network configuration, network statistics, and/or application behaviors, [0021] There are a number of collection techniques for network information, e.g., connectivity probing, obtaining routing table information, application connectivity logs, and firewall configuration analysis, [0022] network software and agents (i.e., the data collector) may be employed for collection techniques or the information collection techniques follows a deployment-free methodology by using simple scripts that are directly executed by the system administrators, without the need for installing agents or obtaining special credentials, [0024] One approach is to collect network configuration and run-time network-related application behavior directly from end hosts (e.g., the netstat command). The approach is realized by exporting and analyzing the configuration files of software systems in the network. It collects information from end hosts without generating any traffic that may disrupt their normal operation, [0067] FIG. 6, a system 500 for automatically discovering security classifications. A processing device 502 (i.e., the security monitoring server) is configured to format permitted network flows and flows permitted by a security policy to enable a comparison therebetween, [0083]) [Examiner interprets that network software and agents or simple scripts /commands (i.e., the data collector) collecting information by using connectivity probing, routing table information, application connectivity logs, and firewall configuration analysis (i.e., the IP configuration data of network connections) and providing it to a central processing device as limitation above].
identifying subnets among the OT network and the IT network based on the IP configuration data with the security monitoring server (Pfitzmann, In an initial stage, the netstat command is run on the individual hosts. Analysis of the gathered information (i.e., the IP configuration data) helps identify the different subnets (which are one type of network area) present in the environment, and the host IP addresses belonging to each subnet. Since each network area can belong to only one security zone, the next stage of information collection is deployed, namely connectivity probing, at only a subset of hosts per subnet (instead of all hosts), [0072] FIG. 6, a system 500 for automatically discovering security classifications. A processing device 502 (i.e., the security monitoring server) is configured to format permitted network flows and flows permitted by a security policy to enable a comparison therebetween, [0083]) [Examiner interpret that system disclosing automated subnet discovery from the collected IP configuration performed by the same central analyzer as limitation above];
determining different security zones among the OT network and the IT network based on the identified subnets with the security monitoring server (Pfitzmann, The inference method can make use of such information (i.e., IP configuration data) to derive security zones…the discovery process involves collection and analysis of network configuration information in a staged or incremental fashion…In each analysis phase, the elimination-based inference method is executed. Eventually, with sufficient information, the method will place each host or node in a unique classification, [0022] The inference method works as follows: In block 102, each network area with unknown security zone classification is assigned all possible colors (colors will be employed throughout this disclosure to generically designate classifications). For example, security zones belonging to the intranet may be referred to as blue zones, security zones belonging to extranets may be referred to as yellow zones, and security zones belonging to opennets may be referred to as red zones. A network area includes a set of computing devices that are known to have a same security classification..in particular:--the network addresses of the computing devices (if the devices are in a same subnet, they necessarily have the same security classification (at least in almost all security policies), [0033]) [Examiner interprets that system using inference method to classify the different subnets (i.e., intranet, extranets, opennets) into their respective security zones (i.e. blue zones, yellow zones, and red zones) and classifying all the network devices that are in same subnet in same security zones as determining different security zones among the OT network and the IT network based on the identified subnets];
Pfitzmann does not explicitly teach:
assesses one or more network connections between different security zones to determine whether a given network connection includes a previously unknown path across a first identified subnet and a second identified subnet and identifying any previously unknown path as a covert path if the first identified subnet belongs to a first determined security zone and the second identified subnet belongs to a second determined security zone, and upon identification of the covert path, rerouting communication from the covert path through a firewall previously avoided by the covert path
However, Lloyd teaches:
assesses one or more network connections between different security zones to determine whether a given network connection includes a previously unknown path across a first identified subnet and a second identified subnet (Lloyd, The goal is to compare the data model with a collection of statements ("access specifications") that indicate what should or should not be permitted, and then indicate non-compliance if any access is found that is either undocumented or explicitly forbidden, (col, 1, lines 66-67, col 2, lines 1-3) Segment the as-built network into Zones (Step A)… a Zone consists of a collection of IP Subnets in an IP network. It can also consist of a collection of IP endpoints in an IP network, or a mixture of IP endpoints and IP Subnets, Find all packet access between Zones by querying the as-built network (Step B). This is an automated step. C. Summarize the inter-zone packet access from Step B to obtain an access dataset (Step C), (Col 4, lines 47-58) This model works from configuration files for network equipment and can compute any traffic access within that network 10, (Col 4, lines 42-44) When two or more zones are defined and their data elements are populated, the tool analyzes the interrelationship of the zones with respect to access to data, applications, hosts, data traffic, as well as anomalies, weaknesses and defects to and from the zones. The zonal interrelationships (inter-zonal access permissions) are generated as illustrations, 5-tuple traffic access diagrams and reports as common forms, (Col 6, lines 33-39) Automatically compute the status of the network--specifically, which access is forbidden by explicit statement from Step D, which access is covered by approvals from Step D, and which access is not accounted for by any statement. This is done by comparing the access dataset with the policy set. Based on this, the whole as-built network can be described as "in compliance" with the policy set so long as all access is deemed approved (and not forbidden or undocumented), (Col 5, lines 23-32) The firewalls found between the zone pair are listed. Also, any failures found in phase 1 are also listed, indicating the source point and destination point that were connected by at least one path not passing through a requisite control point, (Col 11, 19-20, col 12 lines 1-2)) [Examiner interprets that system automatically querying and analyzing packet access between zones, and comparing discovered access against preciously recorded approvals and identifies access that is undocumented or not accounted for as limitation above]; and
identifying any previously unknown path as a covert path if the first identified subnet belongs to a first determined security zone and the second identified subnet belongs to a second determined security zone (Lloyd, "Find the Firewall" Feature, The description so far has dealt with access assessment. However, there is a related type of network compliance testing which is also contemplated as within the scope of this invention. Specifically, rather than evaluating a statement of the form "is the access from Zone A to Zone B justified?", the related statement is "does all traffic from Zone A to Zone B pass through a mandated control device?", (Col 10, lines 37-45), Phase 1, start from origin set (Internet, say), grow the set outwards, stop at firewalls. If any of the target set are found, flag a failure, (Col 11, lines 8-13) The firewalls found between the zone pair are listed. Also, any failures found in phase 1 are also listed, indicating the source point and destination point that were connected by at least one path not passing through a requisite control point, (Col 11, 19-20, col 12 lines 1-2)) [Examiner interprets that system identifying a bypass path between two zones , flagging that path as compliance failure, and lists its source and destination as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Pfitzmann to include a concept of assesses one or more network connections between different security zones to determine whether a given network connection includes; a previously unknown path across a first identified subnet and a second identified subnet and identifying any previously unknown path as a covert path if the first identified subnet belongs to a first determined security zone and the second identified subnet belongs to a second determined security zone as taught by Lloyd for the purpose of analyzing the interrelationship of the zones with respect to access to data, applications, hosts, data traffic, as well as anomalies, weaknesses and defects to and from the zones [Llyod: (Col 6, lines 34-37)].
Pfitzmann and Lloyd does not explicitly teach:
upon identification of the covert path, rerouting communication from the covert path through a firewall previously avoided by the covert path
However, Allen teaches:
upon identification of the covert path, rerouting communication from the covert path through a firewall previously avoided by the covert path (Allen, the filtering device 312 may be part of a firewall that is configured to establish a trust zone, whereby the filtering device 312 may receive data and inspect the data to determine whether to forward the data to a network of connected routers and computer systems. The network of connected routers and computer systems may be part of the trust zone, and data traffic entering or leaving the network may be regulated by the filtering device 312. For example, the filtering device 312 may receive data that is addressed to a remote computer system and may determine whether to forward the received data to the remote computer system. For example, if the filtering device 312 receives data from the local computer system 302 that is addressed to the prohibited computer system 304, the filtering device 312 may not permit the data to be forwarded to the prohibited computer system 304, [0031] The covert router may secretly cooperate with the local computer system 302 to redirect a communication originating from the local computer system 302 to the prohibited computer system 304 instead of the allowed computer system 306, [0033] a filtering device detects 402 a potential covert operation, [0038] a routing configuration may be identified as being covert or may be associated with a likelihood of being covert. If a routing path is associated with a likelihood of being covert, route tracing may be performed to identify the routers present on a routing path. Further, one or more correlations may be performed based on the likelihood to associate a router with a likelihood of covert activity. A router that is associated with a high likelihood of being covert may be “blacklisted” and routing paths that include the router may be avoided when forwarding data by, for example, causing data routing to be biased away from the covert router. [0050] A positive determination may serve as an indication of a likelihood that one or more routers of the first routing path cause packet data transmitted by the local computer system to be redirected to a prohibited computer system, [0053]) (Examiner interprets that system detecting covert routing along a first routing path that includes a covert router that redirects traffic to prohibited computer system and the filtering device (i.e., firewall) detecting such covert routing and changing routing preferences by sending it to second routing path so that no longer traverses the covert router upon identification of covert router or path as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Pfitzmann and Lloyd to include a concept of upon identification of the covert path, rerouting communication from the covert path through a firewall previously avoided by the covert path as taught by Allen for the purpose of inspecting the data to determine whether to forward the data to a network of connected routers and computer systems by the filtering device 312 if the filtering device 312 receives data from the local computer system 302 that is addressed to the prohibited computer system 304 and may not permit the data to be forwarded to the prohibited computer system 304, [Allen:0031] and redirecting a communication originating from the local computer system 302 to the prohibited computer system 304 to the allowed computer system 306, [Allen:0033].
Regarding claim 2, Pfitzmann, Lloyd, and Allen teaches the method according to claim 1, wherein the IP configuration data is acquired by the at least one data collector from collected network flow data in the OT network (Pfitzmann, network software and agents (i.e., the data collector) may be employed for collection techniques or the information (i.e., the IP configuration data) collection techniques follows a deployment-free methodology by using simple scripts that are directly executed by the system administrators, without the need for installing agents or obtaining special credentials, [0024] Obtaining information (i.e., the IP configuration data) about the allowed network flows (i.e., network flow data) manually (e.g., using a questionnaire, a database record, etc.); by analyzing configuration information on one of computing devices and network devices (e.g., servers), by analyzing configuration information on security devices (e.g., firewalls), by analyzing responses or non-responses to sending packets between network areas (e.g., routers), by sniffing, by analyzing logs, etc. Information may be derived from system configuration analysis, routing tables: subnets and groups in the same zone, active connections: app behaviors, connectivity probing, probing with existing app (deployment-free shell script), Ping: ICMP echo access info, Telnet: TCP (any port) access info, Nslookup: UDP (any port) access info, firewall configuration analysis, parsing Cisco PIX firewall configuration files to find the permitted connections, etc., [0080]) [Examiner interprets that network software and agents or scripts (i.e., the data collector) collecting information (i.e., the IP configuration data) about the allowed network flows (i.e., network flow data) with in the enterprise network (i.e. OT +IT network) as the IP configuration data is acquired by the at least one data collector from collected network flow data in the OT network].
Regarding claim 3, Pfitzmann, Lloyd, and Allen teaches the method according to claim 1, wherein the IP configuration data includes IP configuration data of network interface cards installed on OT devices in the OT network. (Pfitzmann, methods for automatically discovering security zone information in enterprise networks (i.e., OT +IT network), [0002] One approach is to collect network configuration and run-time network-related application behavior directly from end hosts (e.g., the netstat command). The approach is realized by exporting and analyzing the configuration files of software systems in the network. It collects information from end hosts without generating any traffic that may disrupt their normal operation, [0067]) [Examiner interprets that collecting network configuration and run-time network-related application behavior directly from end hosts (e.g., the netstat command) (i.e., OT devices) where netstat command returns NIC IP address, listening sockets etc. as the IP configuration data includes IP configuration data of network interface cards installed on OT devices in the OT network].
Regarding claim 4, Pfitzmann, Lloyd, and Allen teaches the method according to claim 1, wherein the IP configuration data is acquired by the data collector from logs of permitted communications in a security device in the OT network (Pfitzmann, network software and agents (i.e., the data collector) may be employed for collection techniques or the information (i.e., the IP configuration data) collection techniques follows a deployment-free methodology by using simple scripts that are directly executed by the system administrators, without the need for installing agents or obtaining special credentials, [0024] Obtaining information (i.e., the IP configuration data) about the allowed network flows …by analyzing configuration information on security devices (e.g., firewalls),..by sniffing, by analyzing logs, etc. Information may be derived from system configuration analysis, ….firewall configuration analysis, parsing Cisco PIX firewall configuration files to find the permitted connections, etc., [0080]) [Examiner interprets that network software and agents or scripts (i.e., the data collector) collecting information (i.e., the IP configuration data) about the allowed network flows to analyze configuration information on security devices (e.g., firewalls) to find the permitted connections with in the enterprise network (i.e. OT +IT network) the IP configuration data is acquired by the data collector from logs of permitted communications in a security device in the OT network].
Regarding claim 6, Pfitzmann, Lloyd, and Allen teaches the method according to claim 1, wherein determining different security zones among the OT network and the IT network based on the identified subnets comprises:
determining different security zones according to predefined relationship between security zones and their included subnets (Pfitzmann, each network area with unknown security zone classification is assigned all possible colors..For example, security zones belonging to the intranet may be referred to as blue zones, security zones belonging to extranets may be referred to as yellow zones, and security zones belonging to opennets may be referred to as red zones. A network area includes a set of computing devices that are known to have a same security classification..in particular:--the network addresses of the computing devices (if the devices are in a same subnet, they necessarily have the same security classification (at least in almost all security policies), [0033].. running the inference method is repeated until each network area has a unique color assignment, [0055]) [Examiner interprets that system assigning each network area (i.e., each subnet) all possible colors (i.e., security zones labels) according to predefined mapping of colors to security zones (e.g., intranet: blue, extranet: yellow, opennet: red)and repeatedly running the inference method until each network area retains exactly one color (i.e., security zones each subnet belongs to) as determining different security zones according to predefined relationship between security zones and their included subnets]; and
discovering covert path across a first identified subnet and a second identified subnet comprise determining that a network connection across the first identified subnet and the second identified subnet is a covert path, wherein the first identified subnet belongs to the first determined security zone and the second identified subnet belongs to the second determined security zone (Pfitzmann, each network area with unknown security zone classification is assigned all possible colors..For example, security zones belonging to the intranet may be referred to as blue zones, security zones belonging to extranets may be referred to as yellow zones, and security zones belonging to opennets may be referred to as red zones. A network area includes a set of computing devices that are known to have a same security classification..in particular:--the network addresses of the computing devices (if the devices are in a same subnet, they necessarily have the same security classification (at least in almost all security policies), [0033].. running the inference method is repeated until each network area has a unique color assignment, [0055] The processing device 502 compares permitted network flows 506 and flows permitted by a security policy 508 which includes in network areas 510. Each network area 510 is a collection of one or more computing and network devices 512 (e.g., servers, routers, firewalls, etc.)..are part of a networked computing environment 520 and include one or more security zones 522, and security classifications are defined by a security policy 508 in the zones. [0083]) [Examiner interprets system assigning every subnet (i.e., network area) all possible security zone labels (i.e. colors) and the runs its inference method until each subnet retains exactly one zone; it then compares detected network flows (i.e., the network connection) against the policy’s permitted flows, any flows not allowed by policy is flagged as covert path between two subnets (each already assigned to its respective security zone)].
Regarding claim 7 and 8, Claims 7 and 8 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except the additional elements:
Pfitzmann further teaches:
An apparatus for covert path discovering in OT security monitoring, the apparatus (Pfitzmann, A processing device 502 is configured to format permitted network flows and flows permitted by a security policy to enable a comparison, [0083]) comprising:
a memory storing computer executable instructions; at least one processor coupled to the memory (Pfitzmann, A program method 524 (e.g., Method Color) is stored in memory 504, [0084]);
at least one processor coupled to the memory and associated with a central OT security monitoring server (Pfitzmann, The processing device 502 include a plurality of computer process (which may be co-located or distributed) of be a single processor, [0083]):
a system for covert path discovering in OT security monitoring, the system comprising (Pfitzmann, FIG. 6, a system 500 for automatically discovering security classifications, [0083]):
a data collector connected to an OT network to acquired IP configuration data of network connections among the OT network and an IT network connected to the OT network (Pfitzmann, network software and agents (i.e., the data collector) may be employed for collection techniques or the information collection techniques follows a deployment-free methodology by using simple scripts that are directly executed by the system administrators, without the need for installing agents or obtaining special credentials, [0024]); and
a central security monitoring center connected with the data collector; wherein the central security monitoring center includes a memory storing computer executable instructions at least one processor coupled to the memory, wherein, upon execution of the computer executable instructions, the at least one processor: (Pfitzmann, Fig 6, The processing device 502 is connected to and works in conjunction with memory storage 504..plurality of computer process (which may be co-located or distributed) of be a single processor…compare permitted network flows 506 and flows permitted by a security policy 508);
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Pfitzmann (US 20110131628 A1) in view of Lloyd (US 8479257 B1) in further view of Allen (US 20170054748 A1) in further view of Gilbert (US 20210092093 A1).
Regarding claim 5, Pfitzmann, Lloyd, and Allen teaches the method according to The method according to wherein determining different security zones among the OT network and the IT network based on the identified subnets comprises:
discovering the covert path across a first identified subnet and a second identified subnet comprises: determining a network connection across the first identified subnet and the second identified subnet as a covert path if the network connection is not predefined as permitted by security policies in the OT network (Pfitzmann, each network area with unknown security zone classification is assigned all possible colors..For example, security zones belonging to the intranet may be referred to as blue zones, security zones belonging to extranets may be referred to as yellow zones, and security zones belonging to opennets may be referred to as red zones. A network area includes a set of computing devices that are known to have a same security classification..in particular:--the network addresses of the computing devices (if the devices are in a same subnet, they necessarily have the same security classification (at least in almost all security policies), [0033].. running the inference method is repeated until each network area has a unique color assignment, [0055] The processing device 502 compares permitted network flows 506 and flows permitted by a security policy 508 which includes in network areas 510. Each network area 510 is a collection of one or more computing and network devices 512 (e.g., servers, routers, firewalls, etc.)..are part of a networked computing environment 520 and include one or more security zones 522, and security classifications are defined by a security policy 508 in the zones. [0083] A program method 524 excludes an assignment of security classifications to network areas if an actually permitted network flow is not compliant with the flows permitted by the security policy. The program method 524 successively excludes potential classifications for a network area from an initial assignment of classifications if the pen fitted network flows between that network area and other network areas contradict the security policy for the assignment of classifications, [0084]) [Examiner interprets system assigning every subnet (i.e., network area) all possible security zone labels (i.e. colors) and the runs its inference method until each subnet retains exactly one zone; it then compares detected network flows (i.e., the network connection) against the policy’s permitted flows, any flows not allowed by policy is flagged as covert path between two subnets (each already assigned to its respective security zone)];
Pfitzmann, Lloyd, and Allen does not appear to explicitly teach:
for each two identified subnets, if there is no restriction on communication between the two identified subnets according to security policies in the OT network, counting a number of OT devices involved in network connections across the two identified subnets, and determining the two identified subnets belong to different security zones, if the number of OT devices is less than a predefined threshold
However, Gilbert teaches:
for each two identified subnets, if there is no restriction on communication between the two identified subnets according to security policies in the OT network (Gilbert, Fig 2, The network 200 includes a first OT network 210 and second OT network 220. The two OT networks 210 and 220 share the use of an IT network 230 to communicate with each other, [0040] During the first mode (also referred to as transparent mode), the first communication interface and the second communication interface are configured to pass data transmitted between the first network and the second network (i.e., the reconfigurable device is transparent to the data transmission). The reconfigurable device is also configured to collect and/or store information representing the data that is transmitted between the first network and the second network, [0014] each reconfigurable device is also configured to securely connect to a management device (e.g., an aggregator)… each candidate segment (also referred to as a candidate network portion, a candidate enclaved segment, or a target segment) has at least one management device. In these embodiments, each reconfigurable device can attempt to connect securely to the management device while continuing to transparently pass existing network traffic, [0017]) [Examiner interprets two separate OT networks (each itself a subnet) connected via IT network, each OT networks as one “Identified subnet” for the segmentation process, and the reconfigurable device does not block any traffic in the transparent mode (i.e. no restriction)];
counting a number of OT devices involved in network connections across the two identified subnets, and determining the two identified subnets belong to different security zones, if the number of OT devices is less than a predefined threshold (Gilbert, If analysis of the aggregated data confirms the appropriate placement of one or more reconfigurable devices (i.e., placed at actual choke points), then the management channel is used to direct each reconfigurable device to switch to the isolation mode, thereby forming one or more enclaved segments, [0018] In the network 500, a device 515a (also referred to as node 11) within the first OT network 510 is communicating with a device 525a (also referred to as node 5) within the second OT network 520. In addition, another device 515b (also referred to as node 3) within the first OT network 510 is communicating with a device 535b (also referred to as node 7) in the IT network 530, [0067] Table 1 above shows example traffic matrix information collected by the reconfigurable devices 550 and 560 that are configured in the transparent mode, as illustrated in FIG. 5A. The “Inside” column lists network traffic received by the inside communication interface of the corresponding reconfigurable device and the “Outside” column lists network traffic received by the outside communication interface of the corresponding reconfigurable device. As used herein, the insider communication interface refers to the communication interface that is attached to devices within a target enclaved segment, and the outside communication interface refers to the communication interface that is attached to devices outside the target enclaved segment, [0068] traffic matrix information indicates that the candidate enclaved segment is incomplete. More specifically, node 3 is communicating with node 7, but no data packet from node 7 towards node 3 is received by any inside communication interface. Accordingly, when the reconfigurable devices 550 and 560 are switched into the isolation mode, the traffic between node 3 and node 7 is blocked, In other words, to maintain existing traffic between two nodes upon definition of an enclaved segment, the traffic between these two nodes (in both directions) is received by the inside communication interface of at least one reconfigurable device as well as the outside communication interface of at least one reconfigurable device, [0069]) [Examiner interprets when the reconfigurable device sits between first network (i.e., OT subnet) and second network (i.e., IT subnet), it logs packet or flow, once it has such logs (i.e., table 1 traffic matrix) by incrementing a count for each distinct OT device IP on each side (i.e., the number of OT devices involved in network connections) as counting a number of OT devices involved in network connections across the two identified subnets, and when the traffic matrix shows that OT devices on one side only talk among themselves (i.e., count<1), then the device switches to isolation mode (i.e., block any further direct data flow between subnets) : treat them as separate security zones];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Pfitzmann, Lloyd, and Allen to include a concept of for each two identified subnets, if there is no restriction on communication between the two identified subnets according to security policies in the OT network, counting a number of OT devices involved in network connections across the two identified subnets, and determining the two identified subnets belong to different security zones, if the number of OT devices is less than a predefined threshold as taught by Gilbert for the purpose of block data between the first network and the second network so as to form an enclaved network segment of the first network [Gilbert:0004] which is protected from the rest of the IT network 530 and the public network 540 that would otherwise provide potential access for an attacker [0070].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210351980 A1: “ relates generally to industrial automation systems, and, more particularly, to autonomous deployment of security configuration and event generation policies in an industrial environment”
US 20220060445 A1: “relates generally to computer networking, and, in particular, to management of connectivity policies of a network environment”
THIS ACTION IS MADE FINAL. 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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights