DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 02/25/2026.
Claims 1 and 16 have been amended.
Claims 2-4, 9-11, and 14 have been cancelled.
Claims 1, 5-8, 12, 13, 15, and 16 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 02/25/2026 have been fully considered but they are not persuasive and/or moot in view of the new grounds of rejection as described below.
On pg. 7 of the Remarks, Applicant essentially argues:
Isolation in Wahler is achieved through software design and its corresponding structure: tasks are encapsulated as independent components that exchange data only through well-defined channels rather than shared memory, and the kernel relies on a realtime OS's scheduling and memory protection features to help contain faults. Put another way, Wahler' s system relies on careful scheduling and cooperative design of tasks for isolation…In contrast, the claims are amended to recite that each of the claimed sandboxes is partitioned from each other in memory and has its own execution environment. Given this clarification, the claimed sandbox is simply not a "process with OS provided isolation/protection" as suggested in the Office Action and this feature is not taught by Wahler.
Examiner notes the limitation is arguably inherently taught by Wahler when it is interpreted in view of AppSpec ¶00271 describing the recited memory partitioning is implemented via a conventional memory management unit (MMU). Wahler’s exemplary HW platform (pg. 102, col. 2) uses an Intel processor (all modern Intel processors have an MMU). But for completeness of record, Aiken is additionally cited in the rejections below concerning the limitation.
On pg. 7 of the Remarks, Applicant essentially argues:
Wahler does not teach or suggest the newly added claim feature that the abstraction layer for each of the claimed sandboxes intercepts system calls from a corresponding execution environment of the control software and reacts to the intercepted system calls as if the intercepted system calls were running on an original or an expected hardware/OS platform. This claim feature allows a given PLC control program to run on a different hardware platform or operating systems than the one it was originally built. Wahler does not include this structure and functionality.
The other cited references are also silent as to these features.
Examiner notes claim 7 recites limitations directed to essentially the same subject matter as the amended limitation with different verbiage (see Claim Interpretation below). As shown in the prior rejection to claim 7, Wahler partially discloses the subject matter in that Wahler discloses an abstraction layer which reacts to system calls originating from the execution environment in the manner expected by the environment and/or controller application. But in Wahler the applications are programmed against a generic, platform neutral/agnostic API and the abstraction layer maps/translates these generic system calls to platform specific system calls rather than translating from original platform specific calls to (different) platform specific calls. Cited prior art Vo is directed to methods for handling the “situation in which an application is executing within an operating system that is different from the operating system for which the application was initially designed” (¶0038) addresses the deficiency as shown in the rejections below and the rejection to claim 7 in the prior Office Action.
Applicant does not specifically address the combination including Vo, but generally argues “Wahler is also not concerned with the ability to execute control software with different hardware. As such, any modification of Wahler to include the claimed subject matter would necessarily rely on the Applicant's own teachings as providing the motivation for any modification and this would amount to an improper hindsight reconstruction of the claimed invention.”
Examiner respectfully disagrees, Wahler is explicitly “concerned with the ability to execute control software with different hardware.” Wahler describes the difficulty of reusing legacy control software on new hardware as a motivation (pg. 83-85) and specifically provides reusability and portability as design goals:
“FASA should support heterogeneous platforms, i.e., it should support the execution of control applications on a control system in which the controllers have different hardware architectures and/or operating systems…Such flexibility has several benefits…controllers can be replaced by more powerful controllers when more complex control applications are required; legacy controllers can easily be integrated into the control system; and applications can be reused across different controller types, ranging from low-end to high-end controllers” (pg. 85, col. 2).
Examiner additionally refers to “Migrating Legacy Control Software to Multi-core Hardware” included with this Action where the same author explores techniques and methods to use the FASA framework for the migration of existing control applications to a new software and hardware platform.
Claim Interpretation
Claim 7 recites limitations that appear to be directed to essentially the same subject matter as limitations added to claim 1 by amendment with different verbiage, but the addition of the limitations was not properly reflected to dependent claim 7 which now overlaps, conflicts, and/or have antecedent basis issues with the amended limitation.
Claim 1: wherein each abstraction layer of each sandbox intercepts system calls from a corresponding execution environment of the control software and reacts to the intercepted system calls as if the intercepted system calls were running on an original or an expected hardware/OS platform
Claim 7: wherein at least one sandbox contains an abstraction layer configured to react to system calls originating from an execution environment of the plurality of execution environments in a same way as the operating system and/or the hardware of a control unit for which the execution environment and/or the associated control software was developed.
In order to advance prosecution, claim 7 has been interpreted as being rolled into claim 1 as shown in the rejections below.
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.
Claims 1, 5-8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Wahler et al. (“FASA: A software architecture and runtime framework for flexible distributed automation systems”, 2015) in view of Bui (“Analysis of Docker Security”, 2015) in view of Aiken et al. (“Deconstructing Process Isolation”, 2006) in further view of Vo et al. (US 2008/0034377 A1) in further view of Vachharajani et al. (US 2013/0185586 A1).
Claims 1 and 7:
Wahler discloses the limitations as shown in the rejections below:
A programmable logic controller (PLC) (automation controller) for at least one field device in an industrial facility, comprising a hardware platform on which an operating system runs, the operating system being configured to execute, in at least one process, a plurality of execution environments (runtime framework/FASA kernel), in each of which a control software (control applications) containing control logic of the PLC is runnable so as to provide multiple redundant instances of the control software (see pg. 82, Abstract and § 1, para. 3; pg. 87-88, § 4 and Fig. 8; pg. 91, Fig. 13).
the hardware platform comprising a main memory, a processor, and communication resources (pg. 86, Fig. 4; pg. 93, § 5.1; pg. 91, Fig. 13; pg. 102, col. 2)
…execute each of the plurality of execution environments in its own sandbox (its own process with OS provided isolation/protection, limitation further discussed below)…wherein each sandbox to execute each of the plurality of execution environments is not configured as a virtual machine, wherein each of the plurality of execution environments (Runtime Framework/FASA kernel) runs, mediated by abstraction layers, as a normal process on the operating system, (see at least pg. 88; pg. 93, col. 2; pg. 106, § 7.2). Exemplary quotation:
“Each kernel runs on exactly one CPU core, and one CPU core executes at most one kernel. FASA requires the operating system to support fixed-priority preemptive scheduling. The FASA kernel must be executed at the highest priority as a user level process...the kernel calls a platform-specific initialization function on startup. In our reference implementation for RTLinux, this function locks the kernel process into memory and sets its priority to the maximum value.”
For clarity of record regarding the mapping to Wahler elements, Examiner notes a FASA “kernel” is an instantiation of the Framework and Abstraction Layer illustrated Fig. 13.
wherein each abstraction layer of the abstraction layers provides a run-time environment for system calls (requests to access platform resources/services) originating from a respective one of the plurality of execution environments (see at least pg. 91-92, § 4.5; pg. 98, § 5.5).
a redundancy manager (fault tolerance service) configured to: provide a functionality of the PLC in relation to the at least one field device from the multiple redundant instances of the control software, forward data inputs from the at least one field device to the multiple redundant instances of the control software, and make data outputs (sent to voter component) subsequently generated by the multiple redundant instances of the control software consistent with one another (via voting based error checking2), wherein each of the multiple redundant instances of the control software is programmed differently (design diversity) (see at least pg. 92, § 4.6; pg. 100, col. 2).
wherein the redundancy manager is configured to continuously monitor a functioning of the multiple redundant instances of the control software and, when an instance fails…to activate at least one additional instance in an additional execution environment in a further sandbox (see at least pg. 93, col. 1; pg. 101, col. 1, limitation further discussed below).
the PLC is configured to communicate with the at least one field device (target device on fieldbus, e.g. valve, electromagnet) in the industrial facility via an I/O interface (pg. 83, col. 2; pg. 100).
As noted above, Wahler employs OS implemented protection and resource partitioning mechanisms to ‘sandbox’/isolate the processes from one another including memory protection and CPU core affinities. Wahler does not specifically disclose a higher-level management system configured to run directly on the operating system and to execute each of the plurality of execution environments in its own sandbox, the management system comprising a resource manager configured to allocate to each sandbox access to the main memory, the processor, and the communication resources of the hardware platform.
However, resource partitioning/control management by user-mode software was known in the art as shown by Bui; describing (non-VM) container-based virtualization including “using the host kernel to run multiple virtual environments…referred to as containers…containers look like normal processes from outside, which run on top of the kernel shared with the host machine. They provide isolated environments with necessary resources to execute applications” (Bui pg. 1, § 2) and further discloses a higher-level management system (Container engine/Docker daemon) configured to run directly on the operating system (Host OS) and to execute each of the plurality of execution environments in its own sandbox (container), the management system comprising a resource manager configured to allocate to each sandbox access to the main memory, the processor, and the communication resources of the hardware platform in at least Bui pg. 2-3, § 3.1; pg. 5, col. 1, para. 1-2; pg. 2, Fig. 1 and 3).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Wahler to run the FASA kernel processes in containers described by Bui to achieve greater resource control and security over the applications with low overhead (Bui pg. 2, col. 1, para. 2; pg. 6, § 5; pg. 5, col. 1, para. 1-2).
Bui further discloses (pg. 3-4, § 4.1, para. 4-5; pg. 5, col. 1, para. 1-2) that each sandbox (container) is partitioned (isolated) from each other using cgroups and namespaces “cgroups provide mechanism for limiting the resources which the processes in each container can access…achieves isolation of processes by wrapping the processes running in containers into namespaces and limiting their permissions and visibility to processes running in the other containers” (pg. 3); Wahler also briefly discloses (pg. 93, § 5.1; pg. 85, § 2.3.3) employing OS process isolation and memory protection, but does not elaborate on any HW mechanisms being employed and does not explicitly disclose each sandbox in the main memory is partitioned from each other using a MMU.
Aiken, however, compares different process isolation implementations including “hardware isolated processes (HIPs), which are analogous to processes in other operating systems” (pg. 1, § 1, para. 5) and further discloses (pg. 4, § 3; pg. 5, § 3.4, para. 1) each sandbox (HIP or “protection domain”) in the main memory is partitioned from each other using an MMU3.
“Singularity implements hardware isolation through a protection domain (domain for short), which is a hardware-enforced protection boundary that…consists of a distinct virtual address space. The processor’s MMU enforces memory isolation in a conventional manner...Hardware isolated processes (HIPs) are the norm for modern operating systems, such as Unix or Windows. HIPs rely on a processor’s memory management unit (MMU) to implement a distinct virtual address space for each process.”
It would have been obvious to one of ordinary skill in the art at the time the invention was filed for Wahler/Bui to employ MMU hardware isolation to protect the memory of each process/container as described by Aiken because it is a standard “powerful, multi-faceted mechanism” for enforcing isolation and "Process isolation is a fundamental function of most operating systems. Isolation protects system integrity by preventing one process from interfering with another’s, or the system’s, code or data, and by preventing untrusted code from accessing protected resources” (Aiken pg. 1, § 1, para. 5; pg. 5, § 3.4, para. 1; pg. 9, § 5).
Wahler further discloses (pg. 91-92, § 4.5; pg. 98, § 5.5; pg. 99, Listing 14 and 15; and pg. 94, col. 1) each abstraction layer configured to react to system calls originating/intercepted from an execution environment (framework) of a corresponding execution environments in a same way/ as if the intercept calls were running on [application and/or framework expects], But Wahler’s abstraction layer maps/translates from a generic, platform neutral, system calls to platform specific system calls rather than translating from original platform specific to (different) platform specific, and the combination does not specifically disclose wherein each abstraction layer of each sandbox intercepts system calls from a corresponding execution environment of the control software and reacts to the intercepted system calls as if the intercepted system calls were running on an original or an expected hardware/OS platform [claim 7: for which the execution environment and/or the associated control software was developed].
Vo, however, discloses (¶0018-0020, 0023-0026, 0032-0034; FIG. 2-4) discloses methods for handling the “situation in which an application is executing within an operating system that is different from the operating system for which the application was initially designed” (¶0038) including using an abstraction layer (shim and/or compatibility module) that hooks/receives through redirection (intercepts) system calls from a legacy application (software) or legacy binary (execution environment) and reacts (provide callbacks and/or exceptions) to the intercepted system calls as if the intercepted system calls were running on an original or an expected hardware/OS platform [claim 7: for which the execution environment (legacy binary) and/or the associated control software (application) was developed (“operating system for which the application was initially designed”). Exemplary quotations:
“the application compatibility module 300 may receive system calls from the legacy binaries 20a-n and translate the system calls into formats that can be understood and processed by the native operating system 230. Additionally, the application compatibility module may receive callbacks and exceptions from the native operating system 230 and translate the callbacks and exceptions into formats that can be understood and processed by the legacy binaries” (¶0020).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the Abstraction layer of Wahler/Bui/Aiken to handle legacy system calls, as taught by Vo, in addition to generic system calls to expand the range applications that can run on the platform and the flexibility of developers preparing applications for the platform (Vo ¶0005, 0019, 0038; Wahler pg. 83-84, § 2.2).
Regarding the monitoring/restarting functionality, as noted above Wahler discloses starting a replacement replica in response to detecting a failed instance, but the combination of Wahler/Bui does not specifically disclose both activating an additional instance and performing a restart of the failed instance as a recovery technique and does not specifically disclose when an instance fails, to restart this instance and/or its execution environment, and to activate at least one additional instance in an additional execution environment in a further sandbox.
However, it was known alternative in the high-availability/fault management arts to both restart a failed redundant instance and start an additional instance as shown by Vachharajani disclosing (¶148-0150, 0157-0159,0040, 0114-0115, 0146) a redundancy manager (health monitor) is configured to continuously monitor a functioning of the multiple redundant instances of the control software and, when an instance fails, to restart this instance and/or its execution environment, and to activate at least one additional instance in an additional execution environment in a further sandbox:
“The health monitor application 1310 may monitor the state information for each of the application instances stored in the share system database 1105-g to dynamically detect and remedy problems arising with the application instances (¶0148)…If one instance of the load balancing application 215 crashes, the health monitor application 1310 may detect the crash…Upon detecting the crash, the health monitor application 1310 may…cause the controller application 205-e to attempt to restart the crashed instance of the load balancing application 215 and/or create a new instance of the load balancing application” (¶0149, emphasis added).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Wahler/Bui/Aiken/Vo’s fault response method with the fault remediation disclosed by Vachharajani to increase the flexibility of the of the fault handling and ensure the best remedy is applied for the particular fault detected (Vachharajani ¶0148-0150, 0157-0159).
Claim 5:
The combination of Wahler/Bui/Aiken/Vo/Vachharajani discloses the limitations as shown in the rejections above. Wahler further discloses (pg. 83, col. 2; pg. 92, § 4.6, para. 1-3 and Fig. 15; pg. 100; pg. 106). the redundancy manager is configured to control a communication of multiple redundant instances of the control software with the at least one field device (target device on fieldbus, e.g. valve, electromagnet) according to a round robin method (switchover and/or load balancing).
Claim 6:
The combination of Wahler/Bui/Aiken/Vo/Vachharajani discloses the limitations as shown in the rejections above. Wahler further discloses wherein the functionality of the PLC is provided by the plurality of execution environments (FASA kernels), the plurality of execution environments comprising two execution environments having different contents (different functions on different platforms), and/or by two instances (replicas) of the control software (pg. 83, Fig. 2; pg. 86; pg. 88; pg. 92, Fig. 16).
Claim 8:
The combination of Wahler/Bui/Aiken/Vo/Vachharajani discloses the limitations as shown in the rejections above. Vo further discloses (¶0023-0026, 0032-0034; FIG. 2-4) wherein the abstraction layer contains at least one runtime environment configured to implement handling routines (e.g. translation table) for the system calls originating from the execution environment, using the native operating system upon which the binaries/application are executing. See also Wahler (pg. 94, § 4.5; pg. 98-99).
Claim 15:
The combination of Wahler/Bui/Aiken/Vo/Vachharajani discloses the limitations as shown in the rejections above. Wahler further discloses a computer program product containing machine-readable instructions, which, if executed on a computer and/or a given PLC (controller), configure the computer or given PLC as the PLC according to claim 1 in at least pg. 102, col. 2; pg. 91, Fig. 13.
Claim 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Wahler in view of Bui in view of Aiken in view of Vo in view of Vachharajani in further view of Blanding et al. (US 9,081,627 B1).
Claim 12:
The combination of Wahler/Bui/Aiken/Vo/Vachharajani discloses the limitations as shown in the rejections above. As noted above, Bui discloses that Docker is configured to “control the amount of resources, such as CPU, memory, and disk I/O, that any Docker container can use, ensuring that each container obtains its fair share of the resources and preventing any container from consuming all resources. They also allow Docker to configure the limits and constraints related to the resources allocated to each container”, but does not describe reallocation methods and the combination of Wahler/Bui/Aiken/Vo/Vachharajani does not specifically disclose wherein the resource manager is configured to reallocate allocations unused in at least one first sandbox for access to the main memory, processor, and/or communication resources to at least one second sandbox.
Blanding, however, discloses methods for managing container resource allocations where a resource manager (workload manager) is configured to reallocate (reassign/transfer) allocations unused in at least one first sandbox (container) for access to the main memory, processor, and/or communication resources to at least one second sandbox in at least col. 4, li. 52-65; col. 6, li. 40-48; col. 7, li. 30-42; col. 8, li. 1-7.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Wahler/Bui/Aiken/Vo/Vachharajani to employ the resource reassignment methods taught by Blanding to increase the containers execution efficiency by ensuring that the resource allocations matches their resource needs (Blanding col. 1, li. 54-58; col. 6, li. 40-48; col. 7, li. 30-42).
Claim 13:
The combination of Wahler/Bui/Aiken/Vo/Vachharajani discloses the limitations as shown in the rejections above. As noted above, Bui discloses that Docker is configured to “control the amount of resources, such as CPU, memory, and disk I/O, that any Docker container can use, ensuring that each container obtains its fair share of the resources and preventing any container from consuming all resources. They also allow Docker to configure the limits and constraints related to the resources allocated to each container”, but does not describe reallocation methods and the combination of Wahler/Bui/ Vachharajani does not specifically disclose wherein the resource manager is configured to completely or partially revoke a respective resource of at least one first sandbox and to reallocate it to at least one second sandbox according to rules in a set of rules when there is a shortage of main memory, processor power, and/or communication resources.
Blanding, however, discloses methods for managing container resource allocations where a resource manager (workload manager) is configured to completely or partially revoke a respective resource of at least one first sandbox (container) and to reallocate (reassign/transfer) it to at least one second sandbox according to rules (policies, priorities, costs) in a set of rules when there is a shortage of main memory, processor power, and/or communication resources in at least col. 4, li. 52-65; col. 6, li. 40-48; col. 7, li. 8-42; col. 7, li. 63 – col. 8, li. 19.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Wahler/Bui/Vachharajani to employ the resource reassignment methods taught by Blanding to increase the containers execution efficiency by ensuring that the resource allocations matches their resource needs (Blanding col. 1, li. 54-58; col. 6, li. 40-48; col. 7, li. 30-42).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Wahler in view of Bui in view of Aiken in view of Vo in further view of Smith et al. (US 2009/0076628 A1).
Claim 16:
Wahler discloses the limitations as shown in the rejections below:
A method for controlling at least one field device in an industrial facility by a PLC (automation controller), the method comprising executing, by…an operating system which in turn is running on a hardware platform of the PLC, a plurality of execution environments (runtime framework/FASA kernels), each in a sandbox (its own process with OS provided isolation/protection, limitation further discussed below) of its own (see pg. 82, Abstract and § 1, para. 3; pg. 87-88, § 4 and Fig. 8; pg. 91, Fig. 13).
the hardware platform comprising a main memory, a processor, and communication resources (pg. 86, Fig. 4; pg. 93, § 5.1; pg. 91, Fig. 13; pg. 102, col. 2)
executing, in a first execution environment (Runtime framework/FASA kernel) associated with a first sandbox, a first instance of a control software (control application, component thereof) containing first control logic of the PLC, the first control logic comprising existing functionality of the control software; executing, in a second execution environment associated with a second sandbox, a second instance of the control software containing second control logic of the PLC, the second control logic comprising new (updated) functionality of new program code; wherein the first sandbox and the second sandbox are not configured as virtual machines, wherein each of the first execution environment (Runtime Framework/FASA kernel) and the second execution environment runs, mediated by abstraction layers, as a normal process on the operating system (see at least pg. 88; pg. 90, § 4.3; pg. 93, col. 2; pg. 106, § 7.2). Exemplary quotation (emphasis added):
“Each kernel runs on exactly one CPU core, and one CPU core executes at most one kernel…The FASA kernel must be executed at the highest priority as a user level process. As shown in Section 3.2, applications can be spread across and executed on multiple kernels. This means that parallel branches in an application can be executed in parallel although each branch is executed in a linear way through ‘‘its’’ kernel. Analogously, each kernel can execute an arbitrary number of applications” (pg. 88).
wherein each abstraction layer of the abstraction layers provides a run-time environment for system calls (requests to access platform resources/services) originating from the first execution environment and the second execution environment (see at least pg. 91-92, § 4.5; pg. 98, § 5.5).
communicating the outcome of the instances of the control software to the at least one field device (target device on fieldbus, e.g. valve, electromagnet) via an I/O interface (pg. 83, col. 2; pg. 100).
As noted above, Wahler employs OS implemented protection and resource partitioning mechanisms to ‘sandbox’/isolate the processes from one another including memory protection and CPU core affinities. Wahler does not specifically disclose a higher-level management system, running directly on the operating system, executing each of the plurality of execution environments in its own sandbox, the management system comprising a resource manager configured to allocate to each sandbox access to the main memory, the processor, and the communication resources of the hardware platform.
However, resource partitioning/control management by user-mode software that runs on the Host OS was known in the art as shown by Bui; describing (non-VM) container-based virtualization including “using the host kernel to run multiple virtual environments…referred to as containers…containers look like normal processes from outside, which run on top of the kernel shared with the host machine. They provide isolated environments with necessary resources to execute applications” (Bui pg. 1, § 2) and further discloses a higher-level management system (Container engine/Docker daemon) running directly on the operating system (Host OS) executing each of the plurality of execution environments in its own sandbox (container), the management system comprising a resource manager configured to allocate to each sandbox access to the main memory, the processor, and the communication resources of the hardware platform in at least pg. 2-3, § 3.1; pg. 5, col. 1, para. 1-2; pg. 2, Fig. 1 and 3).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Wahler to run the FASA kernel processes in containers described by Bui to achieve greater resource control and security over the applications with low overhead (Bui pg. 2, col. 1, para. 2; pg. 6, § 5; pg. 5, col. 1, para. 1-2).
Bui further discloses (pg. 3-4, § 4.1, para. 4-5; pg. 5, col. 1, para. 1-2) that each sandbox (container) is partitioned (isolated) from each other using cgroups and namespaces “cgroups provide mechanism for limiting the resources which the processes in each container can access…achieves isolation of processes by wrapping the processes running in containers into namespaces and limiting their permissions and visibility to processes running in the other containers” (pg. 3); Wahler also briefly discloses (pg. 93, § 5.1; pg. 85, § 2.3.3) employing OS process isolation and memory protection, but does not elaborate on the mechanisms being employed and does not explicitly disclose each sandbox in the main memory is partitioned from each other using a HW memory management unit (MMU).
Aiken, however, compares different process isolation implementations including “hardware isolated processes (HIPs), which are analogous to processes in other operating systems” (pg. 1, § 1, para. 5) and further discloses (pg. 4, § 3; pg. 5, § 3.4, para. 1) each sandbox (HIP/protection domain) in the main memory is partitioned from each other using a MMU.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed for Wahler/Bui to employ MMU hardware isolation to protect the memory of each process/container as described by Aiken because it is a standard “powerful, multi-faceted mechanism” for enforcing isolation and "Process isolation is a fundamental function of most operating systems. Isolation protects system integrity by preventing one process from interfering with another’s, or the system’s, code or data, and by preventing untrusted code from accessing protected resources” (Aiken pg. 1, § 1, para. 5; pg. 5, § 3.4, para. 1; pg. 9, § 5).
Wahler further discloses (pg. 91-92, § 4.5; pg. 98, § 5.5; pg. 99, Listing 14 and 15; and pg. 94, col. 1) each abstraction layer configured to react to system calls originating/intercepted from an execution environment (framework) of a corresponding execution environments in a same way/ as if the intercept calls were running on [application and/or framework expects], But Wahler’s abstraction layer maps/translates from a generic, platform neutral, system calls to platform specific system calls rather than translating from original platform specific to (different) platform specific, and the combination does not specifically disclose wherein each abstraction layer of each sandbox intercepts system calls from a corresponding execution environment of the control software and reacts to the intercepted system calls as if the intercepted system calls were running on an original or an expected hardware/OS platform for which the execution environment and/or the associated control software was developed.
Vo, however, discloses (¶0018-0020, 0023-0026, 0032-0034; FIG. 2-4) discloses methods for handling the “situation in which an application is executing within an operating system that is different from the operating system for which the application was initially designed” (¶0038) including using an abstraction layer (shim and/or compatibility module) that hooks/receives through redirection (intercepts) system calls from a legacy application (software) or legacy binary (execution environment) and reacts (provide callbacks and/or exceptions) to the intercepted system calls as if the intercepted system calls were running on an original or an expected hardware/OS platform for which the associated control software application was developed (“operating system for which the application was initially designed”).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the Abstraction layer of Wahler/Bui/Aiken to handle legacy system calls, as taught by Vo, in addition to generic system calls to expand the range applications that can run on the platform and the flexibility of developers preparing applications for the platform (Vo ¶0005, 0019, 0038; Wahler pg. 83-84, § 2.2).
As noted above, Wahler supports distributed application execution where different application components run in different processes and discloses dynamic application component loading and updating, but does not explicitly disclose wherein the first instance of the control software is run in the first sandbox, and the second instance of the control software which contains only the new functionality is run in a second sandbox.
Smith, however, discloses an analogous system for executing industrial control software where “functions of the control devices and/or control algorithms are isolated, split and/or separated into individual components” (¶0016) and discloses (¶0052, 0056-0058) embodiments where wherein the first instance of the control software is run in the first sandbox (isolated RTOS process), and the second instance of the control software which contains only the new functionality (new/upgraded features/component) is run in a second sandbox (isolated RTOS process). Exemplary quotation:
“The upgrade module starts an instance of the new control component in an "update pending" mode (block 615). In some examples, the new control component is instantiated as an isolated process of an RTOS (¶0052)... The simultaneous execution of two versions of a particular control component allows a process control system additional flexibility in adding new features and/or in fixing defects in existing control components. For example, a new control component containing a so-called "hot fix" that may not yet be fully quality tested can be introduced and utilized by only those control algorithms requiring the change” (¶0058).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Wahler/Bui/Aiken/Vo control software update method in accordance with that of Smith to obtain greater flexibility in adding new features and fixing defects in existing control components (Smith ¶0015, 0058).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
“Migrating Legacy Control Software to Multi-core Hardware” cited in the response to arguments above as evidence of analogous art/field of endeavor.
US 20150378936 A1 and 20110055518 A1 are directed to MMU based memory partitioning.
“Osprey: Operating System for Predictable Clouds” is directed to an OS that supports legacy applications through API interception and emulation.
“Operating Systems - Memory Management: Paging” background information on virtual memory and MMUs.
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
03/26/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
1 “All means which the operating system and/or the hardware platform provide for this purpose can be used for the partitioning (sandboxing) of the sandboxes from one another. For example, a memory management unit (MMU) of the hardware platform can partition the areas of the main memory allocated to the individual sandboxes from one another.”
2 Interpretation for this limitation derived from AppSpec ¶0032.
3 Interpretation for this limitation derived from AppSpec ¶0027.