Prosecution Insights
Last updated: April 19, 2026
Application No. 17/836,624

VISUALIZSATION OF A SOFTWARE DEFINED PROCESS CONTROL SYSTEM FOR INDUSTRIAL PROCESS PLANTS

Non-Final OA §103§DP
Filed
Jun 09, 2022
Examiner
FIBBI, CHRISTOPHER J
Art Unit
2174
Tech Center
2100 — Computer Architecture & Software
Assignee
Fisher-Rosemount Systems Inc.
OA Round
3 (Non-Final)
53%
Grant Probability
Moderate
3-4
OA Rounds
4y 3m
To Grant
90%
With Interview

Examiner Intelligence

Grants 53% of resolved cases
53%
Career Allow Rate
199 granted / 376 resolved
-2.1% vs TC avg
Strong +38% interview lift
Without
With
+37.6%
Interview Lift
resolved cases with interview
Typical timeline
4y 3m
Avg Prosecution
40 currently pending
Career history
416
Total Applications
across all art units

Statute-Specific Performance

§101
9.8%
-30.2% vs TC avg
§103
62.9%
+22.9% vs TC avg
§102
10.7%
-29.3% vs TC avg
§112
10.2%
-29.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 376 resolved cases

Office Action

§103 §DP
DETAILED ACTION This action is in response to the RCE and Amendment dated 29 January 2026. Claims 1, 8, 10, 15, 17, 38, 58 and 59 are amended. No claims have been added or cancelled. Claims 1-80 remain pending and have been considered below. 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 Amendment Based on applicant’s amendment, the claims objections of claims 1, 8 and 59 are withdrawn. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1-20, 22-24, 27-31, 34, 35, and 37-80 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15, 17-20, 32, 37, 39, 41, 42, 44 and 45 of copending Application No. 17/838951 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because: Instant App. ‘624 Reference App. ‘951 Claims 1, 38, 59 Claim 1 The features of the claims listed above of the instant application are anticipated by or are obvious variants of the identified claims of the reference patent. Claims 2, 41, 63 Claim 3 Claims 3, 42, 43, 64, 65 Claim 17 Claim 4 Claim 18 Claim 5 Claim 19 Claims 6, 44, 66 Claim 20 Claim 7 Claim 4 Claims 8, 39, 61 Claim 5 Claims 9, 40, 62 Claim 6 Claims 10, 45, 67 Claim 7 Claims 11, 46, 68 Claim 8 Claim 12 Claim 9 Claim 13 Claim 10 Claim 14 Claim 11 Claims 15, 56, 78 Claim 12 Claim 16 Claim 13 Claims 17, 57, 79 Claim 32 Claims 18, 47, 60, 69 Claim 37 Claims 19, 48, 70 Claim 37 Claims 20, 49, 71 Claim 38 Claim 22 Claim 39 Claims 23, 50, 72 Claim 14 Claim 24 Claim 41 Claims 27, 51, 73 Claim 42 Claims 28, 52, 74 Claim 37 Claims 29, 53, 75 Claim 15 Claims 30, 54, 76 Claim 44 Claims 31, 55, 77 Claim 45 Claim 34 Claim 3 Claim 35 Claim 2 Claim 37 Claim 37 This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented. Claims 1, 2, 6, 8-11, 18-31, 33 and 35-37 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 25-46 and 48-52 of copending Application No. 17/838798 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because: Instant App. ‘624 Reference App ‘798 Claim 1 Claim 25 The features of the claims listed above of the instant application are anticipated by or are obvious variants of the identified claims of the reference patent. Claim 2 Claim 26 Claim 6 Claim 27 Claim 8 Claim 28 Claim 9 Claim 29 Claim 10 Claim 30 Claim 11 Claim 31 Claim 18 Claim 32 Claim 19 Claim 33 Claim 20 Claim 34 Claim 21 Claim 35 Claim 22 Claim 36 Claim 23 Claims 37, 38 Claim 24 Claim 39 Claim 25 Claim 40 Claim 26 Claim 41 Claim 27 Claim 42 Claim 28 Claim 43 Claim 30 Claim 45 Claim 31 Claim 46 Claim 33 Claim 48 Claim 35 Claim 49 Claim 36 Claim 50 Claim 37 Claim 52 This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented. Claim Rejections - 35 USC § 103 This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 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, 2, 8-12, 14-20, 22-24, 26, 29-41, 45-50, 53-63, 67-72 and 75-80 are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 2018/0316729 A1) in view of Rimar et al. (US 2019/0379590 A1) and further in view of Wouhaybi et al. (US 2020/0310394 A1). As for independent claim 1, Chauvet teaches a system comprising: a data cluster comprising a plurality of computing nodes, each computing node comprising: a processor executing an instance of an operating system; a memory; and a communication resource coupled to the one or more other computing nodes in the data cluster [(e.g. see Chauvet paragraphs 0042, 0045, 0047, 0111, 0210) ”This disclosure describes Software-defined Automation (hereinafter “SDA”) technology and system (hereinafter “SDA system”) which provides a reference architecture for designing, managing and maintaining a highly available, scalable and flexible automation system … As depicted in FIG. 1, the architecture of an SDA system 100 comprises of three aspects: (1) a smart distributed system 105, (2) a communication backbone 110, and (3) smart connected devices 115 … the system exhibits distributed intelligence by enabling a guest (e.g., a control/automation application) to be logically defined and distributed and re-distributed to run on one or more hosts (e.g., virtual machines, containers, bare metals) on a server, on a physical automation controller, an embedded system, and the like … comprise of hardware, software, sensors, storage, microprocessor(s), connectivity and the like … a compute resource can be a server machine, a personal computer, an embedded hardware, a human machine interface (HMI) module or an industrial controller … comprised of a control and management infrastructure called the controller nodes 810-1, 810-2 along with the associated compute nodes 820-1, 820-2, 820-3, . . . , 820-N. Each of the compute nodes 820-1, 820-2, 820-3, . . . , 820-N can execute a number of hosts 802-1, . . . , 802-N and associated virtual networks 820. These hosts can be virtual machines, containers or bare metals”]. a plurality of containers executing on the data cluster, the plurality of containers in communication with a software defined networking controller that communicatively couples the containers to a plurality of process control field devices operating to control a physical process in an industrial process plant [(e.g. see Chauvet paragraphs 0054, 0095, 0111 and Figs. 2B, 6B and 8A) ”the example OT architecture as defined by the SDA technology depicted in FIG. 2B is considerably simpler, with three levels of control … an application running in a PLC in functional unit 275B can be moved to the server(s) 285 (e.g., by creating a virtual PLC which is a software implementation of a PLC on a host such as a virtual machine or a container) and the network can be automatically configured to ensure traffic from the virtual PLC (“vPLC”) in the server(s) 285 flows to the I/O devices in functional unit 275B in a timely manner to monitor and/or control input/output devices or field devices … The fog server is comprised of a control and management infrastructure called the controller nodes 810-1, 810-2 along with the associated compute nodes 820-1, 820-2, 820-3, . . . , 820-N. Each of the compute nodes 820-1, 820-2, 820-3, . . . , 820-N can execute a number of hosts 802-1, . . . , 802-N and associated virtual networks 820. These hosts can be virtual machines, containers or bare metals. Each host in turn can execute a guest 804. A guest 804 can include an application, an application function (i.e., a piece or portion of an application corresponding to or performing a function), or any software implementation of a physical device, component or functional unit. In some embodiments, a host 802-1 can execute another host 802-A which in turn can run a guest. For example, the host 802-1 of compute node 820-3 can be a virtual machine on which a container 802-A is instantiated to run guest 804. The virtual networks 820 connect from within the compute nodes (e.g., 820-1, 820-2, . . . ) through external interfaces (e.g., Ethernet ports) to the external physical networks (e.g., Data/OT network 865). Virtual networks 820 reside inside the compute nodes (e.g., 820-1, 820-2, . . . ) and provide connectivity between the virtualized entities and the physical world … the fog server controller 610 can create the virtual networks 620 in the fog server 605 and control connectivity between the virtual machines/containers hosted on the compute nodes 615 and the virtual networks 620, while the network controller 690 can configure the virtual network components 622 of the virtual networks 620 in accordance with one or more network policies”]. a container orchestrator operable to instantiate the containers and manage fault tolerance and load balancing functions on the data cluster [(e.g. see Chauvet paragraph 0134 and Fig. 10B) ”While each one of the orchestration components are individually orchestrated, a top level orchestration component—the system orchestration component 1016—orchestrates them together to virtualize devices and applications on compute nodes 1015 in the fog server 1005 (via fog server orchestration 1024), manage data associated with those virtualized devices and applications in storage 1025/1026 (via storage orchestration 1026), define and disseminate cyber security policies to all components of the SDA system (via cyber security orchestration 1018), and network flows and communications (via network orchestration 1022)”]. Chauvet does not specifically teach a visualization routine executing on the data cluster, the visualization routine operable to receive real-time data from one or more of the plurality of containers, or from the software defined networking controller, or from the container orchestrator or and to present a graphical depiction of an operation of at least a portion of the process control system based on the received data, the graphical depiction representing at least a portion of a process control system runtime configuration of the process control system, the process control system runtime configuration having a logical configuration including a plurality of control logical elements, the graphical depiction including a depiction of a manner in which one or more of the plurality of containers is currently associated with the one or more process control logical elements and the graphical depiction further including a performance indication for at least a portion of the logical configuration. However, in the same field of invention, Rimar teaches: a visualization routine executing on the data cluster, the visualization routine operable to receive real-time data from one or more of the plurality of containers, or from the software defined networking controller, or from the container orchestrator [(e.g. see Rimar paragraphs 0111, 0144, 0135 and Figs. 3, 6 and 8B) ”A containerized software application may be a software application configured to be executed in a container. A container, in turn, is a software package that includes an entire runtime environment needed to execute a given software application … For example, a computing device disposed within managed network 300, within remote network management platform 320, or within computing cluster 604 may request configuration data from API 608. The configuration data may indicate that application 800 is executing in pod 806 on worker node 612A, a first copy of application 802 is executing in pod 808A on worker node 612B, a second copy of application 802 is executing in pod 808B on worker node 612D, and application 804 is executing in pod 810 on worker node 612C. The computing device may also request and receive, from each of the packet detection modules executing on worker nodes 612A, 612B, 612C, and 612D, traffic data corresponding to any connections that have been established between pods 806, 808A, 808B, and 810 … the computing device may be configured to periodically repeat the operations described above to track a history of changes in the distribution of resources in computing cluster 604. Specifically, the computing device may be configured to periodically access the configuration data via API 608 and access the traffic data from packet detection modules 700A and 700B to keep track of the distribution and communicative relationships between software application(s) 624A and 624B, container(s) 622A and 622B, pod(s) 620A and 620B, and worker nodes 612A and 612B over time”]. and to present a graphical depiction of an operation of at least a portion of the process control system based on the received data, the graphical depiction representing at least a portion of a process control system runtime configuration of the process control system, the process control system runtime configuration having a logical configuration including a plurality of control logical elements, the graphical depiction including a depiction of a manner in which one or more of the plurality of containers is currently associated with the one or more process control logical elements and the graphical depiction further including a performance indication for at least a portion of the logical configuration [(e.g. see Rimar paragraphs 0081, 0111, 0113, 0116, 0129, 0145, 0146 and Figs. 9A-B) ”A containerized software application may be a software application configured to be executed in a container. A container, in turn, is a software package that includes an entire runtime environment needed to execute a given software application … provide data indicative of the communicative relationships between the worker nodes, pods, containers, software applications, and/or other components of the container orchestration engine executing on computing cluster 604 … The traffic data may be parsed by the computing device for patterns indicative of communicative relationships between pods 806, 808A, 808B, and 810 (and thus applications 800, 802, and 804 as well as the containers in which these application are executed). The computing device may also generate mappings between any pods (and thus any containers and applications) that have communicative relationships therebetween. The generated mappings may be organized into a graph that can be displayed on a user interface to allow a user to visualize the distribution of software applications 800, 802, and 804 among the nodes of computing cluster 604 … Cluster 604 may also include master node 606 configured to manage the number, distribution, and scheduling of pods, containers, and/or software applications amongst the plurality of worker nodes (e.g., worker nodes 614A and 614B) within computing cluster 604 … Software application(s) 624A and 624B may be executable within corresponding container(s) 622A and 622B, respectively. Generally, each of container(s) 622A and 622B may be configured to execute a single software application of software application(s) 624A and 624B. However, in some cases, some of container(s) 622A and 622B may also be configured to execute therein multiple software applications of software application(s) 624A and 624B … FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A. Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C. Pods 808A, 808B, and 810 (or the applications therein) do not communicate directly with one another in this example. Such visual mapping of the communicative relationships may be helpful … the web-based portals, users may design, test, and deploy applications, generate reports, view analytics, and perform other tasks … provide reports related to usage, performance,”]. Therefore, considering the teachings of Chauvet and Rimar, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add a visualization routine executing on the data cluster, the visualization routine operable to receive real-time data from one or more of the plurality of containers, or from the software defined networking controller, or from the container orchestrator and to present a graphical depiction of an operation of at least a portion of the process control system based on the received data, the graphical depiction representing at least a portion of a process control system runtime configuration of the process control system, the process control system runtime configuration having a logical configuration including a plurality of control logical elements, the graphical depiction including a depiction of a manner in which one or more of the plurality of containers is currently associated with the one or more process control logical elements and the graphical depiction further including a performance indication for at least a portion of the logical configuration, as taught by Rimar, to the teachings of Chauvet because it helps to discover and organize relationships of containerized software applications which facilitates efficient user analysis of service impacts, outages, and other potential issues in a managed network (e.g. see Rimar paragraphs 0002, 0003). Chauvet and Rimar do not specifically teach via one or more input/output elements disposed between the plurality of containers and the process control field devices, plurality of process control logical elements that together define a process control strategy that is implemented at least partially by the plurality of containers on the data cluster during runtime of the industrial process control system, or with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to process control field devices to thereby indicate a manner in which the one or more of the plurality of containers implement the process control strategy via the one or more input/output elements. However, in the same field of invention, Wouhaybi teaches: via one or more input/output elements disposed between the plurality of containers and the process control field devices [(e.g. see Wouhaybi paragraphs 0088, 0092, 0110 and Figs. 1A and 3A) ”a Control Server (CS) node 130A, Edge Control Node (ECN) systems 150. Intelligent I/O Controller systems 165, Basic I/O Controller systems 160, Gateway systems 170, and Control Stations 115. Various field devices (151, 161, 166, 171) are connected to the respective systems (150, 160, 165, 170). Some of the example use cases and configurations of this operational architecture are further discussed below … the Intelligent I/O systems 165 may include various configurable aspects of industrial control from an Intelligent I/O controller (e.g., controller 165A, 165B) and an accompanying operating system, used for control or access of various devices (e.g., field devices 166A, 166B). Also in an example, the Basic I/O systems 160 may include various operating aspects of industrial control from a Basic I/O controller (e.g., controller 160A, 160B) and an accompanying operating system, used for control or access of various devices (e.g., field devices 161A. 161B) … the configuration of FIG. 3A illustrates the operation of respective virtual machines 131B which may include different deployment types of virtual machines, containers, and applications, operating on a hypervisor layer 132B”]. plurality of process control logical elements that together define a process control strategy that is implemented at least partially by the plurality of containers on the data cluster during runtime of the industrial process control system [(e.g. see Wouhaybi paragraphs 0185, 0190, 0191 and Figs. 10 and 11) ”a distributed resource pool is defined as a combination of compute, storage, memory across networked computing assets with the addition of function block scheduling frequency, before and after processing assignments, latency tolerance for the purpose of executing application control strategies. For instance, a control strategy (or application), may be defined by a physically distributed, coordinated set of building blocks with very strict time, block-to-block scheduling, and run-time requirements for execution. The orchestration of these building blocks in time is coordinated with respect to the order of execution, processing latency and full execution cycle of all building blocks that make up the overall application control strategy … coordination of the distributed function block applications is orchestrated across all function blocks that define a specific control strategy … FIG. 11 depicts an example application distribution mapping for a control strategy of an orchestration scenario that includes four applications, where application redundancy is depicted in designs 1120 for native, virtual machine, container, and container in a virtual machine deployments. As illustrated, the orchestration of application assets may encompass different deployment options to consider for dynamic allocation of resources, subject to various compute, storage, memory, and application constraints”]. and with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to process control field devices to thereby indicate a manner in which the one or more of the plurality of containers implement the process control strategy via the one or more input/output elements [(e.g. see Wouhaybi paragraphs 0092, 0191, 0280 and Figs. 10 and 11) ”the Intelligent I/O systems 165 may include various configurable aspects of industrial control from an Intelligent I/O controller (e.g., controller 165A, 165B) and an accompanying operating system, used for control or access of various devices (e.g., field devices 166A, 166B). Also in an example, the Basic I/O systems 160 may include various operating aspects of industrial control from a Basic I/O controller (e.g., controller 160A, 160B) and an accompanying operating system, used for control or access of various devices (e.g., field devices 161A. 161B) … FIG. 11 depicts an example application distribution mapping for a control strategy of an orchestration scenario that includes four applications, where application redundancy is depicted in designs 1120 for native, virtual machine, container, and container in a virtual machine deployments. As illustrated, the orchestration of application assets may encompass different deployment options to consider for dynamic allocation of resources, subject to various compute, storage, memory, and application constraints … the control system application may be displayed and modified with use of a visual representation displayed in a graphical user interface. For instance, the visual representation may be used to establish relationships of one or more inputs or outputs to the control system application, including for inputs or outputs involving the use of one or more sensor, actuator, or controller”]. Therefore, considering the teachings of Chauvet, Rimar and Wouhaybi, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add via one or more input/output elements disposed between the plurality of containers and the process control field devices, plurality of process control logical elements that together define a process control strategy that is implemented at least partially by the plurality of containers on the data cluster during runtime of the industrial process control system, and with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to process control field devices to thereby indicate a manner in which the one or more of the plurality of containers implement the process control strategy via the one or more input/output elements, as taught by Wouhaybi, to the teachings of Chauvet and Rimar because it allows a lower cost commodity hardware and software to achieve better system performance at a control strategy level, while enabling new levels of system redundancy and failover (e.g. see Wouhaybi paragraph 0183). As for dependent claim 2, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction representing a logical configuration that visually indicates the manner in which a set of containers are nested with respect to one another [(e.g. see Rimar paragraph 0081 and Fig. 3) ”Remote network management platform 320 may include modules that integrate with third-party networks 340 to expose virtual machines and managed services therein to managed network 300. The modules may allow users to request virtual resources and provide flexible reporting for third-party networks 340 … These modules may then automatically discover the manageable resources in the account, and also provide reports related to usage, performance, and billing”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 8, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction representing an interaction between a first logical element of the logical configuration and a first physical element [(e.g. see Rimar paragraph 0146 and Fig. 9A) ” FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 9, Chauvet, Rimar and Wouhaybi teach the system as described in claim 8 and Rimar further teaches: wherein the visualization routine presents a graphical depiction that visually indicates a manner in which a first container is pinned to a first physical element [(e.g. see Rimar paragraph 0146 and Fig. 9A) ” FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 10, Chauvet, Rimar and Wouhaybi teach the system as described in claim 8 and Rimar further teaches: wherein the visualization routine presents a graphical depiction that visually indicates a manner in which a first container is dynamically associated with a first physical element, wherein the dynamic association may be changed during runtime of the industrial process control system [(e.g. see Rimar paragraph 0147, 0149 and Figs. 9A-B) ”User interface 900 may additionally include timeline 902, cursor 904 indicating a time point along the timeline 902 at which the state of computing cluster 604 is shown, and the date and time corresponding to the time point (e.g., Apr. 30, 2018 9:02 AM) … The distribution of software applications, containers, and pods across worker nodes 612A, 612B, 612C, and 612D may change from time to time as worker nodes, pods, and/or containers terminate their operation due to planned or unplanned causes”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 11, Chauvet, Rimar and Wouhaybi teach the system as described in claim 10 and Rimar further teaches: wherein the visualization routine enables a user, via user input based on the graphical depiction, to dynamically change the manner in which the first container is associated with the first physical element [(e.g. see Rimar paragraphs 0153, 0155 and Figs. 8D and 9A-B) ”A further tenth request from remote user(s) 602 may be received by front-end software application 800 executing in pod 806. Pod 806 may, in response, transmit an eleventh request to software application 802 by utilizing pod 808C, as shown in the bottom portion of FIG. 8D. In response, software application 802 executing in pod 808C may process the eleventh request and provide a corresponding response 830 … FIG. 9B shows graphical user interface 900 updated to illustrate the communicative relationships amongst components of computing cluster 604 after replacement of pod 808B with pod 808C. Notably, cursor 904 has moved towards the right and the time corresponding thereto (i.e., Apr. 30, 2018 9:15 AM) has been updated to indicate that FIG. 9B shows the state of computing cluster at a later time than FIG. 9A”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 12, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction representing an interaction between a first logical element of the logical configuration and a second logical element of the logical configuration [(e.g. see Rimar paragraph 0146 and Fig. 9A) ”FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A. Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 14, Chauvet, Rimar and Wouhaybi teach the system as described in claim 12 and Rimar further teaches: wherein the visualization routine presents a graphical depiction that visually indicates a manner in which a first container is nested within a second container [(e.g. see Rimar paragraph 0148 and Figs. 9A-B) ”a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein”]. Examiner notes that, as depicted in Figs. 9A-B, the graphical user interface shows the mapping hierarchy between pods at different time periods and the containerized software applications are nested in the pods. The motivation to combine is the same as that used for claim 1. As for dependent claim 15, Chauvet, Rimar and Wouhaybi teach the system as described in claim 12 and Rimar further teaches: wherein the visualization routine presents a graphical depiction that visually indicates a manner in which the first logical element is dynamically associated with the second logical element, wherein the dynamic association may be changed during runtime of the industrial process control system [(e.g. see Rimar paragraphs 0147, 0149 and Figs. 9A-B) ” User interface 900 may additionally include timeline 902, cursor 904 indicating a time point along the timeline 902 at which the state of computing cluster 604 is shown, and the date and time corresponding to the time point (e.g., Apr. 30, 2018 9:02 AM) … The distribution of software applications, containers, and pods across worker nodes 612A, 612B, 612C, and 612D may change from time to time as worker nodes, pods, and/or containers terminate their operation due to planned or unplanned causes”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 16, Chauvet, Rimar and Wouhaybi teach the system as described in claim 15 and Rimar further teaches: wherein the visualization routine enables a user, via user input based on the graphical depiction, to dynamically change the manner in which the first logical element is associated with the second logical element [(e.g. see Rimar paragraphs 0153, 0155 and Figs. 8D and 9A-B) ”A further tenth request from remote user(s) 602 may be received by front-end software application 800 executing in pod 806. Pod 806 may, in response, transmit an eleventh request to software application 802 by utilizing pod 808C, as shown in the bottom portion of FIG. 8D. In response, software application 802 executing in pod 808C may process the eleventh request and provide a corresponding response 830 … FIG. 9B shows graphical user interface 900 updated to illustrate the communicative relationships amongst components of computing cluster 604 after replacement of pod 808B with pod 808C. Notably, cursor 904 has moved towards the right and the time corresponding thereto (i.e., Apr. 30, 2018 9:15 AM) has been updated to indicate that FIG. 9B shows the state of computing cluster at a later time than FIG. 9A”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 17, Chauvet, Rimar and Wouhaybi teach the system as described in claim 12 and Rimar further teaches: wherein the visualization routine presents a graphical depiction representing a logical configuration that visually indicates a manner in which a first container is dynamically associated with a second container, wherein the dynamic association may be changed during runtime of the industrial process control system [(e.g. see Rimar paragraphs 0147, 0149 and Figs. 9A-B) ”User interface 900 may additionally include timeline 902, cursor 904 indicating a time point along the timeline 902 at which the state of computing cluster 604 is shown, and the date and time corresponding to the time point (e.g., Apr. 30, 2018 9:02 AM) … The distribution of software applications, containers, and pods across worker nodes 612A, 612B, 612C, and 612D may change from time to time as worker nodes, pods, and/or containers terminate their operation due to planned or unplanned causes”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 18, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction representing one or more physical elements of a physical configuration, and a performance indication indicating a performance metric of one of the one or more physical elements [(e.g. see Rimar paragraphs 0066, 0081 and Fig. 3) ”Managed network 300 may be, for example, an enterprise network used by an entity for computing and communications tasks, as well as storage of data. Thus, managed network 300 may include various client devices 302, server devices 304, routers 306, virtual machines 308, firewall 310, and/or proxy servers 312 … Remote network management platform 320 may include modules that integrate with third-party networks 340 to expose virtual machines and managed services therein to managed network 300. The modules may allow users to request virtual resources and provide flexible reporting for third-party networks 340 … These modules may then automatically discover the manageable resources in the account, and also provide reports related to usage, performance, and billing”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 19, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a performance indication indicating the health or performance measure of the physical element as determined by a routine coupled to the container orchestrator [(e.g. see Rimar paragraphs 0066, 0081 and Fig. 3) ”Managed network 300 may be, for example, an enterprise network used by an entity for computing and communications tasks, as well as storage of data. Thus, managed network 300 may include various client devices 302, server devices 304, routers 306, virtual machines 308, firewall 310, and/or proxy servers 312 … Remote network management platform 320 may include modules that integrate with third-party networks 340 to expose virtual machines and managed services therein to managed network 300. The modules may allow users to request virtual resources and provide flexible reporting for third-party networks 340 … These modules may then automatically discover the manageable resources in the account, and also provide reports related to usage, performance, and billing”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 20, Chauvet, Rimar and Wouhaybi teach the system as described in claim 19 and Chauvet further teaches: wherein the physical element is a computer device or a communication connection [(e.g. see Chauvet paragraph 0210) ”a compute resource can be a server machine, a personal computer, an embedded hardware, a human machine interface (HMI) module or an industrial controller”]. As for dependent claim 22, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a performance indication indicating one or more of: a messaging speed, a storage utilization, a network bandwidth, an error rate, an assigned physical node, a message diagnostic, an error condition, a physical network adapter, a CPU loading, or a temperature [(e.g. see Rimar paragraph 0067 and Fig. 3) ”virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to individual virtual machines, as well as performance and error reporting”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 23, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including an identification of one or more containers executing on one or more computing nodes [(e.g. see Rimar paragraph 0146 and Figs. 9A-B) ”Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C”]. Examiner notes that, as depicted in Figs. 9A-B, the user interfaces display that the pods (and thus containers and applications) execute on worker nodes. The motivation to combine is the same as that used for claim 1. As for dependent claim 24, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including a health status of each of a plurality of computing nodes [(e.g. see Rimar paragraphs 0090, 0104 and Fig. 3) ”In order for remote network management platform 320 to administer the devices, applications, and services of managed network 300, remote network management platform 320 may first determine what devices are present in managed network 300, the configurations and operational statuses of these devices, and the applications and services provided by the devices, and well as the relationships between discovered devices, applications, and services … This collected information may be presented to a user in various ways to allow the user to view the hardware composition and operational status of devices, as well as the characteristics of services that span multiple devices and applications”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 26, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including a physical view of one or more servers and a physical resource management routine [(e.g. see Rimar paragraphs 0067 and Fig. 9A) ”One physical computing system, such as server cluster 200, may support up to thousands of individual virtual machines. In some embodiments, virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to individual virtual machines”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 29, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including a configuration hierarchy indicating a current operation of the process control system including relationships between one or more physical elements and logical elements of the process control system [(e.g. see Rimar paragraph 0146 and Fig. 9A) ”FIG. 9A illustrates graphical user interface 900 that shows the mapping between pods 806, 808A, 808B, and 810. Namely, FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A. Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 30, Chauvet, Rimar and Wouhaybi teach the system as described in claim 29 and Rimar further teaches: wherein the hierarchy illustrates a manner in which one or more logical elements are nested in or pinned to other logical elements [(e.g. see Rimar paragraph 0148 and Fig. 9A-B) ”a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein”]. Examiner notes that, as depicted in Figs. 9A-B, the user interface shows the mapping hierarchy between pods at different time periods and the containerized software applications are nested in the pods. The motivation to combine is the same as that used for claim 1. As for dependent claim 31, Chauvet, Rimar and Wouhaybi teach the system as described in claim 29 and Rimar further teaches: wherein the hierarchy illustrates a manner in which one or more logical elements are currently pinned to one or more physical elements [(e.g. see Rimar paragraph 0146 and Fig. 9A) ”FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 32, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including a depiction of a relationship between a set of logical elements and a set of physical elements of the process control system [(e.g. see Rimar paragraphs 0129, 0146 and Figs. 9A-B) ”data indicative of the communicative relationships between the worker nodes, pods, containers, software applications, and/or other components of the container orchestration engine executing on computing cluster 604 … FIG. 9A illustrates graphical user interface 900 that shows the mapping between pods 806, 808A, 808B, and 810. Namely, FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A. Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C”]. Examiner notes that, as depicted in Figs. 9A-B, the logical and physical relationship is shown by the worker nodes (e.g. physical) of the computing cluster and the location of the pods containing the software applications (e.g. logical). The motivation to combine is the same as that used for claim 1. As for dependent claim 33, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including a depiction of a relationship between a set of logical elements and an indication of the physical elements on which one or more of the logical elements are currently being executed [(e.g. see Rimar paragraphs 0116, 0129, 0146 and Figs. 9A-B) ”Cluster 604 may also include master node 606 configured to manage the number, distribution, and scheduling of pods, containers, and/or software applications amongst the plurality of worker nodes (e.g., worker nodes 614A and 614B) within computing cluster 604 … data indicative of the communicative relationships between the worker nodes, pods, containers, software applications, and/or other components of the container orchestration engine executing on computing cluster 604 … FIG. 9A illustrates graphical user interface 900 that shows the mapping between pods 806, 808A, 808B, and 810. Namely, FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A. Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C”]. Examiner notes that, as depicted in Figs. 9A-B, the logical and physical relationship is shown by the worker nodes (e.g. physical) of the computing cluster and the location of the pods containing the software applications (e.g. logical). The motivation to combine is the same as that used for claim 1. As for dependent claim 34, Chauvet, Rimar and Wouhaybi teach the system as described in claim 33 and Rimar further teaches: wherein the relationship indicates a manner in which the logical elements are nested within each other [(e.g. see Rimar paragraph 0148 and Figs. 9A-B) ”a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein”]. Examiner notes that, as depicted in Figs. 9A-B, the user interface shows the mapping hierarchy between pods at different times and the containerized software applications are nested in the pods. The motivation to combine is the same as that used for claim 1. As for dependent claim 35, Chauvet, Rimar and Wouhaybi teach the system as described in claim 33 and Rimar further teaches: wherein the visualization routine presents a graphical depiction further including a performance indication for one or more of the logical elements [(e.g. see Rimar paragraph 0081 and Fig. 3) ”Remote network management platform 320 may include modules that integrate with third-party networks 340 to expose virtual machines and managed services therein to managed network 300. The modules may allow users to request virtual resources and provide flexible reporting for third-party networks 340 … These modules may then automatically discover the manageable resources in the account, and also provide reports related to usage, performance, and billing”]. The motivation to combine is the same as that used for claim 1. As for dependent claim 36, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including a depiction of a set of physical elements and an indication of one or more logical elements being implemented by the one or more physical elements [(e.g. see Rimar paragraphs 0116, 0129, 0146 and Figs. 9A-B) ”Cluster 604 may also include master node 606 configured to manage the number, distribution, and scheduling of pods, containers, and/or software applications amongst the plurality of worker nodes (e.g., worker nodes 614A and 614B) within computing cluster 604 … data indicative of the communicative relationships between the worker nodes, pods, containers, software applications, and/or other components of the container orchestration engine executing on computing cluster 604 … FIG. 9A illustrates graphical user interface 900 that shows the mapping between pods 806, 808A, 808B, and 810. Namely, FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A. Pod 806, in turn, communicates with software application 802, executing in pods 808A and 808B on worker nodes 612B and 612D, respectively, and with software application 804 executing in pod 810 on worker node 612C”]. Examiner notes that, as depicted in Figs. 9A-B, the logical and physical relationship is shown by the worker nodes (e.g. physical) of the computing cluster and the location of the pods containing the software applications (e.g. logical). The motivation to combine is the same as that used for claim 1. As for dependent claim 37, Chauvet, Rimar and Wouhaybi teach the system as described in claim 36 and Rimar further teaches: wherein the visualization routine presents a graphical depiction further including a performance indication for one or more of the physical elements [(e.g. see Rimar paragraphs 0066, 0081 and Fig. 3) ”Managed network 300 may be, for example, an enterprise network used by an entity for computing and communications tasks, as well as storage of data. Thus, managed network 300 may include various client devices 302, server devices 304, routers 306, virtual machines 308, firewall 310, and/or proxy servers 312 … Remote network management platform 320 may include modules that integrate with third-party networks 340 to expose virtual machines and managed services therein to managed network 300. The modules may allow users to request virtual resources and provide flexible reporting for third-party networks 340 … These modules may then automatically discover the manageable resources in the account, and also provide reports related to usage, performance, and billing”]. The motivation to combine is the same as that used for claim 1. As for independent claim 38, Chauvet, Rimar and Wouhaybi teach a method. Claim 38 discloses substantially the same limitations as claim 1. Therefore, it is rejected with the same rational as claim 1. As for dependent claim 39, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 39 discloses substantially the same limitations as claim 8. Therefore, it is rejected with the same rational as claim 8. As for dependent claim 40, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 40 discloses substantially the same limitations as claim 9. Therefore, it is rejected with the same rational as claim 9. As for dependent claim 41, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 41 discloses substantially the same limitations as claim 2. Therefore, it is rejected with the same rational as claim 2. As for dependent claim 45, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 45 discloses substantially the same limitations as claim 10. Therefore, it is rejected with the same rational as claim 10. As for dependent claim 46, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 46 discloses substantially the same limitations as claim 11. Therefore, it is rejected with the same rational as claim 11. As for dependent claim 47, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 47 discloses substantially the same limitations as claim 18. Therefore, it is rejected with the same rational as claim 18. As for dependent claim 48, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 48 discloses substantially the same limitations as claim 19. Therefore, it is rejected with the same rational as claim 19. As for dependent claim 49, Chauvet, Rimar and Wouhaybi teach the method as described in claim 48; further, claim 49 discloses substantially the same limitations as claim 20. Therefore, it is rejected with the same rational as claim 20. As for dependent claim 50, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 50 discloses substantially the same limitations as claim 23. Therefore, it is rejected with the same rational as claim 23. As for dependent claim 53, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 53 discloses substantially the same limitations as claim 29. Therefore, it is rejected with the same rational as claim 29. As for dependent claim 54, Chauvet, Rimar and Wouhaybi teach the method as described in claim 53; further, claim 54 discloses substantially the same limitations as claim 30. Therefore, it is rejected with the same rational as claim 30. As for dependent claim 55, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 55 discloses substantially the same limitations as claim 31. Therefore, it is rejected with the same rational as claim 31. As for dependent claim 56, Chauvet, Rimar and Wouhaybi teach the method as described in claim 55; further, claim 56 discloses substantially the same limitations as claim 15. Therefore, it is rejected with the same rational as claim 15. As for dependent claim 57, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 57 discloses substantially the same limitations as claim 17. Therefore, it is rejected with the same rational as claim 17. As for dependent claim 58, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 58 discloses substantially the same limitations as claim 33. Therefore, it is rejected with the same rational as claim 33. As for independent claim 59, Chauvet, Rimar and Wouhaybi teach a method. Claim 59 discloses substantially the same limitations as claim 1. Therefore, it is rejected with the same rational as claim 1. Further, Rimar teaches a physical configuration associated with the runtime configuration of one or more physical elements within the process control system [(e.g. see Rimar paragraphs 0081, 0111, 0113, 0116, 0129, 0145, 0146 and Figs. 9A-B)]. Examiner notes that, as depicted in Figs. 9A-B, the logical and physical configuration is shown by the worker nodes (e.g. physical) of the computing cluster and the location of the pods containing the software applications (e.g. logical). As for dependent claim 60, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 60 discloses substantially the same limitations as claim 18. Therefore, it is rejected with the same rational as claim 18. As for dependent claim 61, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 61 discloses substantially the same limitations as claim 8. Therefore, it is rejected with the same rational as claim 8. As for dependent claim 62, Chauvet, Rimar and Wouhaybi teach the method as described in claim 61; further, claim 62 discloses substantially the same limitations as claim 9. Therefore, it is rejected with the same rational as claim 9. As for dependent claim 63, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 63 discloses substantially the same limitations as claim 2. Therefore, it is rejected with the same rational as claim 2. As for dependent claim 67, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 67 discloses substantially the same limitations as claim 10. Therefore, it is rejected with the same rational as claim 10. As for dependent claim 68, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 68 discloses substantially the same limitations as claim 11. Therefore, it is rejected with the same rational as claim 11. As for dependent claim 69, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 69 discloses substantially the same limitations as claim 18. Therefore, it is rejected with the same rational as claim 18. As for dependent claim 70, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 70 discloses substantially the same limitations as claim 19. Therefore, it is rejected with the same rational as claim 19. As for dependent claim 71, Chauvet, Rimar and Wouhaybi teach the method as described in claim 70; further, claim 71 discloses substantially the same limitations as claim 20. Therefore, it is rejected with the same rational as claim 20. As for dependent claim 72, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 72 discloses substantially the same limitations as claim 23. Therefore, it is rejected with the same rational as claim 23. As for dependent claim 75, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 75 discloses substantially the same limitations as claim 29. Therefore, it is rejected with the same rational as claim 29. As for dependent claim 76, Chauvet, Rimar and Wouhaybi teach the method as described in claim 75; further, claim 76 discloses substantially the same limitations as claim 30. Therefore, it is rejected with the same rational as claim 30. As for dependent claim 77, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 77 discloses substantially the same limitations as claim 31. Therefore, it is rejected with the same rational as claim 31. As for dependent claim 78, Chauvet, Rimar and Wouhaybi teach the method as described in claim 77; further, claim 78 discloses substantially the same limitations as claim 15. Therefore, it is rejected with the same rational as claim 15. As for dependent claim 79, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 79 discloses substantially the same limitations as claim 17. Therefore, it is rejected with the same rational as claim 17. As for dependent claim 80, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 80 discloses substantially the same limitations as claim 33. Therefore, it is rejected with the same rational as claim 33. Claims 3-6, 25, 42-44 and 64-66 are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 2018/0316729 A1) in view of Rimar et al. (US 2019/0379590 A1) and further in view of Wouhaybi et al. (US 2020/0310394 A1), as applied to claim 1 above, and further in view of Resurreccion et al. (US 2012/0259436 A1). As for dependent claim 3, Chauvet, Rimar and Wouhaybi teach the system as described in claim 2, but do not specifically teach wherein the set of nested containers includes a control container and an I/O server container nested within a subsystem container. However, in the same field of invention, Resurreccion teaches: wherein the set of nested containers includes a control container and an I/O server container nested within a subsystem container [(e.g. see Resurreccion paragraphs 0017, 0075 and Fig. 3) ”the example in FIG. 3 shows that logical containers may be nested to enable process control personnel to further organize process control resources … My Device Watch List logical container 306 includes a Hart Devices logical container 318 and a Foundation Fieldbus (FF) devices logical container 320. The logical containers 318 and 320 enable process control personnel to organize process control resources by a communication protocol type within the My Device Watch List logical container 306 … The field devices, controllers, I/O cards, servers, computers, processors, groups of devices, documents, process control personnel, and/or other components are referred to herein as process control resources”]. Therefore, considering the teachings of Chauvet, Rimar, Wouhaybi and Resurreccion, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the set of nested containers includes a control container and an I/O server container nested within a subsystem container, as taught by Resurreccion, to the teachings of Chauvet, Rimar and Wouhaybi because it allows process control personnel to manage resources more effectively by creating customizable logical containers (e.g. see Resurreccion paragraph 0021). As for dependent claim 4, Chauvet, Rimar, Wouhaybi and Resurreccion teach the system as described in claim 3 and Resurreccion further teaches: wherein the set of nested containers further includes a further container nested with respect to the control container, the I/O server container and the subsystem container [(e.g. see Resurreccion paragraph 0050 and Figs. 2-3) ”The example container manager 204 also enables process control personnel to create logical containers. To create a logical container, the container manager 204 prompts process control personnel, via the workstation interface 202, for a name of the container, an identifier for the container, a characteristic of the container, and/or a directory location for the container. The directory location may indicate if the logical container is to be nested within another logical container or may indicate if the logical container is to be included within a relatively high level structure within, for example, an asset management tool”]. The motivation to combine is the same as that used for claim 3. As for dependent claim 5, Chauvet, Rimar, Wouhaybi and Resurreccion teach the system as described in claim 4 and Resurreccion further teaches: wherein the further container is one of a data collection container, a data processing container, a third party container, and a performance index container [(e.g. see Resurreccion paragraph 0051 and Figs. 2-3) ”A characteristic selected by process control personnel may be any feature, function, location, and/or property of a process control resource including for example, a fault type, a history of common issues, a type of resource, a physical location, a user preference, a manufacturer, a calibration date, an installation date, and/or a communication type. In some instances, process control personnel may create a logical container with a common characteristic of process control resources assigned to the personnel or, alternatively, resources of interest to the personnel. In this manner, the example container manager 204 enables process control personnel to organize process control resources based on preferences separate or distinct from how the resources are provisioned and/or communicatively coupled”]. The motivation to combine is the same as that used for claim 3. As for dependent claim 6, Chauvet, Rimar and Wouhaybi teach the system as described in claim 2, but do not specifically teach the following limitation. However, Resurreccion teaches: wherein the graphical depiction visually indicates whether the containers within the set of containers are statically or are dynamically nested with respect to one another [(e.g. see Resurreccion paragraph 0050 and Figs. 2-3) ”The example container manager 204 also enables process control personnel to create logical containers. To create a logical container, the container manager 204 prompts process control personnel, via the workstation interface 202, for a name of the container, an identifier for the container, a characteristic of the container, and/or a directory location for the container. The directory location may indicate if the logical container is to be nested within another logical container or may indicate if the logical container is to be included within a relatively high level structure within, for example, an asset management tool”]. The motivation to combine is the same as that used for claim 3. As for dependent claim 25, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1, but do not specifically teach the following limitation. However, Resurreccion teaches: wherein the visualization routine presents a graphical depiction of a logical view of one or more controllers and an I/O sub-system of the process control system [(e.g. see Resurreccion paragraphs 0017, 0050) ”The field devices, controllers, I/O cards, servers, computers, processors, groups of devices, documents, process control personnel, and/or other components are referred to herein as process control resources … The example container manager 204 also enables process control personnel to create logical containers. To create a logical container, the container manager 204 prompts process control personnel, via the workstation interface 202, for a name of the container, an identifier for the container, a characteristic of the container, and/or a directory location for the container. The directory location may indicate if the logical container is to be nested within another logical container or may indicate if the logical container is to be included within a relatively high level structure within, for example, an asset management tool”]. The motivation to combine is the same as that used for claim 3. As for dependent claim 42, Chauvet, Rimar and Wouhaybi teach the method as described in claim 41; further, claim 42 discloses substantially the same limitations as claim 3. Therefore, it is rejected with the same rational as claim 3. As for dependent claim 43, Chauvet, Rimar and Wouhaybi teach the method as described in claim 41; further, claim 43 discloses substantially the same limitations as claim 3. Therefore, it is rejected with the same rational as claim 3. As for dependent claim 44, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 44 discloses substantially the same limitations as claim 6. Therefore, it is rejected with the same rational as claim 6. As for dependent claim 64, Chauvet, Rimar and Wouhaybi teach the method as described in claim 63; further, claim 64 discloses substantially the same limitations as claim 3. Therefore, it is rejected with the same rational as claim 3. As for dependent claim 65, Chauvet, Rimar and Wouhaybi teach the method as described in claim 63; further, claim 65 discloses substantially the same limitations as claim 3. Therefore, it is rejected with the same rational as claim 3. As for dependent claim 66, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 66 discloses substantially the same limitations as claim 6. Therefore, it is rejected with the same rational as claim 6. Claims 7 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 2018/0316729 A1) in view of Rimar et al. (US 2019/0379590 A1) and further in view of Wouhaybi et al. (US 2020/0310394 A1), as applied to claim 1 above, and further in view of Jangam et al. (US 11,451,447 B1). As for dependent claim 7, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1, but do not specifically teach wherein the visualization routine presents a graphical depiction representing a logical configuration that visually indicates the manner in which a first container is pinned to a second container. However, in the same field of invention, Jangam teaches: wherein the visualization routine presents a graphical depiction representing a logical configuration that visually indicates the manner in which a first container is pinned to a second container [(e.g. see Jangam col 7 line 62 – col 8 lines 57 and Figs. 2B-C) ”FIG. 2B depicts a network topology for a data center including a variety of physical and virtual components after selection of a component … Upon receiving this selection, in the illustrated embodiment, the Network Topology 200B is revised and output to depict all of the Containers 115B in the cluster … a single container in the VM Cluster 230 has been selected. As illustrated, in response to this selection, the Network Topology 200C has been updated to include Information 235 about the selected container. In the illustrated embodiment, this Information 235 includes the name of the container, a name of the host where the pod/collection of containers is executing (which may be a virtual machine or a bare metal cluster, in one embodiment), an identifier of the container, the host IP for the container, the pod IP for the container”]. Therefore, considering the teachings of Chauvet, Rimar, Wouhaybi and Jangam, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the visualization routine presents a graphical depiction representing a logical configuration that visually indicates the manner in which a first container is pinned to a second container, as taught by Jangam, to the teachings of Chauvet, Rimar and Wouhaybi because it assists the user in viewing the topology of the complex ever-changing data center with physical and virtualized components (e.g. see Jangam col 1 lines 48-67). As for dependent claim 13, Chauvet, Rimar and Wouhaybi teach the system as described in claim 12, but do not specifically teach the following limitation. However, Jangam teaches: wherein the visualization routine presents a graphical depiction that visually indicates a manner in which a first container is pinned to a second container [(e.g. see Jangam col 7 line 62 – col 8 lines 57 and Figs. 2B-C) ”FIG. 2B depicts a network topology for a data center including a variety of physical and virtual components after selection of a component … Upon receiving this selection, in the illustrated embodiment, the Network Topology 200B is revised and output to depict all of the Containers 115B in the cluster … a single container in the VM Cluster 230 has been selected. As illustrated, in response to this selection, the Network Topology 200C has been updated to include Information 235 about the selected container. In the illustrated embodiment, this Information 235 includes the name of the container, a name of the host where the pod/collection of containers is executing (which may be a virtual machine or a bare metal cluster, in one embodiment), an identifier of the container, the host IP for the container, the pod IP for the container”]. The motivation to combine is the same as that used for claim 7. Claims 21, 27, 28, 51, 52, 73 and 74 are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 2018/0316729 A1) in view of Rimar et al. (US 2019/0379590 A1) and further in view of Wouhaybi et al. (US 2020/0310394 A1), as applied to claim 1 above, and further in view of Law et al. (US 2018/0114414 A1). As for dependent claim 21, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1, but do not specifically teach wherein the visualization routine presents a performance indication indicating a health or performance measure using one or more colors. However, in the same field of invention, Law teaches: wherein the visualization routine presents a performance indication indicating a health or performance measure using one or more colors [(e.g. see Law paragraph 0051) ”a reference to a primary plant display 134, a reference to a primary faceplate display 136, and various alarm handling and viewing parameter values 138, which may include, for example, alarm priority characteristics, alarm suppression characteristics, alarm display characteristics such as fonts, sizes, colors, icons, etc., that will be applied to or used for each of the alarms within the alarm group when viewing or interacting with the alarm”]. Therefore, considering the teachings of Chauvet, Rimar, Wouhaybi and Law, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the visualization routine presents a performance indication indicating a health or performance measure using one or more colors, as taught by Law, to the teachings of Chauvet, Rimar and Wouhaybi because it provides an efficient and flexible alarm handling and viewing system (e.g. see Law paragraph 0014). As for dependent claim 27, Chauvet, Rimar and Wouhaybi teach the system as described in claim 1, but do not specifically teach the following limitation. However, Law teaches: wherein the visualization routine presents a graphical depiction including a view of interactions between a set of process control field devices, at least a portion of an I/O subsystem, and one or more containers, depicting data flows between each of the process control field devices and the one or more containers via the portion of the I/O subsystem [(e.g. see Law paragraphs 0042, 0043, 0076 and Figs. 1-2) ” The plant display 97 may be based on a PI&D diagram and may depict various icons or other representations of devices such as valves, tanks, transmitters (e.g., sensors) as interconnected within the plant 5, and may depict various important parameters and values such as device tags or names, control system references or logic, measured process parameter values, etc. … The plant display view 96 may also or instead include one or more faceplate displays 98 for various devices (such as controllers, I/O devices, field devices, etc.), modules (such as control or safety system modules) or other containers within the plant 5. Faceplate displays generally provide some information about a device and/or a module, such as a standard icon for the device or module, a tag, a name, a description, a manufacturer, a device type, one or more values for significant parameters associated with the device or module, etc … Generally speaking, a container may be a physical device, such as a field device, an I/Odevice, etc., or a logical module executed on a processor, such as a process control module, a safety system logic module, etc., or any other entity that generates an alarm … each node or device in the plant 200 may store a module list 234 including a list of modules, devices, and other components of the plant 200 and the communication paths or details needed to communicate with each of the modules, devices, or other components of the plant 200. The lists 234 (shown as being stored in the device 202 of FIG. 9) may be expanded in this case to include the alarm group tag names and communication paths for the alarm group elements defined in the system for any of the modules or other containers (either as sub-components of the modules or other containers, or as separate modules)”]. The motivation to combine is the same as that used for claim 21. As for dependent claim 28, Chauvet, Rimar, Wouhaybi and Law teach the system as described in claim 27 and Rimar further teaches: wherein the visualization routine presents a graphical depiction including one or more performance or health measures for one or more of the containers, process control field devices, or the portion of the I/O subsystem [(e.g. see Rimar paragraphs 0066, 0081 and Fig. 3) ”Managed network 300 may be, for example, an enterprise network used by an entity for computing and communications tasks, as well as storage of data. Thus, managed network 300 may include various client devices 302, server devices 304, routers 306, virtual machines 308, firewall 310, and/or proxy servers 312 … Remote network management platform 320 may include modules that integrate with third-party networks 340 to expose virtual machines and managed services therein to managed network 300. The modules may allow users to request virtual resources and provide flexible reporting for third-party networks 340 … These modules may then automatically discover the manageable resources in the account, and also provide reports related to usage, performance, and billing”]. The motivation to combine is the same as that used for claim 21. As for dependent claim 51, Chauvet, Rimar and Wouhaybi teach the method as described in claim 38; further, claim 51 discloses substantially the same limitations as claim 27. Therefore, it is rejected with the same rational as claim 27. As for dependent claim 52, Chauvet, Rimar, Wouhaybi and Law teach the method as described in claim 51; further, claim 52 discloses substantially the same limitations as claim 28. Therefore, it is rejected with the same rational as claim 28. As for dependent claim 73, Chauvet, Rimar and Wouhaybi teach the method as described in claim 59; further, claim 73 discloses substantially the same limitations as claim 27. Therefore, it is rejected with the same rational as claim 27. As for dependent claim 74, Chauvet, Rimar, Wouhaybi and Law teach the method as described in claim 73; further, claim 74 discloses substantially the same limitations as claim 28. Therefore, it is rejected with the same rational as claim 28. Response to Arguments Applicant's arguments, filed 29 January 2026, have been fully considered but they are not persuasive. Applicant argues that [“None of Chauvet or Rimar or Wouhaybi discloses or suggests the claimed visualization routine which provides a graphical depiction illustrating logical configuration elements or, more particularly, which illustrates a manner in which one or more of a plurality of containers is associated logical configuration elements of a process control strategy, including illustrating the I/O elements used to connect the containers with the field devices in a plant, to thereby indicate the manner in which the one or more of the plurality of containers implement the process control strategy via I/O elements … Wouhaybi does not disclose creating a graphical user interface or a visualization ” (Pages 18 and 19).]. Examiner respectfully disagrees. Both Rimar and Wouhaybi teach graphical user interfaces/visualizations. Rimar provides a graphical interface showing the mappings between containerized software applications (e.g. see Figs 9A-B). Wouhaybi shows displaying the relationship of applications, I/O, and devices and further depicts a process control strategy for a control application (e.g. see Wouhaybi paragraph 0280 and Fig. 11) [“the control system application may be displayed and modified with use of a visual representation displayed in a graphical user interface. For instance, the visual representation may be used to establish relationships of one or more inputs or outputs to the control system application, including for inputs or outputs involving the use of one or more sensor, actuator, or controller”]. One of ordinary skill in the art, namely a software developer, would recognize that the mappings between applications, containers, inputs/outputs, and field devices (e.g. sensors/actuators) can all be presented to an operator. Thus, the combination adequately teaches applicant’s claimed limitation. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. PGPub 2024/0004688 A1 issued to Shigemori on 04 January 2024. The subject matter disclosed therein is pertinent to that of claims 1-20 (e.g. I/O devices between containers and field devices). Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER J FIBBI whose telephone number is (571)-270-3358. The examiner can normally be reached Monday - Thursday (8am-6pm). 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, William Bashore can be reached at (571)-272-4088. 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. /CHRISTOPHER J FIBBI/Primary Examiner, Art Unit 2174
Read full office action

Prosecution Timeline

Jun 09, 2022
Application Filed
Jun 13, 2025
Non-Final Rejection — §103, §DP
Sep 17, 2025
Response Filed
Oct 28, 2025
Final Rejection — §103, §DP
Jan 29, 2026
Request for Continued Examination
Feb 06, 2026
Response after Non-Final Action
Feb 12, 2026
Non-Final Rejection — §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585866
AUTOMATED ENTRY OF EXTRACTED DATA AND VERIFICATION OF ACCURACY OF ENTERED DATA THROUGH A GRAPHICAL USER INTERFACE
2y 5m to grant Granted Mar 24, 2026
Patent 12561152
METHODS AND SYSTEMS FOR ADAPTIVE CONFIGURATION
2y 5m to grant Granted Feb 24, 2026
Patent 12535930
INTEROPERABILITY FOR TRANSLATING AND TRAVERSING 3D EXPERIENCES IN AN ACCESSIBILITY ENVIRONMENT
2y 5m to grant Granted Jan 27, 2026
Patent 12535941
USER INTERFACE FOR MANAGING INPUT TECHNIQUES
2y 5m to grant Granted Jan 27, 2026
Patent 12519999
Location Based Playback System Control
2y 5m to grant Granted Jan 06, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
53%
Grant Probability
90%
With Interview (+37.6%)
4y 3m
Median Time to Grant
High
PTA Risk
Based on 376 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month