DETAILED ACTION
Claims 1-20 are presented for examination.
This office action is in response to the request for continued examination submitted on 17-SEP-2025.
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 .
Examiner Note
A new Examiner has been assigned to act on the application. Examiner has reviewed and given credit to the previous Examiner's actions consistent with MPEP § 704.01.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/17/2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to 35 U.S.C. 101 have been fully considered and are persuasive. The rejection of 35 U.S.C. 101 has been withdrawn.
Applicant’s arguments with respect to the rejection(s) under 35 U.S.C 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of
under 35 U.S.C. 102(a)(1) as being anticipated by Reaves et al., “An open virtual testbed for industrial control system security research” (hereinafter ‘Reaves’) [2012].
under 35 U.S.C. 103 as being unpatentable over Reaves in view of
Čeleda et al., “KYPO4INDUSTRY: A Testbed for Teaching Cybersecurity of Industrial Control Systems” (hereinafter ‘Čeleda’) [2020].
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 5-9, 11-16, and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by
Reaves et al., “An open virtual testbed for industrial control system security research” (hereinafter ‘Reaves’) [2012].
Regarding Claim 1: A system for testing industrial processes and industrial control systems comprising:
Reaves teaches a physical environment comprising: at least one industrial control system hardware; and at least one physical model; and (Pg. 218 left col 4th paragraph left col Reaves “…Mississippi State University’s laboratory-scale process control system cybersecurity testbed [10] uses process control system equipment to control and monitor small, laboratory-scale processes. MSU has two types of testbed: five laboratory-scale industrial control system and a laboratory-scale electrical substation (in which power flows are simulated). The industrial control systems include an oil pipeline system, an oil storage tank, water tower, industrial air blower, manufacturing conveyor, and rolled sheet metal plant…”)
Reaves teaches a computer system comprising a processor and a memory, wherein the processor is set up to perform operations, embodied in instructions on computer-readable medium, the operations comprising: (Pg. 219 right col 1st paragraph Reaves “…Virtual devices include control logic implemented in Python to mimic internal master or remote terminal logic functions (such as ladder logic). Additionally, virtual devices implement points which model internal memory of the remote or master terminal unit. The virtual devices and process simulator communicate via a separate simulator communication channel. Figure 1 also includes a set of wireless radios and a human–machine interface (HMI) computer…”)
Reaves teaches virtually link the physical environment and a virtual environment; (Pg. 222 left col 2nd paragraph Reaves “…Because virtual devices are implemented within virtual machines and use standard communication interfaces and validated network software stacks, actual industrial control system devices may be connected to a virtual testbed. This feature allows virtual testbed users to test new devices with a virtual testbed and capture data logs, which include interaction with new actual devices…”)
Reaves teaches input at least one document comprising supporting software and (Pg. 218 1st paragraph Reaves “…A network simulator, RINSE, was used to model communications between simulated devices; these simulated devices include relays and data aggregators. PowerWorld software was used to simulate the Power Grid…”)
Reaves teaches a scenario instruction set; (Pg. 221 3rd paragraph Reaves “…Figure 3 shows example control logic for an on/off controller to safely turn on a water storage tank pump. The code checks the status of the control system mode (manual or automatic), reads the value of high-level and low-level water sensors, and the current intended pump state before turning the pump on…”)
PNG
media_image1.png
238
376
media_image1.png
Greyscale
Reaves teaches generate a scenario according to the scenario instruction set, by: (Pg. 221 right col 2nd paragraph Reaves “…VDEV Control Logic: The control logic directly emulates the control and monitoring functions of an actual control device. Control logic is specified as a single Python function separate from the VDEV implementation. The control logic is called by a logic control thread; this thread also synchronizes process simulator communication. The same control logic function may be used for multiple slave devices to allow code reuse. Process control logic in actual industrial control systems consists of reading inputs, performing logical and numeric calculations, and then setting appropriate outputs. This behavior is modeled by the VDEV control logic. Reads and writes to points in device memory are handled with get() and set() functions. Control logic may consist of combinatorial logic, loops, conditional programming, and arithmetic…”)
Reaves teaches modifying one or more connections between one or more physical models of the physical environment and one or more simulated models of the virtual environment to be used for the scenario; (Pg. 227 left col 3rd paragraph Reaves “…The virtual masters were used to control actual slave devices in the laboratory, and the virtual slaves were connected to actual masters from the laboratory. The virtual masters were able to monitor and control the laboratory slave devices connected to the actual physical process. Also, the real masters were able to monitor and control the virtual slave devices connected to the virtual physical process. All system operation modes were tested and were functional, and there were no error communications errors present in the system…” Pg. 227 left col last paragraph “…The first attack assumes that an insider or other attacker with physical access has placed a device on the serial line between the master and slave device in the ground tank system; this device can monitor communications and inject commands and responses…”)
Reaves teaches simulate the scenario by modifying inputs and outputs of the one or more physical models and the one or more simulated models based on the one or more connections; and (Pg. 220 left col last paragraph Reaves “…Simulation is discrete time based. The simulator interface accepts and provides updates to and from the simulator about relevant inputs and outputs of the device. Inputs and outputs are defined in a configuration file by name. Name–value pairs are transmitted to and from the process simulator. This simulates the connection of analog and digital input and outputs between the remote terminal unit (simulated by a VDEV) and process measurement devices and process actuators…”)
Reaves teaches display simulation results of the simulating of the scenario. (Pg. 227 left col 2nd paragraph Reaves “…In spite of the low similarities in timing (which may be correctible in futurework), the results show that all non-timing-based behaviors of the virtual system were similar to the laboratory system…”)
Regarding Claim 2: Reaves teaches The system of claim 1,
Reaves teaches wherein the at least one physical model and the at least one industrial control system hardware are interconnected. (Pg. 218 right col 4th paragraph Reaves “…Captures of the network traffic, to be effective for research purposes, must be logged reliably; logging should be done with a minimum effect on the industrial control system traffic itself and with sufficient precision and accuracy to fully describe the behavior of the system. In addition to exhibiting realistic traffic, the testbed should also be able to interface with actual industrial control system equipment. This helps to ensure that the testbed has behavior compatible with real industrial control systems and facilitates the use of the system as a “backend” for research on equipment vulnerabilities. This requirement dictates that the virtual testbed must be capable of soft real-time operation…”)
Regarding Claim 5: Reaves teaches The system of claim 1,
Reaves teaches wherein at least one document includes instructions for reconfiguring components of the system and updating components of the system. (Pg. 218 left col 1st paragraph Reaves “…In [9], the authors take the approach of using a small “complex electromechanical device consisting of pipes, valves, sensors, pumps, etc” to model a power plant. Their system uses a number of different PLCs and field devices. They also use a DeltaV DCS system. They also included a small office intranet with interconnections with VLAN, VPNs, RADIUS, a DMZ, and “external network” system. The authors have used this system to demonstrate four different attack scenarios…” Pg. 220 left col 3rd paragraph “…Configuration files are used to set initial conditions for the physical process…”)
Regarding Claim 6: Reaves teaches The system of claim 1,
Reaves teaches wherein additional supporting software is included in the memory of the computer system. (Pg. 219 left col 1st paragraph Reaves “…Examples include the ability to include PMU and PDC instances from the OpenPDC project or to integrate other software virtual testbeds…” pg. 222 left col 3rd paragraph “…For example, a virtual testbed may interface with actual human machine interface (HMI) software. HMI software available in the MSU SCADA Security Laboratory communicates with the control system via MODBUS/RTU. The HMI can run in one virtual machine and communicate with a VDEV, which simulated a remote terminal unit…”)
Regarding Claim 7: A method for simulating industrial processes and industrial control systems on a testbed comprising:
Reaves teaches integrating, by a processor, a physical environment with a virtual environment; (Pg. 218 left col 4th paragraph left col Reaves “…Mississippi State University’s laboratory-scale process control system cybersecurity testbed [10] uses process control system equipment to control and monitor small, laboratory-scale processes. MSU has two types of testbed: five laboratory-scale industrial control system and a laboratory-scale electrical substation (in which power flows are simulated). The industrial control systems include an oil pipeline system, an oil storage tank, water tower, industrial air blower, manufacturing conveyor, and rolled sheet metal plant…”)
Reaves teaches inputting, by the processor, at least one document comprising supporting software; (Pg. 218 1st paragraph Reaves “…A network simulator, RINSE, was used to model communications between simulated devices; these simulated devices include relays and data aggregators. PowerWorld software was used to simulate the Power Grid…”)
Reaves teaches generating, by the processor, a scenario environment including the physical environment and the virtual environment linked as described in the at least one document by (Pg. 221 right col 2nd paragraph Reaves “…VDEV Control Logic: The control logic directly emulates the control and monitoring functions of an actual control device. Control logic is specified as a single Python function separate from the VDEV implementation. The control logic is called by a logic control thread; this thread also synchronizes process simulator communication. The same control logic function may be used for multiple slave devices to allow code reuse. Process control logic in actual industrial control systems consists of reading inputs, performing logical and numeric calculations, and then setting appropriate outputs. This behavior is modeled by the VDEV control logic. Reads and writes to points in device memory are handled with get() and set() functions. Control logic may consist of combinatorial logic, loops, conditional programming, and arithmetic…”)
Reaves teaches modifying one or more connections between one or more physical models of the physical environment and one or more simulated models of the virtual environment to be used for the scenario environment: (Pg. 227 left col 3rd paragraph Reaves “…The virtual masters were used to control actual slave devices in the laboratory, and the virtual slaves were connected to actual masters from the laboratory. The virtual masters were able to monitor and control the laboratory slave devices connected to the actual physical process. Also, the real masters were able to monitor and control the virtual slave devices connected to the virtual physical process. All system operation modes were tested and were functional, and there were no error communications errors present in the system…” Pg. 227 left col last paragraph “…The first attack assumes that an insider or other attacker with physical access has placed a device on the serial line between the master and slave device in the ground tank system; this device can monitor communications and inject commands and responses…”)
Reaves teaches generating, by the processor, a scenario within the scenario environment as described in the at least one document; and (Pg. 220 left col 4th paragraph Reaves “…Process simulations are described in Python classes. At start-up, the simulator module reads the configuration file to configure process variables, such as flowrates, motor speeds, etc., and sets the initial simulation state…”)
Reaves teaches simulating, by the processor, the scenario by modifying inputs and outputs of the one or more physical models and the one or more simulated models based on the one or more connections. (Pg. 220 left col last paragraph Reaves “…Simulation is discrete time based. The simulator interface accepts and provides updates to and from the simulator about relevant inputs and outputs of the device. Inputs and outputs are defined in a configuration file by name. Name–value pairs are transmitted to and from the process simulator. This simulates the connection of analog and digital input and outputs between the remote terminal unit (simulated by a VDEV) and process measurement devices and process actuators…”)
Regarding Claim 8: Reaves teaches The method of claim 7, further comprising:
Reaves teaches reconfiguring, by the processor, the at least one document, to include a new scenario. (Pg. 218 left col 1st paragraph Reaves “…In [9], the authors take the approach of using a small “complex electromechanical device consisting of pipes, valves, sensors, pumps, etc” to model a power plant. Their system uses a number of different PLCs and field devices. They also use a DeltaV DCS system. They also included a small office intranet with interconnections with VLAN, VPNs, RADIUS, a DMZ, and “external network” system. The authors have used this system to demonstrate four different attack scenarios…” Pg. 220 left col 3rd paragraph “…Configuration files are used to set initial conditions for the physical process…”)
Regarding Claim 9: Reaves teaches The method of claim 7, further comprising:
Reaves teaches returning, by the processor, results of simulating the scenario. (Pg. 227 left col 2nd paragraph Reaves “…In spite of the low similarities in timing (which may be correctible in futurework), the results show that all non-timing-based behaviors of the virtual system were similar to the laboratory system…”)
Regarding Claim 11: Reaves teaches The method of claim 7, further comprising:
Reaves teaches reconfiguring, by the processor, the virtual environment and the physical environment, as described in the at least one document. (Pg. 223 left col 3rd paragraph Reaves “…Figure 4 shows the water storage tank and gas pipeline systems from the MSU SCADA Security Laboratory. Both systems implement a distributed control scheme. A Control Microsystems, Inc. SCADAPack LP PLC is connected to each physical process and acts as the remote terminal unit (RTU). The PLC includes ladder logic that monitors process measurements and executes control logic. The control logic is described in the form of ladder logic. A single MTU communicates with both RTU. The MTU includes supervisory control logic and acts as a repeater forwarding queries from a system HMI to the addressed RTU. The HMI periodically polls each RTU for process measurements. The HMI can also execute supervisory control over the physical processes by changing RTU setpoints…” Pg. 220 left col 3rd paragraph “…Configuration files are used to set initial conditions for the physical process…”)
Regarding Claim 12: Reaves teaches The method of claim 7, further comprising:
Reaves teaches updating, by the processor, the virtual environment and the physical environment, as described in the at least one document. (Pg. 216 left col 4th paragraph Reaves “…An open platform enables researchers to update existing virtual testbeds or add new testbeds modeling new control systems…”)
Regarding Claim 13: Reaves teaches The method of claim 7, further comprising:
Reaves teaches recording, by the processor, onto a memory, results of simulating the scenario. (Pg. 225 right col 4th paragraph Reaves “…Figure 5 provides a comparison of simulated ground tank water levels versus actual ground tank water levels measured in the laboratory…”)
Claims 14-16 and 18-20 are medium claims, containing substantially the same elements as method Claims 7-9 and 11-13, respectively, and are rejected on the same grounds under 35 U.S.C. 103 as Claims 7-9 and 11-13, respectively, Mutatis mutandis.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 3-4, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over
Reaves et al., “An open virtual testbed for industrial control system security research” (hereinafter ‘Reaves’) [2012] in view of
Čeleda et al., “KYPO4INDUSTRY: A Testbed for Teaching Cybersecurity of Industrial Control Systems” (hereinafter ‘Čeleda’) [2020].
Regarding Claim 3: Reaves teaches The system of claim 1, further comprising
Reaves teaches a communication device, comprising a transmitter and a receiver, (Pg. 220 left col 3rd paragraph Reaves “…The simulator module performs process simulation and stores the current state of the physical process. The communication interface receives periodic process control changes and requests for process measurement updates from virtual devices (VDEV). Requests from the VDEVs are queued by the communication interface and applied in the order received by the update queue…”)
Reaves does not appear to explicitly disclose
wherein the communication device is configured to access a cloud-based computing system.
PNG
media_image2.png
250
296
media_image2.png
Greyscale
However, Čeleda teaches wherein the communication device is configured to access a cloud-based computing system. (Pg. 1028 left col Čeleda “…As Figure 2 shows, the devices within the testbed infrastructure are interconnected and so can communicate with each other…” where Figure 2 shows cloud infrasture)
Reaves and Čeleda are analogous art because they are from the same field of endeavor, cybersecurity of industrial control systems.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the a communication device, comprising a transmitter and a receiver as disclosed by Reaves by wherein the communication device is configured to access a cloud-based computing system as disclosed by Čeleda.
One of ordinary skill in the art would have been motivated to make this modification in order to test the different environments encountered in cybersecurity of connects industrial control systems as discussed on pg. 1026 right col 1st paragraph by Čeleda “…Industrial control systems (ICS) provide vital services, such as electricity, water treatment, and transportation. Although these systems were formerly isolated, they became connected with information technology (IT) systems and even to the Internet. Figure 1 shows the ISA-95 enterprise reference architecture that describes the connection between the functions of ICS and IT systems [29]. This connection of processes in the cyberspace and the physical world has reduced costs and enabled new services. However, the ICS assets became vulnerable to new threats and ever-evolving cyber threat landscape [41] …”
Regarding Claim 4: Reaves and Čeleda teaches The system of claim 3,
Čeleda teaches wherein the operations of the computer system are performed by the cloud-based computing system. (Pg. 1029 right col 3rd-4th paragraph Čeleda “…The software stack of ICS testbed includes Linux OS (Debian optimized for PLC devices), Docker ecosystem [18], and on-premise OpenStack [14] cloud environment. We combine cloud deployment (virtual machines in OpenStack) with physical devices (PLCs, sensors, and actuators) to create ICS systems with varying levels of fidelity. Automated orchestration of the testbed environment is of utmost importance. The central testbed controller runs as a virtual appliance. It provides management and monitoring of ICS testbed and contains Docker repository for PLC devices. The PLC devices are pre-installed with Debian OS and enabled Docker support. Using Docker containers simplifies software deployment and configuration of testbed components…”)
Regarding Claim 10: Reaves teaches The method of claim 7,
Reaves does not appear to explicitly disclose
wherein the processor is part of a cloud-based computing system.
However, Čeleda teaches wherein the processor is part of a cloud-based computing system. (Pg. 1029 right col 3rd-4th paragraph Čeleda “…The software stack of ICS testbed includes Linux OS (Debian optimized for PLC devices), Docker ecosystem [18], and on-premise OpenStack [14] cloud environment. We combine cloud deployment (virtual machines in OpenStack) with physical devices (PLCs, sensors, and actuators) to create ICS systems with varying levels of fidelity. Automated orchestration of the testbed environment is of utmost importance. The central testbed controller runs as a virtual appliance. It provides management and monitoring of ICS testbed and contains Docker repository for PLC devices. The PLC devices are pre-installed with Debian OS and enabled Docker support. Using Docker containers simplifies software deployment and configuration of testbed components…”)
Reaves and Čeleda are analogous art because they are from the same field of endeavor, cybersecurity of industrial control systems.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the processor as disclosed by Reaves by wherein the processor is part of a cloud-based computing system as disclosed by Čeleda.
One of ordinary skill in the art would have been motivated to make this modification in order to test the different environments encountered in cybersecurity of connects industrial control systems as discussed on pg. 1026 right col 1st paragraph by Čeleda “…Industrial control systems (ICS) provide vital services, such as electricity, water treatment, and transportation. Although these systems were formerly isolated, they became connected with information technology (IT) systems and even to the Internet. Figure 1 shows the ISA-95 enterprise reference architecture that describes the connection between the functions of ICS and IT systems [29]. This connection of processes in the cyberspace and the physical world has reduced costs and enabled new services. However, the ICS assets became vulnerable to new threats and ever-evolving cyber threat landscape [41] …”
Claims 17 is medium claims, containing substantially the same elements as method Claim 10, respectively, and are rejected on the same grounds under 35 U.S.C. 103 as Claims 10, respectively, Mutatis mutandis.
Conclusion
Claims 1-20 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN E JOHANSEN whose telephone number is (571)272-8062. The examiner can normally be reached M-F 9AM-3PM.
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, Emerson Puente can be reached at 5712723652. 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.
/JOHN E JOHANSEN/Examiner, Art Unit 2187