DETAILED ACTION
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 .
The response of 06/23/26 was received and considered. Claims 1-26 and 31-32 are canceled. Claims 27-30 and 33-52 are pending.
Response to Arguments
Applicant’s arguments, filed 06/23/26, with respect to 35 U.S.C. 112 have been fully considered and are persuasive. The previous rejections under 35 U.S.C. 112 have been withdrawn.
Applicant's arguments filed 06/23/26, with respect to 35 U.S.C. 101 have been fully considered but they are not persuasive. In view of the amendments, the rejection has been modified below. To overcome the 101 rejection, amend the independent claims to incorporate specific technical steps. For example, detailing how the rule is uniquely constructed to minimize resource consumption (pulling from the specification, rather than just claim 41), or how the constraint satisfaction problem mechanically alters the physical operation of the network device to prevent a DDoS attack. As, currently amended, the claims represent a classic “data collection…analysis…output” paradigm that does not overcome the current Alice framework.
Applicant’s arguments with respect to claims 27-30 and 33-52 have been considered but are moot in view of the new ground of rejection.
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-30 and 33-52 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As per Independent Claims 27, 50, 52:
Claims 27 (Apparatus), 50 (Method), and 52 (Apparatus) share largely the same core limitations regarding receiving generic security rules and device data, determining/generating a device-specific rule, and sending/initiating configuration.
Step 1 (Statutory Category): Yes. Claim 50 is a process (method). Claims 27 and 52 are machines (apparatuses comprising processors and memory).
Step 2A, Prong 1 (Abstract Idea): The core functionality across these claims is receiving information (policies, Internet info, telemetry), analyzing that information, and generating a new set of instructions (a device-specific security rule). Under Federal Circuit precedent (e.g., Electric Power Group), the collection, analysis, and output of data is generally considered an abstract idea (a mental process or method of organizing human activity). Translating a generic rule into a specific rule based on hardware parameters is a logical process that could theoretically be performed in the human mind.
Step 2A, Prong 2 (Practical Application): Applicant argues that generating a "device-specific security rule optimized for the network device" improves computer/network functionality. However, as currently drafted, these claims are vulnerable. They claim the result (an optimized, device-specific rule) without claiming the specific technical means or method by which optimization is achieved. Merely claiming a rule "based on a programming language" is too generic to satisfy the integration requirement.
Step 2B (Significantly More): The physical components recited ("at least one processor," "at least one memory," "network device," "communication network") are invoked at a high level of generality to perform their standard, routine functions (storing, receiving, analyzing, sending).
Conclusion: Claims 27, 50, and 52 are ineligible.
As per Independent Claim 51:
Claim 51 is written from the perspective of the network device: it sends its configuration/telemetry, receives the device-specific rule, applies it, and sends feedback.
Step 1: Yes (Apparatus).
Step 2A (Abstract Idea): Similar to the above, communicating data and receiving rules are abstract concepts of data transmission and execution.
Step 2B (Significantly More/Practical Application): The strongest limitation here is "perform... an application of the first device-specific security rule." If applying this rule fundamentally changes how the network device processes packets to defend against attacks, it might be argued that this is a specific improvement to network security (similar to SRI International, Inc. v. Cisco Systems, Inc.). However, "perform an application" is broad. Therefore, this simply amounts to a generic computer executing generic instructions, which does not supply an inventive concept.
Conclusion: Claim 27 is ineligible.
Analysis of Dependent Claims:
Group 1: Data Gathering Limitations:
Merely limiting an abstract idea to a particular technological environment or specifying the type of data being gathered does not confer patentability under § 101.
As per Claims 28, 29, 30, 43: Specify that the attack data is related to DDoS or botnet attacks. Conclusion: Fails § 101. Limiting the field of use to specific types of cyberattacks does not make the data analysis non-abstract.
As per Claim 33: Specifies network configuration data types (vendor, capability, capacity, format). Conclusion: Fails § 101. Mere data gathering.
As per Claims 34, 35: Specify hardware/OS/programming capabilities and CPU/memory/IO capacities. Conclusion: Fails § 101. Adds specificity to the data, but the claim still just analyzes this data generically.
As per Claims 36, 37, 44, 45: Specify network telemetry data types (packet info, mirrored packets, IPFIX, SNMP, gRPC). Conclusion: Fails § 101. Standard network data formats collected using conventional networking techniques.
Group 2: Mathematical Concepts:
As per Claim 38: Requires solving a "constraint satisfaction problem" based on a set of inputs.
Conclusion: Introduces a secondary judicial exception (a mathematical algorithm). Under Step 2A, Prong 1, this further highlights the abstract nature of the claim. Applying a mathematical formula to network data without a specific physical implementation fails Step 2B.
Group 3:
To survive § 101, claims generally need to show a specific technical solution to a technical problem (e.g., Enfish).
As per Claim 39: Recites "compile the security rule taking into account at least a portion of the network device information." Conclusion: Compiling code is a highly conventional computer function.
As per Claim 40: The rule is generated based on the "hardware capability of the network device." Conclusion: Ineligible. It lacks the "how."
As per Claim 41: The rule is generated "in a manner tending to minimize resource consumption at the network device."
Evaluation: This is the strongest limitation for arguing a practical application (improving computer functionality). However, claims must focus on a specific means or method that improves the technology, not just claim the desired result. Because Claim 41 claims the result (minimized resource consumption) without detailing the specific algorithmic steps to achieve it, the claim is an abstract idea.
As per Claim 42: Rule conforms with a supported configuration. Conclusion: Formatting data to be compatible with a receiving device is a conventional, abstract practice.
Group 4: Feedback Loops
As per Claims 46, 47, 48, 49: Detail a feedback loop where the apparatus receives feedback on the rule's efficacy, recompiles/generates a second rule if a threshold is failed, and sends it.
Evaluation: Iterative feedback loops (evaluating performance and adjusting) are fundamental, abstract concepts (e.g., standard mental processes or human organization). Because the evaluation ("determine... an efficacy," "fails to satisfy a threshold") and the response ("generate... a second device-specific security rule") are claimed functionally rather than detailing a specific technical mechanism, these claims do not add an inventive concept under Step 2B.
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 27-30 and 33-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.
Claims 27, 50, 51, and 52 rely on the limitation that the generated rule is "optimized" for the network device. The term "optimized" renders the claims indefinite because the claim includes elements not actually disclosed (those encompassed by "optimizing"), thereby rendering the scope of the claims unascertainable. “Optimized” is a term of degree. What constitutes an “optimized” rule? Is it optimized for processing speed, minimum memory usage, or maximum threat blockage? See MPEP § 2173.05(d) and 2173.05(b).
Claim 51 states: “an operating parameter indicative of strain on the network device handling the traffic”. “Strain” does not hold concrete boundaries (e.g. exceeding a specific threshold, memory buffer overflows) and is considered indefinite.
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-30 and 33-52 are rejected under 35 U.S.C. 103 as being unpatentable over Nicoll et al., US 11,212,322, in view of Smith et al., US 10,812,504 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
the set of security policies being generic security rules and specifying at least one of a security goal to be achieved, a parameter which may be used for detection of a security attack, or an action which may be initiated for mitigation of the security attack detected (Nicoll teaches that the input policies are “high level policies” or “generic” business goals (e.g. “block authenticated traffic”) rather than technical rules. Nicoll as modified above, does not expressly disclose the security attack sample information describing security attacks which have occurred. However, Smith teaches the security attack sample information describing security attacks which have actually occurred, the Internet information including information of at least one of Internet topology, Internet devices, or Internet services security attack sample information, and Internet information (Smith teaches utilizing a “cloud based data feed that tracks the security context of the internet” including BGP Internet topology and a database of actual historical DDOS attack signatures/samples). 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, as modified above, to include security attack sample information in order to initiate mitigation of the attack, as taught by Smith.
Nicoll as modified above further discloses
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.);
determine, based on an analysis of the set of security policies, the security attack sample information, the Internet information, and the network device information, a device-specific security rule that is specific to the network device, wherein the device-specific security rule is a security rule optimized for the network device based on the analysis (Nicol teaches executing an automated workflow to analyze the generic policy against the target device context to determine the precise technical rule needed. The translation engine selects the syntax and parameter thresholds that are optimized for the specific hardware’s capabilities);
generate, based on the determination, the, 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). Nicoll as modified above, does not expressly disclose the security attack sample information describing security attacks which have occurred. However, Smith teaches the security attack sample information describing security attacks which have actually occurred, the Internet information including information of at least one of Internet topology, Internet devices, or Internet services security attack sample information, and Internet information (Smith teaches utilizing a “cloud based data feed that tracks the security context of the internet” including BGP Internet topology and a database of actual historical DDOS attack signatures/samples). 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, as modified above, to include security attack sample information in order to initiate mitigation of the attack, as taught by Smith.
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). Nicoll as modified above, does not expressly disclose the security attack sample information describing security attacks which have occurred. However, Smith teaches the security attack sample information describing security attacks which have actually occurred, the Internet information including information of at least one of Internet topology, Internet devices, or Internet services security attack sample information, and Internet information (Smith teaches utilizing a “cloud based data feed that tracks the security context of the internet” including BGP Internet topology and a database of actual historical DDOS attack signatures/samples). 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, as modified above, to include security attack sample information in order to initiate mitigation of the attack, as taught by Smith.
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.
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
Prosecution Insights