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 .
Claims 1-26 are canceled. Claims 27-52 are pending.
Response to Arguments
Applicant’s arguments, filed 02/26/26, with respect to the rejection of claims 27-52 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of newly found references, as set forth below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 27-52 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As per claim 27:
Step 1: Statutory Category: The claim is directed to a machine or manufacture.
Step 2A, Prong 1: Is the claim directed to a judicial exception? Under Step 2A, we must look at the focus or "heart" of the claim to see if it is directed to a judicial exception, such as an abstract idea (e.g., mathematical concepts, certain methods of organizing human activity, or mental processes). Stripped of the generic hardware (processor, memory, network device), the functional steps of the claim are:
Receiving data (a generic security rule based on various information sources).
Receiving more data (device configuration and telemetry).
Processing/Translating data (compiling the generic rule into a device-specific programming language).
Transmitting data (sending the rule to the device).
Collecting information, analyzing it, and presenting the results (or translating data from one format to another) falls under the abstract idea categories of "mental processes". Humans can, in their minds or with pen and paper, take a general rule, look at a device's specific specs, and translate that rule into a device-specific format. Therefore, the claim is directed to an abstract idea based on a mental process.
Step 2A, Prong 2: Does the claim integrate the abstract idea into a practical application?
The claim describes generating a "device-specific security rule" based on "compiling." However, it claims this at a very high level of generality. It does not explain how this compilation process is technically achieved in a novel way, nor does it claim the actual execution of the rule on the device to physically prevent an attack.. It merely stops at sending the translated rule. The hardware recited is invoked merely as a tool to execute the abstract idea.
Step 2B: Does the claim recite an Inventive Concept?
The physical elements of the claim are: "at least one processor", "at least one memory", "communication network", "network device". These elements are "well-understood, routine, and conventional" elements in the field. Furthermore, the functions of receiving data, compiling/translating data based on configuration info, and sending data over a network are classic, routine computer functions. There is no specialized hardware or unconventional ordered combination of steps recited.
As per claims 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 42, 43, 44, 45:
These claims specify the types of data being received, processed, or generated. For example, they limit the data to DDoS/botnet attacks (28, 30, 43), specify device/topology info (31, 33-35), or detail specific telemetry formats like SNMP traps, IPFIX, or gRPC data (37, 45). Claim 32 simply spells out receiving and generating based on the data already mentioned in Claim 27. Claim 42 specifies the output format.
Collecting information, analyzing it, and displaying or transmitting certain results is abstract. Specifying what the information is, even if it is highly technical network telemetry or specific attack types, constitutes mere "data gathering" or limiting the abstract idea to a specific "field of use." These limitations do not change the fundamental nature of the claim from being an abstract process of data translation.
As per claim 38, generating the rule by solving a "constraint satisfaction problem" based on inputs and limits. Gathering inputs (policies, goals, limits) to solve a constraint problem can also be characterized as a mental process.
Claim 27 simply adds another abstract idea without providing a specific technological solution to how the network operates.
As per claims: 46, 47, 48, 49:
These claims add a feedback loop: receive feedback (46), determine if the rule's efficacy falls below a threshold (47), and generate a new or modified rule based on that feedback (48, 49).
Evaluating data against a threshold and updating rules iteratively are considered fundamental human mental steps or standard programming logic. Without reciting how the efficacy is calculated using unconventional technical means, or how the network dynamically restructures itself in a novel way.
As per claims: 40, 41:
Claim 40 states the rule is generated based on a hardware capability. Claim 41 states the rule is generated "in a manner tending to minimize resource consumption at the network device." Claim 41 is the strongest claim in this set because "minimizing resource consumption" points directly to a technological improvement in computer functionality (a strong argument under Step 2A, Prong 2). However, claim 41 is "result-oriented” and the result of an abstract idea is not patent eligible. An abstract idea (saving resources); technical means by which that result is achieved. Claim 41 only claims the "manner tending to minimize" without explaining the actual technical steps of how it minimizes consumption.
As per claim 50: This claim outlines the steps of receiving a generic security rule, receiving device telemetry/configuration, compiling a device-specific rule, and sending it.
Step 1 (Statutory Category): Yes. It is a process/method.
Step 2A, Prong 1 (Abstract Idea): Yes. Functionally, this is the exact method analogous to the apparatus in claim 27. It is directed to the abstract idea of collecting data, analyzing/translating it into a new format (compiling), and transmitting the results. The courts routinely classify this as a "mental process" or "method of organizing human activity."
Step 2A, Prong 2 (Practical Application): No. The claim ends at "sending the device-specific security rule toward the network device." It does not claim any actual improvement to the network's operation or physical execution of the rule that solves a technological problem.
Step 2B (Inventive Concept): No. The steps are performed using generic network components (a communication network, a network device).
As per claim 51: This claim is drafted from the perspective of the network device itself. It sends its info, receives a rule, performs an application of the rule, sends feedback, receives a second rule, and performs an application of the second rule.
Step 1 (Statutory Category): Yes. It is a machine/manufacture (apparatus).
Step 2A, Prong 1 (Abstract Idea): Yes. The core focus is a data-driven feedback loop: sending status, receiving instructions, acting on them, reporting back, and updating. This is a fundamental concept of organization and logic.
Step 2A, Prong 2 (Practical Application): This claim is stronger than Claim 50 because it actually recites performing an application of the rule at the device, rather than just sending it into the void. However, "apply it on a computer" or "execute the rule" is not enough to constitute a practical application. The claim lacks the technical "how." How is the rule applied? Without reciting the specific technical execution, "performing an application" is viewed as generic computer functionality.
Step 2B (Inventive Concept): No. Executing rules and sending feedback are well-understood, routine, and conventional activities for network devices.
As per claim 52: Similar to Claim 50, but focuses on receiving a rule based on a programming language, compiling it, and "initiating configuration of the network device to use" the rule.
Step 1 (Statutory Category): Yes. It is a machine/manufacture (apparatus).
Step 2A, Prong 1 (Abstract Idea): Yes. It is directed to data collection and translation/compilation.
Step 2A, Prong 2 (Practical Application): No. The phrase "initiate configuration of the network device" is functionally very similar to "sending" the rule in Claim 50. It describes the result (the device gets configured) but not the technical means by which the configuration improves the system.
Step 2B (Inventive Concept): No. The components and compilation steps are generic.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 27-50 and 52 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for gathering telemetry and configuration files by referencing known protocols, does not reasonably provide enablement for “based on compiling of the security rule based on the network device information”. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make the invention commensurate in scope with these claims. While paragraph 0060 discloses “high-level language may be configured to support compiling of security rules between languages”, the disclosure lacks detailed algorithms, or data structures explaining how a complier translates a generic policy into a resource optimized, hardware specific rule. The automated translation of gathered information into optimized and device specific rules is described largely functionally. Additionally, the specification 0058, states the system compiles rules and solves a “constraint satisfaction problem”, but does not provide the underlying algorithm or model for how that constraint is solved. The specification states, 0048, “advance AI/ML algorithms” without detailing the training data structures or algorithm logic.
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 27-52 are 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.
As per claims 27, 50-52:
"based on compiling of the security rule based on the network device information" wherein "based on compiling" makes the exact inputs of the compilation step unclear, as compiling is not previously mentioned.
"wherein the device-specific security rule is based on a programming language" is unclear. Does this mean the rule is written in a specific programming language? Or does it mean the logic of the rule targets a programming language capability on the device?
Claim 41: Recites generating the rule "in a manner tending to minimize resource consumption." What is the baseline for "tending to minimize"? This term is unclear and renders the claim indefinite.
Claim 47: Recites determining if the efficacy "fails to satisfy a threshold." The specification does not explicitly define what this threshold is, how it is calculated, or how the threshold is set.
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 27-52 are rejected under 35 U.S.C. 103 as being unpatentable over Nicoll et al., US 11,212,322 and further in view of Campo et al., WO 2019/201458.
Regarding claims 27 and 50, Nicoll teaches an apparatus (Fig. 2, security policy configuration system 202), comprising:
at least one processor (processor 220); and at least one memory (memory 222) storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
receive, for a communication network (Figs. 3 and 8, plant network 306) including a network device (industrial assets 308), a security rule that is based on a set of security policies and Internet information (col. 8 lines 29-34: Policy translation component 208 can be configured to generate security rule data based on the annotated nodal diagram, where the security rule data defines a set of security rules inferred by the system 202 based on analysis of the nodal diagram.).
Nicoll lack or does not expressly disclose receiving a security rule that is based on a set of security attack sample information. However, Campo teaches receiving a security rule that is based on a set of security policies, security attack sample information, and Internet information (Summary: “The user data node receives at least one rule originating from a policy node. Said at least one rule comprises attack information provided to the policy node, and an identifier of the application to which the attack information applies. The attack information relates to the management of the attack and the attack information comprises a type of attack, a set of detection conditions relating to detection of attacks of the type of attack, and a mitigation action to be invoked.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nicoll with Campo to include receiving a security rule based on security attack sample information in order to detect and mitigate attacks according to the rule, as taught by Campo.
Nicoll as modified above further discloses
security attack sample information, and Internet information;
receive, for the network device, network device information that includes network device configuration information indicative of a configuration of the network device and network telemetry data of the network device (Fig. 9, steps 902-908: Col. 17, line 5-col. 18, line 32: Step 902: design data for an industrial automation system is read from one or more industrial control project development platforms using a device configuration tool. 904, model data representing a nodal diagram of the industrial automation system is generated based on the design data read at step 902. The nodal diagram can define industrial and network devices that make up the industrial control system as well as the network connections between the devices. The device and network connectivity information included in the model data can be obtained or inferred by the system based on the design data.);
generate, based on compiling of the security rule based on the network device information, a device-specific security rule for the network device, wherein the device-specific security rule is based on a programming language (Fig. 9, steps 910-912: Generate a set of security rules based on analysis of the annotated nodal diagram and generate device-level security configuration instructions for implementation on one or more of the devices based on the security rules); and
send the device-specific security rule toward the network device (914: send the security configuration instructions to the devices).
As per claim 50, this is a method version of the claimed apparatus discussed above in claim 1 wherein all claimed limitations have also been addressed and/or cited as set forth above.
Regarding claims 28-30 and 43, Nicoll lack or does not expressly disclose a type of attack information. However, Campo teaches apparatus of claim 27, wherein the security rule is related to at least one of a distributed denial-of-service (DDOS) attack or a botnet attack;
a set of security attack samples or security attack sample analysis information output based on analysis of one or more security attack samples;
wherein the security attack sample information is based on at least one actual distributed denial-of-service (DDOS) attack sample;
wherein the device-specific security rule is related to at least one of a distributed denial-of-service (DDOS) attack or a botnet attack
(“The type of attack may indicate DoS, DDoS, Spoofing, etc. Furthermore, the type of attack may also comprise additional, more detailed information, like ping scan, SYN flood, GET/POST flooding, volume based, etc.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nicoll with Campo to include a DDOS attack in order to mitigate many different types of attacks, as taught by Campo.
Regarding claim 31, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the Internet information includes at least one of device information, topology information, or service information (col. 18, line 64: The network can include public networks such as the internet, intranets, and automation networks such as control and information protocol (CIP) networks including DeviceNet, ControlNet, and Ethernet/IP. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, near field communication (NFC), Bluetooth, and so forth. In addition, the network devices can include various possibilities (hardware and/or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and/or other devices.).
Regarding claim 32, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive the set of security policies, the security attack sample information, and the Internet information; and generate the security rule based on the set of security policies, the security attack sample information, and the Internet information (Fig. 9: 910-912).
Regarding claim 33, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the network device configuration information includes at least one of an indication of a vendor of the network device, an indication of at least one capability of the network device, an indication of a capacity of the network device, or an indication of at least one device-specific format supported by the network device (col. 8 lines 39-45: policy translation component 208 can translate the security rules to vendor-specific and model-specific security configuration instructions based on translation rules 226 stored on memory 222, which can define appropriate configuration instruction formats or available security settings for devices of various types and vendors.).
Regarding claim 34, Nicoll, as modified above, further discloses the apparatus of claim 33, wherein the at least one capability of the network device includes at least one of a hardware capability supported by the network device, an operating system capability supported by the network device, or a programming language capability supported by the network device (Industrial assets 308 can also include the network infrastructure devices (e.g., routers, hubs, switches, firewalls, etc.) that make up the backbone of the plant network 306 and which manage data transfer and security between network devices and network segments.).
Regarding claim 35, Nicoll lacks or does not expressly disclose an indication of capacity. However, Campo teaches wherein the indication of the capacity of the network device includes at least one of an indication of an amount of central processing unit resources available at the network device, an indication of an amount of memory resources available at the network device, or an indication of an amount of input-output resources available at the network device (that the application node may inform the operator network about is capacity in terms of a detection condition related to e.g. DoS-attacks. Assume that the application hosted by the application node is capable of handling 100 000 requests per minute. In order to protect itself from being overwhelmed the application and/or the application node may inform the operator network that an attack shall be considered to have been detected when the number of requests exceeds 90 000 requests per minute. That is to say, the limit is set lower than the maximum number of requests that the application is capable of handling. The number of requests, i.e. 90 000 requests per minute, may be provided as a detection condition of the set of detection conditions that is comprised in the attack information. As a result, the operator network is enabled to manage a potential or ongoing attack towards the application.). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nicoll with Campo to include a capacity in order to mitigate overload style attacks that are targeted to a particular resource, as taught by Campo.
Regarding claim 36, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the network telemetry data of the network device includes packet information for a set of traffic flows handled at the network device (col. 3, lines 25-30: The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal. Col. 4, line 52: Example input devices can include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc).
Regarding claim 37, Nicoll, as modified above, further discloses the apparatus of claim 36, wherein the network telemetry data includes at least one of a set of mirrored packets, Internet Protocol (IP) Flow Information Export (IPFIX) data, Simple Network Management Protocol (SNMP) traps, or gRPC data (col. 6, lines 27-28: assigning Internet Protocol (IP) addresses to respective devices. Col. 9, line 17: lant network 306 may conform to any suitable networking protocol or combination of protocols, including but not limited to Ethernet, Ethernet/IP, DeviceNet, ControlNet, Data Highway and Data Highway Plus (DH/DH+), Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, etc.)).
Regarding claim 38, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein, to generate the device-specific security rule, the instructions, when executed by the at least one processor, cause the apparatus at least to: solve a constraint satisfaction problem that includes a set of inputs, wherein the set of inputs includes at least one of the set of security policies, the network device information, a security goal associated with the security rule, or a configuration limit (col. 13, line 40: restrictions on a given communication path may also be specified by the security rules 602 in accordance with the annotated communication path definitions recorded in the model data 224.).
Regarding claim 39, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein, to generate the device-specific security rule, the instructions, when executed by the at least one processor, cause the apparatus at least to: compile the security rule taking into account at least a portion of the network device information (At 904, model data representing a nodal diagram of the industrial automation system is generated based on the design data read at step 902. The nodal diagram can define industrial and network devices that make up the industrial control system as well as the network connections between the devices. The device and network connectivity information included in the model data can be obtained or inferred by the system based on the design data.).
Regarding claim 40, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the network device configuration information includes a hardware capability of the network device, wherein the device-specific security rule is generated based on the hardware capability of the network device (col. 11, lines 7-11: Model builder component 206 can also determine network connections to the ethernet switch based on hardware diagram information, network device configuration information, or other relevant network design information obtained from the design data 302. Col. 7, line 5: security policy configuration system can discover and retrieve design data from one or more sources, including but not limited to industrial controller program files, controller configuration data (e.g., controller I/O configuration data and communication settings), configuration data for motor drives or other devices that make up the industrial system (e.g., motor drives, HMIs, etc.), network architecture data, hardware diagrams, or other sources of design data. The design data typically includes data generated by device manufacturers, system integrators, original equipment manufacturers (OEMs), or the owners of the industrial assets during the design of the industrial systems.).
Regarding claim 41, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the device-specific security rule is generated in a manner tending to minimize resource consumption at the network device (col. 7, line 5: Security policy configuration system 202 can reduce reliance upon human judgment by automatically identifying expected normal network traffic based on the control system design, prior to installation of the control system, and generate a comprehensive set of security policies that facilitate permitted, expected network traffic while preventing abnormal or unexpected network activity.).
Regarding claim 42, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the device-specific security rule is specified in a format supported by the network device as indicated in the network device configuration information (Col. 13, line 55: Each security policy 702 can comprise one or more device-specific configuration instructions or security parameter setting in a format understandable by the target device. Col. 22, line 39: translate the security rules to device-specific configuration instructions or security parameter settings in a format executable by respective devices).
Regarding claim 44, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the network telemetry data of the network device for a set of traffic flows handled at the network device (col. 3, lines 25-30: The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal. Col. 4, line 52: Example input devices can include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc).
Regarding claim 45, Nicoll, as modified above, further discloses the apparatus of claim 44, wherein the network telemetry data includes at least one of a set of mirrored packets, Internet Protocol (IP) Flow Information Export (IPFIX) data, Simple Network Management Protocol (SNMP) traps, or gRPC data (col. 6, lines 27-28: assigning Internet Protocol (IP) addresses to respective devices. Col. 9, line 17: lant network 306 may conform to any suitable networking protocol or combination of protocols, including but not limited to Ethernet, Ethernet/IP, DeviceNet, ControlNet, Data Highway and Data Highway Plus (DH/DH+), Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, etc.)).
Regarding claim 46, Nicoll, as modified above, further discloses the apparatus of claim 27, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive feedback information associated with application of the device-specific security rule at the network device; generate, based on compiling of the security rule based on the feedback information, a second device-specific security rule for the network device; and send the second device-specific security rule toward the network device (col. 1, lines 60-67: generating, by the system based on the security rules, one or more security policies that, in response to execution by respective one or more of the devices, cause the respective one or more of the devices to enforce the security rules; and sending, by the system, the one or more security policies to the one or more of the devices.).
Regarding claim 47, Nicoll, as modified above, lacks or does not expressly disclose an efficacy of the device-specific security rule at the network device; and generate, in response to a determination that the efficacy of the device-specific security rule at the network device fails to satisfy a threshold, the second device-specific security rule.
However, Campo teaches determine, based on the feedback information, an efficacy of the device-specific security rule at the network device (Action A100: In response to the detection 18 of the attack, the user data node 120 may initiate the mitigation action according to the attack information of the rule. Thus, when the mitigation action eventually is executed, the attack may be mitigated. Sometimes, a combination of mitigation actions may be required in order to efficiently mitigate the attack. An advantage with embodiments herein is that a network operator, such as NSP or the like, may handle attacks more efficiently thanks to increased knowledge - carried by the attack information.); and generate, in response to a determination that the efficacy of the device-specific security rule at the network device fails to satisfy a threshold, the second device-specific security rule (Action 1: Additionally, the SCS/AS might also send the policy (mitigation action) to apply in case the above thresholds are reached (e.g. reset flows exceeding the maximum number of simultaneous flows and notify).).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nicoll with Campo to determine the efficacy of a specific security rule in order determine the appropriate mitigation response, as taught by Campo.
Regarding claim 48, Nicoll, as modified above, further discloses the apparatus of claim 46, wherein, to generate the second device-specific security rule, the instructions, when executed by the at least one processor, cause the apparatus at least to: compile the security rule taking into account at least a portion of the feedback information (col. 1, lines 60-67: generating, by the system based on the security rules, one or more security policies that, in response to execution by respective one or more of the devices, cause the respective one or more of the devices to enforce the security rules; and sending, by the system, the one or more security policies to the one or more of the devices.).
Regarding claim 49, Nicoll, as modified above, further discloses the apparatus of claim 46, wherein the second device-specific security rule is a modified version of the device-specific rule or the second device-specific security rule is a new security rule (col. 1, lines 60-67: generating, by the system based on the security rules, one or more security policies that, in response to execution by respective one or more of the devices, cause the respective one or more of the devices to enforce the security rules; and sending, by the system, the one or more security policies to the one or more of the devices.).
Regarding claim 51, Nicoll, as modified above, further discloses an apparatus, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
send, by a network device, network device information that includes network device configuration information indicative of a configuration of the network device and network telemetry data of the network device (Fig. 3, 302: Design data Design data discovery component 204 is configured to read and retrieve design data 302 from one or more project development platforms 316 used to design, configure, and/or program one or more of the industrial assets 308. Project development platforms 316 can include, but are not limited to, industrial controller configuration and programming applications used to develop ladder logic programs or other types of industrial controller programs, as well as associated industrial controller configuration settings (e.g., controller communication settings, definition of I/O modules associated with the industrial controller and their respective I/O settings, etc.).);
receive, by the network device, a first device-specific security rule configured based on the network device information wherein the first device-specific security rule is based on a programming language (col. 12: line 65: IG. 3, once model data 224 (representing the annotated nodal diagram) has been completed by the model builder component 206, the model data 224 is provided to policy translation component 208, which translates the model data 224 to a set of security rules);
perform, by the network device, an application of the first device-specific security rule at the network device (col. 8, line 33: Policy translation component 208 is also configured to translate these security rules to executable security policy data or instructions that, when implemented on respective industrial and/or networking devices, enforce the security rules generated by the system 202);
receive, by the network device, a second device-specific security rule configured based on the feedback information; and perform, by the network device, an application of the second device-specific security rule at the network device (col. 8, line 46: Device interface component 210 can be configured to exchange data between the security policy configuration system 202 and devices on a plant and/or office network. This can include, for example, sending the executable security policy data or instructions to the devices, polling the devices for confirmation that the security policies have been implemented, polling for device identification and configuration information, etc. Col. 13, line 50: policy translation component 208 uses the set of security rules 602 as the basis for constructing individual device-specific security policies 702 that, when implemented on respective devices of the automation system, enforce the communication permissions defined by the security rules 602).
Regarding claim 52, Nicoll, as modified above further discloses an apparatus, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, a security rule that is based on a programming language and that is based on at least one of a set of security policies, security attack sample information, or Internet information; receive, for a network device, network device information that includes network device configuration information indicative of a configuration of the network device and network telemetry data of the network device; and generate, based on compiling of the security rule based on the programming language and based on at least a portion of the network device information, a device-specific security rule for the network device; and initiate configuration of the network device to use the device-specific security rule for the network device (col 14, line 7:
Example configuration actions that may be implemented on devices of the automation system by the security policies 702 can include modification of network addresses (e.g., IP addresses) or network address ranges on selected devices, enabling of specific security modes on selected devices, setting of valid inbound and outbound connections for respective devices, enabling of key-based or certificate-based security protocols in selected devices, distribution of encryption keys or certificates to devices to facilitate secure communication (e.g., if the devices are configured for key- or certificate-based security), updates of one or more whitelists that explicitly define devices that are permitted to communicate with the target device, modification of network router or switch settings, definition of an authoritative policy source, configuration of a group of devices to participate in a security zone, or other such actions. Policy translation component 208 can generate such security configuration instructions—in the form of security policies 702—for all necessary device-level security parameter changes required to implement the security strategy defined by the security rules 602. Since a given set of heterogeneous industrial assets may support different security technologies, the system 202 can implement the defined security strategy using more than one security enforcement technology for a given set of industrial and networking devices).
Conclusion
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 AUBREY H WYSZYNSKI whose telephone number is (571)272-8155. The examiner can normally be reached M-F 9-5.
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.
/AUBREY H WYSZYNSKI/Primary Examiner, Art Unit 2434