DETAILED ACTION
This communication is in response to the Applicant’s Amendment and Remarks filed on March 5, 2026 in which claims 1-25 are pending in the application. Claims 1, 12, and 24 are in independent form.
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 .
CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit of U.S. Provisional Patent Application No. 63/571,788, filed March 29,2024, the entire disclosure of which is incorporated herein by reference.
Response to Amendment
This Final Office Action is in response to the applicant’s remarks and arguments filed on
March 05, 2026.
Claims 1, 12 and 24 are amended.
No claims were added or canceled.
Claims 1-25 remain pending in the application. Claims 1-25 are being considered on the merits.
Response to Arguments
The applicant’s remarks and/or arguments, filed on March 05, 2026 have been fully considered with the following result(s).
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 162 USPQ 541,550-51 (CCPA 1969).
Applicant's arguments in the applicant’s remarks and amendments of independent claims 1, 12 and 24 filed on March 5, 2026, have been fully considered and are partially persuasive. Therefore, the previous claim(s) rejection under 35 U.S.C 103 has been modified.
However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art: Chen et al. (US 7251743 B2) and in view of the previously cited prior art(s). Reference Chen discloses queuing the external event on an external event queue for execution by the primary controller [Col. 6, lines 62–67, “primary controller 6 … maintains in memory … a redrive I/O queue 28 to queue I/O requests to retry … and one path I/O queue 30 for each path 19 …”]. I/O requests are queued in specific queues for execution or retry;
Chen also discloses queuing the external event for synchronized execution by the secondary controller [Col. 8, lines 23–31, “the write request is queued … in the I/O path queue … to transmit the write request to the secondary controller 16”]. Requests are queued and transmitted to the secondary for execution.
For further details, please see below claims rejections under 35 USC 103.
As such, the combination of references discloses the claimed invention.
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.
Claim(s) 1-7, 10-18 and 21-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aubin et al. (US PGPub 20230125853 A1) and Chen et al. (US 7251743 B2) and Model Based Event Triggered Control over lossy Networks, Garcia et al., July 2020.
As per claim 1, Aubin discloses a method of achieving application state synchronicity comprising:
receiving an event by a primary controller, the primary controller configured to actively monitor and control at least one process of a plant responsive to the received event [Para [0005], a method for providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU; Para [0018], “The RTU 110 is used as a control device… collects measurements from various wireless and wired field sensors… RTU 110 can determine the tension or load… Other data collected by RTU 110 from the field sensors may include fluid flow rate, temperature, pressure, and the like.”; Para [0021], “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110.”];
determining if the event and input data associated therewith received by the primary controller comprise an external event [Para [0005], providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU as the time-stamped events are generated on the main RTU CPU, receiving the time-stamped events on the standby RTU CPU, and storing the time-stamped events in one or more standby RTU CPU event buffers; Para [0023], “Events are captured in the event store 304 based on an RTU configuration associated with physical I/O, downstream data sources, and internal data items (including data items coming from Unity run-time 306).”];
queuing the external event on an external event queue for execution by the primary controller [Para [0023], [0031], [0035], “Events are captured in the event store 304… buffered time-stamped event transfer from a main RTU CPU to a standby RTU CPU”; ];
transferring the external event to a secondary controller in a duplex configuration with the primary controller, the secondary controller configured to, responsive to a failure of the primary controller, actively monitor and control the at least one process of the plant; [Para [0024], “Critical infrastructure benefits from the use of dual RTU CPUs 202A, 202B to increase system availability. Synchronizing the dual RTU CPUs 202A, 202B…”; Para [0035], “buffered time-stamped event transfer from a main RTU CPU to a standby RTU CPU”; Para [0065], In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).];
queuing the external event for synchronized execution by the secondary controller [Para [0031], “The standby RTU CPU 202B receives the events and inserts them into event buffers (in the same way as the main RTU CPU 202A).”; Para [0065], In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).]; and
in response to the external event and the associated input data received by the primary and secondary controllers, synchronizing execution of the event by the primary and secondary controllers by queuing the external event on an internal event queue associated therewith to achieve application state synchronicity between the primary controller and the secondary controller [Para [0031], “The standby RTU CPU 202B receives the events and inserts them into event buffers (in the same way as the main RTU CPU 202A).”; Para [0065], In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).]; Para 0033, “Logic state data images are synchronized between the main RTU CPU 202A and the standby RTU CPU 202B starting with a snapshot of the logic state image on the main RTU CPU 202A at the end of the IEC 61131-3 logic scan. The logic state data image is compressed and transferred to the standby RTU CPU 202B. The standby CPU 202B receives, decompresses, and deploys the logic data image, synchronized with other data and event updates from the main RTU CPU 202A.”].
Aubin discloses the invention as detailed above for claim 1. Although Aubin discloses an event, the reference does not specifically teach queuing the external event on an external event queue for execution by the primary controller as recited in the claim.
Chen discloses queuing the external event on an external event queue for execution by the primary controller [Col. 6, lines 62–67, “primary controller 6 … maintains in memory … a redrive I/O queue 28 to queue I/O requests to retry … and one path I/O queue 30 for each path 19 …”]. I/O requests are queued in specific queues for execution or retry;
Chen also discloses queuing the external event for synchronized execution by the secondary controller [Col. 8, lines 23–31, “the write request is queued … in the I/O path queue … to transmit the write request to the secondary controller 16”]. Requests are queued and transmitted to the secondary for execution.
Both Aubin and Chen are in the same field of endeavor as they are both in the synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin with the teachings of Chen to determine that received events comprise asynchronous external events as taught by Chen, before placing such events into the synchronized external event queues.
Motivation for the modification would have been to ensure deterministic execution of externally generated asynchronous events across redundant controllers, thereby improving synchronization accuracy and ensuring correct failover behavior.
Accordingly, it would have been obvious to combine teachings of the references because each is directed to maintaining synchronized execution among redundant processing systems in the presence of externally generated asynchronous events, and the combination merely applies the known technique of identifying and synchronizing asynchronous external events to the redundant controller architecture of Aubin to obtain predictable results.
Garcia discloses a system comprising an event-based controller is implemented at the sensor node of the networked and uncertain system and it transmits feedback measurements to the controller node at asynchronous time instants (see abstract).
Aubin, Chen and Garcia are in the same field of endeavor as they are in the synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin and Chen with the teachings of Garcia in order to reduce the number of instances where the sensor node needs to transmit feedback updates to the controller nodes as taught by Garcia.
Modification would provide an approach crucial in modern computing and control systems for handling unpredictable inputs, such as network traffic, user interactions, or sensor data, and a system that efficiently responds to external signals without halting its primary operations.
As per claim 2, Aubin discloses the method of claim 1, wherein the input data associated with the external event includes one or more of input/output (10) value changes, operator setpoint updates from a Human-Machine Interface, data changes from a subscribed peer controller, and events generated by internal Timer Objects [Para 0023, “Events are captured in the event store 304 based on an RTU configuration associated with physical I/O, downstream data sources, and internal data items (including data items coming from Unity run-time 306).”].
As per claim 3, Aubin discloses the method of claim 1, wherein synchronizing execution of the external event includes triggering execution of one or more function blocks within a control resource of the primary controller and a corresponding control resource of the secondary controller in response to the external event [Para 0033, “Logic state data images are synchronized between the main RTU CPU 202A and the standby RTU CPU 202B starting with a snapshot of the logic state image on the main RTU CPU 202A at the end of the IEC 61131-3 logic scan.”].
As per claim 4, Aubin discloses the method of claim 1, wherein synchronizing execution of the external event comprises maintaining identical control application states at the end of execution [Para 0033, “The standby CPU 202B receives, decompresses, and deploys the logic data image, synchronized with other data and event updates from the main RTU CPU 202A. The logic of standby RTU CPU 202B is ready to activate with the updated data image, within the timing of one scan on the logic of main RTU CPU 202A.”].
As per claim 5, Aubin discloses the method of claim 1, further comprising designating one controller in the duplex configuration as a preferred primary [Para 0028, “CPU A indicates RTU 110A in the main state and CPU B indicates RTU 110B in the standby state. Alternatively, CPU A could be in the standby state and CPU B could in the main state…”].
As per claim 6, Aubin discloses the method of claim 1, further comprising actively scanning, by the primary controller, one or more 10 devices and synchronizing data from the 10 devices to the secondary controller [Para 0112, Table I, “MAIN Start I/O Scanning, Execute logic, enable Logic outputs controlled from database, allow events to be generated and stored, if partner CPU is in RESYNC or STANDBY queue update changes”].
As per claim 7, Aubin discloses the method of claim 6, further comprising actively scanning, by the secondary controller, the one or more 10 devices after taking over a primary role from the primary controller [Para 112, “The new partner CPU, i.e., standby CPU 202B, is deemed ‘Synchronized’ and enters a standby state when the logic application and logic data image is received and readied on the standby RTU 110B and the RED queue on the standby CPU 202B is empty. … Take control from other CPU (standby to main transition when manual change-over is triggered) … MAIN Start I/O Scanning, Execute logic, enable Logic outputs controlled from database, allow events to be generated and stored…”].
As per claim 10, Aubin discloses the method of claim 1, wherein queuing the external event for synchronized execution by the secondary controller comprises executing a runtime software component configured to run on one or more of a programmable logic controller (PLC), a controller of a distributed control system (DCS), and an industrial personal computer (IPC) [Para 0021, “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110. … The RTU 110 is configured to be interfaced to multiple control stations and intelligent electronic devices using different communication media such as RS485, RS232, Ethernet, microwave, satellite, etc.”].
As per claim 11, Aubin discloses the method of claim 1, wherein the input data includes one or more of: data from a sensor associated with the at least one process of the plant, data received from an operator interface, and data received from a peer controller [Para 0016, “The substation 104 includes a number of peripherals 106, including sensors, actuators, drives, and the like.”].
As per claim 12, Aubin discloses a system for achieving application state synchronicity comprising: a control resource associated with a primary controller, the primary controller configured to actively monitor and control at least one process of a plant [Para [0001], [0005], a method for providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU; Para [0016], [0018], “The RTU 110 is used as a control device… collects measurements from various wireless and wired field sensors… RTU 110 can determine the tension or load… Other data collected by RTU 110 from the field sensors may include fluid flow rate, temperature, pressure, and the like.”; Para [0021], “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110.”];
a corresponding control resource associated with a secondary controller in a duplex configuration with the primary controller, the secondary controller configured to, responsive to a failure of the primary controller, actively monitor and control the at least one process of the plant [Para [0003], “Redundant controllers consist of two identical individual controllers.”; Para [0024], “Critical infrastructure benefits from the use of dual RTU CPUs 202A, 202B to increase system availability. Synchronizing the dual RTU CPUs 202A, 202B…”]; and
one or more storage memories coupled to the control resources, the one or more storage memories storing processor-executable instructions that, when executed, configure the control resources for [Para [0016], “a data memory is implemented each of the subsystems …”; Para 0021, “RTU 110 includes a memory 204 (e.g., volatile and non-volatile)…”]:
receiving an event by the primary controller [Para [0005], a method for providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU; Para [0018], “The RTU 110 is used as a control device… collects measurements from various wireless and wired field sensors… RTU 110 can determine the tension or load… Other data collected by RTU 110 from the field sensors may include fluid flow rate, temperature, pressure, and the like.”];
responsive to the event and input data associated therewith received by the primary controller comprising an external event [Para [0005], providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU as the time-stamped events are generated on the main RTU CPU, receiving the time-stamped events on the standby RTU CPU, and storing the time-stamped events in one or more standby RTU CPU event buffers; Para [0023], “Events are captured in the event store 304 based on an RTU configuration associated with physical I/O, downstream data sources, and internal data items (including data items coming from Unity run-time 306).”],
queuing the external event for execution by the primary controller [Para 0023, 0031, 0035, “Events are captured in the event store 304… buffered time-stamped event transfer from a main RTU CPU to a standby RTU CPU”];
transferring the external event to the secondary controller [Para [0024], “Critical infrastructure benefits from the use of dual RTU CPUs 202A, 202B to increase system availability. Synchronizing the dual RTU CPUs 202A, 202B…”; Para [0035], “buffered time-stamped event transfer from a main RTU CPU to a standby RTU CPU”; Para 0065, In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).];
queuing the external event for synchronized execution by the secondary controller [Para [0031], “The standby RTU CPU 202B receives the events and inserts them into event buffers (in the same way as the main RTU CPU 202A).”; Para [0065], In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).]; and
in response to the external event and the associated input data received by the primary and secondary controllers, synchronizing execution of the external event by the primary and secondary controllers to achieve application state synchronicity between the primary controller and the secondary controller [Para [0031], “The standby RTU CPU 202B receives the events and inserts them into event buffers (in the same way as the main RTU CPU 202A).”; Para [0065], In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).; Para [0033], “Logic state data images are synchronized between the main RTU CPU 202A and the standby RTU CPU 202B starting with a snapshot of the logic state image on the main RTU CPU 202A at the end of the IEC 61131-3 logic scan. The logic state data image is compressed and transferred to the standby RTU CPU 202B. The standby CPU 202B receives, decompresses, and deploys the logic data image, synchronized with other data and event updates from the main RTU CPU 202A.”].
Aubin discloses the invention as detailed above for claim 12. Although Aubin discloses an event, the reference does not specifically teach an asynchronous external event; queuing the external event on an external event queue for execution by the primary controller as recited in the claim.
Chen discloses queuing the external event on an external event queue for execution by the primary controller [Col. 6, lines 62–67, “primary controller 6 … maintains in memory … a redrive I/O queue 28 to queue I/O requests to retry … and one path I/O queue 30 for each path 19 …”]. I/O requests are queued in specific queues for execution or retry;
Chen also discloses queuing the external event for synchronized execution by the secondary controller [Col. 8, lines 23–31, “the write request is queued … in the I/O path queue … to transmit the write request to the secondary controller 16”]. Requests are queued and transmitted to the secondary for execution.
Both Aubin and Chen are in the same field of endeavor as they are both in the synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin with the teachings of Chen to determine that received events comprise asynchronous external events as taught by Chen, before placing such events into the synchronized external event queues.
Motivation for the modification would have been to ensure deterministic execution of externally generated asynchronous events across redundant controllers, thereby improving synchronization accuracy and ensuring correct failover behavior.
Accordingly, it would have been obvious to combine teachings of the references because each is directed to maintaining synchronized execution among redundant processing systems in the presence of externally generated asynchronous events, and the combination merely applies the known technique of identifying and synchronizing asynchronous external events to the redundant controller architecture of Aubin to obtain predictable results.
Garcia discloses a system comprising an event-based controller is implemented at the sensor node of the networked and uncertain system and it transmits feedback measurements to the controller node at asynchronous time instants (see abstract).
Aubin, Chen and Garcia are in the same field of endeavor as they are in the synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin and Chen with the teachings of Garcia in order to reduce the number of instances where the sensor node needs to transmit feedback updates to the controller nodes as taught by Garcia.
Modification would provide an approach crucial in modern computing and control systems for handling unpredictable inputs, such as network traffic, user interactions, or sensor data, and a system that efficiently responds to external signals without halting its primary operations.
As per claim 13, Aubin discloses the system of claim 12, wherein the input data associated with the external event includes one or more of input/output (10) value changes, operator setpoint updates from a Human-Machine Interface, data changes from a subscribed peer controller, and events generated by internal Timer Objects [Para 0023, “Events are captured in the event store 304 based on an RTU configuration associated with physical I/O, downstream data sources, and internal data items (including data items coming from Unity run-time 306).”].
As per claim 14, Aubin discloses the system of claim 12, wherein synchronizing execution of the external event includes triggering execution of one or more function blocks within the control resource of the primary controller and the corresponding control resource of the secondary controller in response to the external event [Para 0033, “Logic state data images are synchronized between the main RTU CPU 202A and the standby RTU CPU 202B starting with a snapshot of the logic state image on the main RTU CPU 202A at the end of the IEC 61131-3 logic scan.”].
As per claim 15, Aubin discloses the system of claim 12, wherein synchronizing execution of the external event comprises maintaining identical control application states at the end of execution [Para 0033, “The standby CPU 202B receives, decompresses, and deploys the logic data image, synchronized with other data and event updates from the main RTU CPU 202A. The logic of standby RTU CPU 202B is ready to activate with the updated data image, within the timing of one scan on the logic of main RTU CPU 202A.”].
As per claim 16, Aubin discloses the system of claim 12, wherein the one or more storage memories store processor- executable instructions that, when executed, further configure the control resources for designating one controller in the duplex configuration as a preferred primary [Para 0028, “CPU A indicates RTU 110A in the main state and CPU B indicates RTU 110B in the standby state. Alternatively, CPU A could be in the standby state and CPU B could in the main state…”].
As per claim 17, Aubin discloses the system of claim 12, wherein the one or more storage memories store processor- executable instructions that, when executed, further configure the control resource of the primary controller for actively scanning one or more devices and synchronizing data from the 10 devices to the secondary controller [Para 0112, Table I, “MAIN Start I/O Scanning, Execute logic, enable Logic outputs controlled from database, allow events to be generated and stored, if partner CPU is in RESYNC or STANDBY queue update changes”].
As per claim 18, Aubin discloses the system of claim 17, wherein the one or more storage memories store processor- executable instructions that, when executed, further configure the control resource of the secondary controller for actively scanning the one or more 10 devices after taking over a primary role from the primary controller [Para 112, “The new partner CPU, i.e., standby CPU 202B, is deemed ‘Synchronized’ and enters a standby state when the logic application and logic data image is received and readied on the standby RTU 110B and the RED queue on the standby CPU 202B is empty. … Take control from other CPU (standby to main transition when manual change-over is triggered) … MAIN Start I/O Scanning, Execute logic, enable Logic outputs controlled from database, allow events to be generated and stored…”].
As per claim 21, Aubin discloses the system of claim 12, wherein queuing the external event for synchronized execution by the secondary controller comprises executing a runtime software component, wherein the runtime component is configured to run on one or more of a programmable logic controller (PLC), a controller of a distributed control system (DCS), and an industrial personal computer (IPC) [Para 0021, “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110. … The RTU 110 is configured to be interfaced to multiple control stations and intelligent electronic devices using different communication media such as RS485, RS232, Ethernet, microwave, satellite, etc.”].
As per claim 22, Aubin discloses the system of claim 12, wherein the input data includes one or more of: data from a sensor associated with the at least one process of the plant, data received from an operator interface, and data received from a peer controller [Para 0016, “The substation 104 includes a number of peripherals 106, including sensors, actuators, drives, and the like.”].
As per claim 23, Aubin discloses the system of claim 12, wherein each of the control resources comprises at least one of a programmable logic controller (PLC), a controller of a distributed control system (DCS), and an industrial personal computer (IPC), and wherein queuing the external event for synchronized execution by the secondary controller comprises executing a runtime software component on at least one of the control resources [Para 0021, “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110. … The RTU 110 is configured to be interfaced to multiple control stations and intelligent electronic devices using different communication media such as RS485, RS232, Ethernet, microwave, satellite, etc.”].
As per claim 24, Aubin discloses a process control system for achieving application state synchronicity comprising: a primary controller, the primary controller configured to actively monitor and control at least one process of a plant [Para [0005], a method for providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU; Para [0018], “The RTU 110 is used as a control device… collects measurements from various wireless and wired field sensors… RTU 110 can determine the tension or load… Other data collected by RTU 110 from the field sensors may include fluid flow rate, temperature, pressure, and the like.”; Para [0021], “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110.”];
a secondary controller in a duplex configuration with the primary controller, the secondary controller configured to actively monitor and control the at least one process of the plant responsive to a failure of the primary controller [Para 0024, “Critical infrastructure benefits from the use of dual RTU CPUs 202A, 202B to increase system availability. Synchronizing the dual RTU CPUs 202A, 202B…”]; and
one or more storage memories coupled to the primary and secondary controllers, the one or more storage memories storing processor-executable instructions that, when executed, configure the controllers for [Para 0021, “RTU 110 includes a memory 204 (e.g., volatile and non-volatile)…”]:
receiving an external event by the primary controller [Para 0005, providing redundancy synchronization of RTU CPUs associated with an industrial operation comprises queuing time-stamped events on a main RTU CPU for transfer to a standby RTU CPU as the time-stamped events are generated on the main RTU CPU, receiving the time-stamped events on the standby RTU CPU, and storing the time-stamped events in one or more standby RTU CPU event buffers; Para 0023, “Events are captured in the event store 304 based on an RTU configuration associated with physical I/O, downstream data sources, and internal data items (including data items coming from Unity run-time 306).”];
queuing the external event for execution by the primary controller [Para 0023, 0031, 0035, “Events are captured in the event store 304… buffered time-stamped event transfer from a main RTU CPU to a standby RTU CPU”];
transferring the external event to the secondary controller [Para [0024], “Critical infrastructure benefits from the use of dual RTU CPUs 202A, 202B to increase system availability. Synchronizing the dual RTU CPUs 202A, 202B…”; Para 0035, “buffered time-stamped event transfer from a main RTU CPU to a standby RTU CPU”; Para 0065, In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).];
queuing the external event for synchronized execution by the secondary controller [Para [0031], “The standby RTU CPU 202B receives the events and inserts them into event buffers (in the same way as the main RTU CPU 202A).”; Para 0065, In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).]; and
in response to the external event and the associated input data received by the primary and secondary controllers, synchronizing execution of the external event by the primary and secondary controllers to achieve application state synchronicity between the primary controller and the secondary controller [Para [0031], “The standby RTU CPU 202B receives the events and inserts them into event buffers (in the same way as the main RTU CPU 202A).”; Para [0065], In general, RTU Ethernet channels that provide server protocol support would normally provide a “Main” IP address so that external clients can reconnect to the RTU at a single IP address upon a standby-main processor changeover (e.g., remote protocols, local HMI, etc.).]; Para [0033], “Logic state data images are synchronized between the main RTU CPU 202A and the standby RTU CPU 202B starting with a snapshot of the logic state image on the main RTU CPU 202A at the end of the IEC 61131-3 logic scan. The logic state data image is compressed and transferred to the standby RTU CPU 202B. The standby CPU 202B receives, decompresses, and deploys the logic data image, synchronized with other data and event updates from the main RTU CPU 202A.”].
Aubin discloses the invention as detailed above for claim 24. Although Aubin discloses an event, the reference does not specifically teach an asynchronous external event; queuing the external event on an external event queue for execution by the primary controller as recited in the claim.
Chen discloses queuing the external event on an external event queue for execution by the primary controller [Col. 6, lines 62–67, “primary controller 6 … maintains in memory … a redrive I/O queue 28 to queue I/O requests to retry … and one path I/O queue 30 for each path 19 …”]. I/O requests are queued in specific queues for execution or retry;
Chen also discloses queuing the external event for synchronized execution by the secondary controller [Col. 8, lines 23–31, “the write request is queued … in the I/O path queue … to transmit the write request to the secondary controller 16”]. Requests are queued and transmitted to the secondary for execution.
Both Aubin and Chen are in the same field of endeavor as they are both in the synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin with the teachings of Chen to determine that received events comprise asynchronous external events as taught by Chen, before placing such events into the synchronized external event queues.
Motivation for the modification would have been to ensure deterministic execution of externally generated asynchronous events across redundant controllers, thereby improving synchronization accuracy and ensuring correct failover behavior.
Accordingly, it would have been obvious to combine teachings of the references because each is directed to maintaining synchronized execution among redundant processing systems in the presence of externally generated asynchronous events, and the combination merely applies the known technique of identifying and synchronizing asynchronous external events to the redundant controller architecture of Aubin to obtain predictable results.
Garcia discloses a system comprising an event-based controller is implemented at the sensor node of the networked and uncertain system and it transmits feedback measurements to the controller node at asynchronous time instants (see abstract).
Aubin, Chen and Garcia are in the same field of endeavor as they are in the synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin and Chen with the teachings of Garcia in order to reduce the number of instances where the sensor node needs to transmit feedback updates to the controller nodes as taught by Garcia.
Modification would provide an approach crucial in modern computing and control systems for handling unpredictable inputs, such as network traffic, user interactions, or sensor data, and a system that efficiently responds to external signals without halting its primary operations.
As per claim 25, Aubin discloses the process control system of claim 24, wherein queuing the external event for synchronized execution by the secondary controller comprises executing a runtime software component, wherein the runtime component is configured to run on one or more of a programmable logic controller (PLC), a controller of a distributed control system (DCS), and an industrial personal computer (IPC) [Para 0021, “RTU 110 includes a central processing unit (CPU) 202, which is the controller module of RTU 110. … The RTU 110 is configured to be interfaced to multiple control stations and intelligent electronic devices using different communication media such as RS485, RS232, Ethernet, microwave, satellite, etc.”].
Claim(s) 8-9 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aubin et al. (US PGPub 20230125853 A1) and Chen et al. (US 7251743 B2) and Model Based Event Triggered Control over lossy Networks, Garcia et al., July 2020 as applied to claims 1 and 12 above, and further in view of Arora et al. (US 8374966 B1).
As per claim 8, Aubin, Chen and Garcia disclose the invention as detailed above for claim 1. However, the combination of references does not specifically teach the method of claim 1, further comprising staging events on the secondary controller in a staging queue separate from an external events queue.
Arora discloses staging events on the secondary controller in a staging queue separate from an external events queue [Para 41, Fig. 1, Information is added to each of staging areas 102, 104, 106 by capture processes 112, 114 and 116, respectively. Information is consumed from each of staging areas 102, 104, 106 by consuming processes 122, 124 and 126, respectively].
Aubin, Chen, Garcia and Arora are in the same field of endeavor as they are both in the sharing of information and synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin, Chen and Garcia with the teachings of Arora to include a staging queue in order to avoid pausing execution to await the capture of the changes and avoid the need to report back to the capture processes to prompt the capture processes to continue execution as taught by Arora (Para 36).
Modification would provide an approach crucial in modern computing and control systems for handling unpredictable inputs, such as network traffic, user interactions, or sensor data, and a system that efficiently responds to external signals without halting its primary operations.
As per claim 9, Aubin, Chen, Garcia and Arora disclose the invention as detailed above for claim 8. Aubin further discloses the method of claim 8, further comprising removing events from the staging queue when the same event is synchronized from the primary controller [Para 0031, “The corresponding removal of buffered events from the standby RTU CPU 202B, occurs in real-time, as SCADA controlling station confirmations are received and removed from the main RTU CPU 202A.”].
As per claim 19, Aubin, Chen and Garcia disclose the invention as detailed above for claim 1. However, the combination of references does not specifically teach the system of claim 12, further comprising a staging queue for the secondary controller separate from an external events queue, wherein the one or more storage memories store processor-executable instructions that, when executed, further configure the control resource of the secondary controller for staging events on the secondary controller in the staging queue.
Arora discloses a staging queue for the secondary controller separate from an external events queue, wherein the one or more storage memories store processor-executable instructions that, when executed, further configure the control resource of the secondary controller for staging events on the secondary controller in the staging queue [Para 41, Fig. 1, Information is added to each of staging areas 102, 104, 106 by capture processes 112, 114 and 116, respectively. Information is consumed from each of staging areas 102, 104, 106 by consuming processes 122, 124 and 126, respectively].
Aubin, Chen, Garcia and Arora are in the same field of endeavor as they are both in the sharing of information and synchronization of event state by a controller and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Aubin, Chen and Garcia with the teachings of Arora to include a staging queue in order to avoid pausing execution to await the capture of the changes and avoid the need to report back to the capture processes to prompt the capture processes to continue execution as taught by Arora (Para 36).
Modification would provide an approach crucial in modern computing and control systems for handling unpredictable inputs, such as network traffic, user interactions, or sensor data, and a system that efficiently responds to external signals without halting its primary operations.
As per claim 20, Aubin, Chen, Garcia and Arora disclose the invention as detailed above for claim 19. Aubin further discloses the system of claim 19, wherein the one or more storage memories store processor- executable instructions that, when executed, further configure the control resource of the secondary controller for removing events from the staging queue when the same event is synchronized from the primary controller [Para 0031, “The corresponding removal of buffered events from the standby RTU CPU 202B, occurs in real-time, as SCADA controlling station confirmations are received and removed from the main RTU CPU 202A.”].
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Horst US 5317726 A teaches the processors are synchronized at the time of external events (memory references), resulting in the processors typically executing the same instruction stream, in the same sequence…” (Col. 6, lines 65–68).
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Pierre M. Vital whose telephone number is (571)272-4215. The examiner can normally be reached Mon-Fri, 8:00a-4:00p.
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, Zecher can be reached at (571) 272-7771. 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.
July 2, 2026
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights