DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 12/23/2025. Claims 1-45 are pending in this application.
Priority
This application claims priority of 63/211,535, filed 06/16/2021. The assignee of record is FISHER-ROSEMOUNT SYSTEMS, INC. The listed inventor(s) is/are: Amaro, Anthony Jr.; Nixon, Mark J.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/23/2025 has been entered.
Response to Arguments
Applicant’s arguments filed 12/23/2025 have been fully considered but they are not persuasive. Applicant argues:
a.
Applicant states that “None of Chauvet or Rimar or Wouhaybi discloses or suggests the claimed visualization routine which provides a graphical depiction illustrating both physical and logical configuration elements or, more particularly, which illustrates a manner in which one or more of a plurality of containers is associated with both the physical and 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 (Reply, p. 13).”
a.
Examiner respectfully disagrees. Rimar exemplifies graphical user interfaces illustrating the distribution and communicative relationships of the containers with both physical configuration elements (e.g. worker nodes) and logical configuration elements (e.g. containerized software applications in respective pods) in FIG. 9A , FIG. 9B, ¶ 0145 and ¶ 0146. Wouhaybi further depicts the coordination of the function block applications (including containerized applications) being orchestrated to define a process control strategy using a graphical environment as exemplified in FIG. 11. Wouhaybi also depicts the input/output elements/points/flow connecting the containerized applications with the field devices (e.g. sensors, actuators, flow valve) in FIG. 11 and FIG. 26.
Taking into account the meaning of the words in their ordinary usage as they would be understood by one of ordinary skill in the art, Examiner would like to respectfully point out that the “thereby” language, which is recited in the independent claims 1 and 23 and in the above arguments, appears to be reciting an intended result of the visualization, and would appear to have questionable weight for the claimed subject matter. Further, the term “indicate” would only provide enough information to at least hint at the information, which is different than directly providing or specifying the information. The broader scope of the claimed subject matter based on the two terms are considered in the examination.
b.
Applicant states that “In particular, while Wouhaybi apparently discloses a system that implements a process control strategy having both physical and logical elements, Wouhaybi does not disclose creating a graphical user interface or visualization that depicts how a set of containers that is implementing a process control strategy is tied to or associated with both physical and logical elements … Fig. 11 and the disclosure related thereto is not, in any manner, a depiction of or a description of a graphical visualization to be presented to a user of the system at any time. Fig. 11 is not provided as an example visualization to be presented to a user but is, instead, intended to be an aid in describing the orchestration element actually being disclosed in the patent document. Neither Fig. 11 and the description related thereto, nor any other part of Wouhaybi discloses or suggests executing a visualization routine on the data cluster to receive real-time data from at least one of the plurality of containers or the orchestrator or any other element that indicates the particular manner in which one or more containers is currently configured to implement a control strategy using both physical and logical control elements. (Reply, pp. 13-14).” Applicant further states that “Moreover, as noted in the response to the Non-Final Action dated July 18, 2025, Rimar fails to disclose providing a graphical visualization that indicates a manner in which containers are associated with both a physical device and with one or more logical process control configuration elements that define a process control strategy to thereby indicate the manner in which the containers implement the process control strategy. Thus, the Examiner's combination of Wouhaybi with Rimar requires a person of ordinary skill to add specific visualization elements to the Rimar system, without any suggestion or motivation to do so in either of Rimar or Wouhaybi. That is, the fact the Wouhaybi system uses containers to implement a process control strategy having both physical and logical elements does not provide a disclosure of or any motivation for tracking the manner in which the system implements these connections and, importantly, providing a graphical visualization to illustrate the current manner that the system executes containers to implement a process control strategy having both physical and logical elements (Reply, pp. 14-15).”
b.
Examiner respectfully disagrees. The previous Office Actions explicitly state that Rimar teaches “executing a visualization routine on the data cluster to receive real-time data from at least one of the plurality of containers, or from the software defined networking controller, or from the container orchestrator,” Wouhaybi is not incorporated to teach this part of limitations. Wouhaybi is incorporated to disclose that a GUI may be presented to a process engineer (or other operator) to define process control flows and applications using functional blocks that bear application logic or control loops, generate an orchestration plan and map the plan to available compute and communication resources for deployment (Wouhaybi, FIG. 9, ¶ 0170 - ¶ 0172). FIG. 11 of Wouhaybi depicts an example application distribution mapping for a control strategy of an orchestration scenario, in which the containerized applications (i.e. the logical elements) are depicted to be deployed on computing nodes A+1 … B (i.e. the physical devices) to reflect the runtime relationships of the containers, the logical elements and the physical elements (Wouhaybi, FIG. 11, ¶ 0191 - ¶ 0192). Therefore, Wouhaybi augments the visualization of Rimar by presenting the process control strategy using containers being associated with physical devices and logical elements in a graphical environment.
c.
Applicant further states that “Even if Fig. 11 of Wouhaybi was considered to be a disclosure of a graphical visualization (which it is not), neither Fig. 11 nor the specification associated therewith illustrates or describes input/output elements that connect containers to one or more field devices (Reply, p. 15).”
c.
Examiner respectfully disagrees. Wouhaybi exemplifies the visualization of the process control strategies by using containerized applications in FIG. 11 and FIG. 26 and also discloses that the input/output elements/points/flow associate the containerized control applications with the field devices (i.e. sensors, actuators, flow valve) (Wouhaybi, FIG. 11, FIG. 26, ¶ 0191, ¶ 0250).
Based on the above responses, the incorporation of Chauvet, Rimar and Wouhaybi is considered to continue to teach the amended independent claims 1 and 23.
Response to Amendment
The claim objection to claim 1 is now withdrawn in view of the claim amendments.
The claim rejections under 35 U.S.C. 112(b) to claims 1-45 are now withdrawn in view of the claim amendments.
The claim rejections under Double Patenting remain. See details as follows.
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-45 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over the claims 1-9, 11-30, 32-51 of co-pending Application No. 17/838,798 (hereinafter ’798), in view of Chauvet et al. (US 20180316729 A1, published 11/01/2018; hereinafter Chauvet), in view of Rimar et al. (US 20190379590 A1, published 12/12/2019; hereinafter Rimar, and in further view of Wouhaybi et al. (US 20200310394 A1, published 10/01/2020; hereinafter Wouhaybi).
Although the claims at issue are not identical, they are not patentably distinct from each other because the claimed limitations recited in the instant application are transparently found in the listed co-pending application with obvious wording variations. Specifically, co-pending application ’798 does not teach “communicatively coupling the plurality of containers with a software defined networking controller that communicatively couples the plurality of containers to the plurality of process control field devices operating to control a physical process in the industrial process plant via one or more input/output elements disposed between the plurality of containers and the process control field devices.” However, Chauvet teaches communicatively coupling containers with a network controller (Chauvet, ¶ 0095) and connecting the containerized applications with field devices via external interfaces (Chauvet, ¶ 0111). It would have been obvious to one of ordinary skill in the art to use the software defined network controller of Chauvet with the system of ’798 to “disseminate network policies throughout the network infrastructure … to control connectivity, bandwidth and latency, Service Level Agreements …, traffic flow control, etc.” (Chauvet ¶ 0090). Also, co-pending application ’798 does not teach “the graphical depiction including an indication of a manner in which one or more of the plurality of containers is currently associated with the one or more physical devices and with one or more of the plurality of process control logical elements.” However, Rimar discloses the relationship manner between the containers and the software applications, as well as the relationship manner between the containers and the worker nodes in the computing cluster in a GUI (Rimar, ¶ 0113, ¶ 0116, ¶ 0145, ¶ 0146 and FIGS 9A, 9B). It would have been obvious to one of ordinary skill in the art to use the visualization techniques of Rimar with the system of ’798 to discover and logically organize representations and relationships of the containerized software applications (Rimar ¶ 0002) and generate service mapping to facilitate analysis of service impacts, help locate outages, and identify other potential issues in a managed network (Rimar, ¶ 0003). Further on, co-pending application ’798 does not teach a plurality of process control logical elements “that together define a process control strategy” and one or more of the plurality of containers is also currently associated “with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to the 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, Wouhaybi discloses that the coordination of the function block applications is orchestrated to define a control strategy, the containers facilitate the control strategy of the application orchestration (Wouhaybi, ¶ 0170, ¶ 0185, ¶ 0190, ¶ 0191 and ¶ 0280) and the input/output elements/points/flow associate the containerized control applications with the field devices (i.e. sensors, actuators) (Wouhaybi, FIG. 11, FIG. 26, ¶ 0191 and ¶ 0250). It would have been obvious to one of ordinary skill in the art to use the orchestrating control strategy in the software-defined industrial system techniques of Wouhaybi with the system of Chauvet-Rimar to “provide the ability, at a distributed application control strategy level, to leverage lower cost commodity hardware and software to achieve better system performance at a control strategy level” (Wouhaybi, ¶ 0183).
The table presented below exemplifies a mapping of independent claim 1 of the instant application to the claim 1 of ’798. Likewise, claims 2-45 contain subject matter found in claims 1-9, 11-30, 32-51 of co-pending application ’798.
Claim 1 of present application 17/838,951
Claim 1 of co-pending application 17/838,798
Claim 1: A method for use in controlling and visualizing an industrial process, having a process control system implemented on a data cluster having a plurality of computing nodes, each computing node including a processor executing an instance of an operating system, a memory, and a communication resource coupled to one or more other computing nodes in the data cluster, the method comprising:
executing a plurality of containers on the data cluster to perform runtime control operations using a plurality of process control field devices; communicatively coupling the plurality of containers with a software defined networking controller that communicatively couples the plurality of containers to the plurality of process control field devices operating to control a physical process in the industrial process plant via one or more input/output elements disposed between the plurality of containers and the process control field devices;
executing a container orchestrator on the data cluster to instantiate the plurality of containers and manage fault tolerance and load balancing functions on the data cluster; and
executing a visualization routine on the data cluster to receive real-time data from at least one of the plurality of containers, or from the software defined networking controller, or from the container orchestrator, and
to present a graphical depiction based on at least a portion of the received real-time data, the graphical depiction representing a system runtime configuration including a physical configuration having one or more physical devices and a process control logical configuration having a 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 process control system,
the graphical depiction including an indication of a manner in which one or more of the plurality of containers is currently associated with the one or more physical devices and with one or more of the plurality of process control logical elements and with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to the 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.
Claim 1: A method for use in controlling and visualizing an industrial process having a control system implemented on a data cluster having a plurality of computing nodes, each computing node including a processor executing an instance of an operating system, a memory, and a communication resource coupled to one or more other computing nodes in the data cluster, the method comprising:
executing a plurality of containers on the data cluster; communicatively coupling the plurality of containers to a plurality of process control field devices operating to control a physical process in an industrial process plant;
executing a container orchestrator on the data cluster to instantiate the plurality of containers and manage fault tolerance and load balancing functions on the data cluster; and
executing a visualization routine on the data cluster to receive real-time data from one or more of the plurality of containers or from the container orchestrator, and
to present a graphical depiction based on at least a portion of the received data, the graphical depiction representing a system configuration that includes a logical configuration associated with the system configuration, a plurality of logical elements including the plurality of containers during runtime of the process control system, and a physical configuration associated with one or more physical elements within the process control system,
wherein executing the visualization routine includes enabling a user, via user input based on the graphical depiction, to instruct the container orchestrator of a change of a manner in which the plurality of containers is associated with the one or more physical elements and, in response, causing the container orchestrator to perform the change to thereby dynamically change the manner in which the plurality of containers is associated with the one or more physical elements during runtime of the process control system.
This is a provisional nonstatutory obviousness-type double patenting rejection.
Double Patenting
Claims 1-45 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over the claims 1-80 of co-pending Application No. 17/836,624 (hereinafter ’624), in view of Rimar et al. (US 20190379590 A1, published 12/12/2019; hereinafter Rimar), and in further view of Wouhaybi et al. (US 20200310394 A1, published 10/01/2020; hereinafter Wouhaybi).
Although the claims at issue are not identical, they are not patentably distinct from each other because the claimed limitations recited in the instant application are transparently found in the listed co-pending application with obvious wording variations. Specifically, co-pending application ’624 does not teach “communicatively couples the plurality of containers to the plurality of process control field devices operating to control a physical process in the industrial process plant via one or more input/output elements disposed between the plurality of containers and the process control field devices.” However, Chauvet teaches connecting the containerized applications with field devices via external interfaces (Chauvet, ¶ 0111). It would have been obvious to one of ordinary skill in the art to use the software defined network controller of Chauvet with the system of ’798 to “disseminate network policies throughout the network infrastructure … to control connectivity, bandwidth and latency, Service Level Agreements …, traffic flow control, etc.” (Chauvet ¶ 0090). Also, co-pending application ’624 also does not teach “the graphical depiction including an indication of a manner in which at least one of the plurality of containers is currently associated with the one or more physical devices.” However, Rimar discloses the relationship manner between the containers and the software applications, as well as the relationship manner between the containers and the worker nodes in the computing cluster in a GUI (Rimar, ¶ 0113, ¶ 0116, ¶ 0145, ¶ 0146 and FIGS 9A, 9B). It would have been obvious to one of ordinary skill in the art to use the visualization techniques of Rimar with the system of ’624 to discover and logically organize representations and relationships of the containerized software applications (Rimar ¶ 0002) and generate service mapping to facilitate analysis of service impacts, help locate outages, and identify other potential issues in a managed network (Rimar, ¶ 0003). Further on, co-pending application ’624 does not teach one or more of the plurality of containers is also currently associated “with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to the 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, Wouhaybi discloses that the coordination of the function block applications is orchestrated to define a control strategy, the containers facilitate the control strategy of the application orchestration (Wouhaybi, ¶ 0170, ¶ 0185, ¶ 0190, ¶ 0191 and ¶ 0280) and the input/output elements/points/flow associate the containerized control applications with the field devices (i.e. sensors, actuators) (Wouhaybi, FIG. 11, FIG. 26, ¶ 0191 and ¶ 0250). It would have been obvious to one of ordinary skill in the art to use the orchestrating control strategy in the software-defined industrial system techniques of Wouhaybi with the system of Chauvet-Rimar to “provide the ability, at a distributed application control strategy level, to leverage lower cost commodity hardware and software to achieve better system performance at a control strategy level” (Wouhaybi, ¶ 0183)
The table presented below exemplifies a mapping of independent claim 1 of the instant application to the claim 59 of ’624. Likewise, claims 2-45 contain subject matter found in claims 1-80 of co-pending application ’624.
Claim 1 of present application 17/838,951
Claim 59 of co-pending application 17/836,624
Claim 1: A method for use in controlling and visualizing an industrial process, having a process control system implemented on a data cluster having a plurality of computing nodes, each computing node including a processor executing an instance of an operating system, a memory, and a communication resource coupled to one or more other computing nodes in the data cluster, the method comprising:
executing a plurality of containers on the data cluster to perform runtime control operation using a plurality of process control field devices; communicatively coupling the plurality of containers with a software defined networking controller that communicatively couples the plurality of containers to the plurality of process control field devices operating to control a physical process in the industrial process plant via one or more input/output elements disposed between the plurality of containers and the process control field devices;
executing a container orchestrator on the data cluster to instantiate the containers and manage fault tolerance and load balancing functions on the data cluster; and
executing a visualization routine on the data cluster to receive real-time data from at least one of the plurality of containers, from the software defined networking controller, or from the container orchestrator, and
to present a graphical depiction based on at least a portion of the received real-time data, the graphical depiction representing a system runtime configuration including a physical configuration having one or more physical devices and a process control logical configuration having a 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 process control system,
the graphical depiction including an indication of a manner in which one or more of the plurality of containers is currently associated with the one or more physical devices and with one or more of the plurality of process control logical elements and with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to the 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.
Claim 59: A method for use in controlling an industrial process having a control system implemented on a data cluster having a plurality of computing nodes, each computing node including a processor executing an instance of an operating system, a memory, and a communication resource coupled to one or more other computing nodes in the data cluster, the method comprising:
communicating, via a processor, with one or more computing nodes in the data cluster; executing, via one or more processors on the data cluster, a plurality of containers; executing, via a processor, a software defined networking controller that communicatively couples the plurality of containers to a plurality of process control field devices operating to control a physical process in an industrial process plant;
executing, via a processor, a container orchestrator to instantiate and manage the containers on the data cluster; and
executing, via a processor, a visualization routine, 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 control system based on the received data, the graphical depiction representing a logical configuration associated with the runtime configuration of the plurality of containers and a physical configuration associated with the runtime configuration of one or more physical elements within the process control system, the logical configuration including a 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 control system,
the graphical depiction of the logical configuration including a depiction of a manner in which one or more of the plurality of containers is currently associated with the one or more of the process control logical elements to thereby indicate a manner in which the one or more of the plurality of containers implement the process control strategy.
This is a provisional nonstatutory obviousness-type double patenting rejection.
Claim Objections
Claims 1 and 23 are objected to because of the following informalities:
Claim 1 recites the limitation “process control field devices” in line 27. It is unclear to the examiner if the limitation refers to the limitation “a plurality of process control field devices” recited in line 7. For examination purpose, “process control field devices” in line 27 will read as “the process control field devices.”
Claim 23 recites the limitation “plurality of process control field devices” in line 28. It is unclear to the examiner if the limitation refers to the limitation “a plurality of process control field devices” recited in line 9. For examination purpose, “plurality of process control field devices” in line 28 will read as “the plurality of process control field devices.”
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claims 1-3, 5-9, 11-16, 21-24, 30-41 and 43-45 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 20180316729 A1, published 11/01/2018; hereinafter Chauvet), in view of Rimar et al. (US 20190379590 A1, published 12/12/2019; hereinafter Rimar), and in further view of Wouhaybi et al. (US 20200310394 A1, published 10/01/2020; hereinafter Wouhaybi).
For Claim 1, Chauvet teaches a method for use in controlling and visualizing an industrial process, having a process control system implemented on a data cluster having a plurality of computing nodes, each computing node including a processor executing an instance of an operating system, a memory, and a communication resource coupled to one or more other computing nodes in the data cluster (Chauvet, FIG. 1, ¶ 0042 “… 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 …”; ¶ 0045 “… 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 …”; ¶ 0047 “… Smart connected devices 115 can comprise of hardware, software, sensors, storage, microprocessor(s), connectivity and the like …”), the method comprising:
executing a plurality of containers on the data cluster to perform runtime control operations using a plurality of process control field devices (Chauvet, FIG. 2B, FIG. 8A, ¶ 0054 “… 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 …”; ¶ 0111 “… 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 … 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 (i.e. Operational Technology network includes field devices such as sensors and actuators, etc.)). 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 …”);
communicatively coupling the plurality of containers with a software defined networking controller that communicatively couples the plurality of containers to the plurality of process control field devices operating to control a physical process in an industrial process plant via one or more input/output elements (Chauvet, ¶ 0111 external interfaces (e.g., Ethernet ports)) disposed between the plurality of containers and the process control field devices (Chauvet, FIG. 6B, FIG. 8A, ¶ 0095 “… 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 …”; ¶ 0111 “… 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 (i.e. Operational Technology network includes field devices such as sensors and actuators, etc.)). 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. In some embodiments, a compute node can be a smart connected device, which can have a physical part and a virtual part …”);
executing a container orchestrator on the data cluster to instantiate the plurality of containers and manage fault tolerance and load balancing functions on the data cluster (Chauvet, FIG. 10B, ¶ 0133 “… 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) …”); and
Chauvet does not explicitly teach, but Rimar teaches executing a visualization routine on the data cluster to receive real-time data from at least one of the plurality of containers, or from the software defined networking controller, or from the container orchestrator (Rimar, FIG. 3, FIG. 6, FIG. 8B, ¶ 0111 “… 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 …”; ¶ 0144 “… 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…”; ¶ 0135 “… 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 based on at least a portion of the received real-time data, the graphical depiction representing a system runtime configuration including a physical configuration having one or more physical devices and a process control logical configuration having a plurality of process control logical elements … that is implemented at least partially by the plurality of containers on the data cluster during runtime of the process control system (Rimar discloses generating the service mappings into a graph to depict the distribution and communicative relationships between the software applications, containers, and worker nodes, FIG. 9A and FIG. 9B exemplify a graphical user interface showing the configuration of software applications, pods and containers, as well as the configuration of the worker nodes; FIG. 3, FIG. 6, FIG. 8B, FIG.9A, FIG. 9B; ¶ 0145 “… 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 …”),
the graphical depiction including an indication of a manner in which one or more of the plurality of containers is currently associated with the one or more physical devices and with one or more of the plurality of process control logical elements … (Rimar discloses the relationship manner between the containers and the software applications, as well as the relationship manner between the containers and the worker nodes in the computing cluster in the GUI; FIG. 6, FIG. 8B, FIG. 9A, FIG. 9B; ¶ 0113 “… 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 …”; ¶ 0116 “… 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 …”; ¶ 0145 “… 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 …”; ¶ 0146 “… 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 …”).
Chauvet and Rimar are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the visualization techniques of Rimar with the system of Chauvet to discover and logically organize representations and relationships of the containerized software applications (Rimar ¶ 0002) and generate service mapping to facilitate analysis of service impacts, help locate outages, and identify other potential issues in a managed network (Rimar, ¶ 0003).
Chauvet-Rimar does not explicitly teach, but Wouhaybi teaches a plurality of process control logical elements that together define a process control strategy (Wouhaybi discloses that the coordination of the function block applications is orchestrated to define a control strategy using a graphical environment; FIG. 9; FIG. 11; ¶ 0170 “… a process engineer (or other operator) defines control flows and applications by combining and configuring existing functional blocks 990 from the library 980. These functional blocks 990 may represent application logic or control loops (e.g., control loops 970, data storage, analytics modules, data acquisition or actuation modules, or the like), control modules … such functional blocks may be utilized to implement end-to-end logic, including control flows or end-to-end applications using a graphical, drag-and-drop environment …”; ¶ 0191 “… 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
one or more of the plurality of containers is also currently associated with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to the 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 (Wouhaybi discloses the input/output elements/points/flow to associate the containerized control applications with the field devices (i.e. sensors, actuators), FIG. 11 and FIG. 26 exemplify the visualization of the process control strategies by using containers; ¶ 0191 “… 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 …”; ¶ 0250 “… FIG. 26 depicts an overview of a control application as represented by an example control application graph 2600, represented at the level of sensors and actuators. As shown, the control application is defined by a control engineer as a graph of software modules in which the outputs of each module (e.g., outputs from Sensor A 2610, and Sensor B 2620) are connected to the inputs of other modules (e.g., inputs into Actuator C 2640, and PID controller 2630). The control engineer may also specify other factors, such as starting values for module parameters. The control engineer may find these software modules in a software library or request that custom modules be implemented by an IT department. In an example, this graph may be defined through use of a graphical user interface, or other visual-based representation. For instance, the example control application graph 2600 may be defined by the control engineer to reflect inputs, outputs, and controllers of an industrial system. The example control application graph 2600 may reflect connections of a physical system, and be used to accomplish the various functional operations (and real-world changes, measurements, and effects) of the control application …”).
Wouhaybi and Chauvet-Rimar are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the orchestrating control strategy in the software-defined industrial system techniques of Wouhaybi with the system of Chauvet-Rimar to “provide the ability, at a distributed application control strategy level, to leverage lower cost commodity hardware and software to achieve better system performance at a control strategy level” (Wouhaybi, ¶ 0183).
For Claim 2, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes presenting, on the graphical depiction, one or more performance indications for at least a portion of the process control logical configuration (Rimar, FIG. 3, ¶ 0081 “… 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 …”). See motivation to combine for claim 1.
For Claim 3, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes presenting 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 (Rimar, FIG. 9A and FIG. 9B exemplifies graphical user interface that shows the mapping hierarchy between pods at different time periods and the containerized software applications are nested in the pods; ¶ 0148 “… a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein …”). See motivation to combine for claim 1.
For Claim 5, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes presenting a graphical depiction representing an interaction between a first logical configuration element and a first physical configuration element (Rimar, FIG. 9A, ¶ 0146 “… FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A …”). See motivation to combine for claim 1.
For Claim 6, Chauvet-Rimar-Wouhaybi teaches the method of claim 5, wherein executing the visualization routine includes presenting a graphical depiction that visually indicates a manner in which a first container is pinned to a first physical element (Rimar, FIG. 9A, ¶ 0146 “… FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A …”). See motivation to combine for claim 1.
For Claim 7, Chauvet-Rimar-Wouhaybi teaches the method of claim 5, wherein executing the visualization routine includes presenting 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 process control system (Rimar, FIG. 9A, FIG. 9B; ¶ 0147 “… 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) …”; ¶ 0149 “… 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 …”). See motivation to combine for claim 1.
For Claim 8, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes enabling a user, via user input based on the graphical depiction, to dynamically change the manner in which a first container is associated with a first physical element (Rimar, FIG. 8D, FIG. 9A, FIG. 9B; ¶ 0153 “… 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 …”; ¶ 0155 “… 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 …”). See motivation to combine for claim 1.
For Claim 9, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes presenting a graphical depiction representing an interaction between a first logical element and a second logical element (Rimar, FIG. 9A, ¶ 0146 “… 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 …”). See motivation to combine for claim 1.
For Claim 11, Chauvet-Rimar-Wouhaybi teaches the method of claim 9, wherein executing the visualization routine includes presenting a graphical depiction that visually indicates a manner in which a first container is nested within a second container (Rimar, FIG. 9A and FIG. 9B exemplifies graphical user interface that shows the mapping hierarchy between pods at different time periods and the containerized software applications are nested in the pods; ¶ 0148 “… a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein …”). See motivation to combine for claim 1.
For Claim 12, Chauvet-Rimar-Wouhaybi teaches the method of claim 9, wherein executing the visualization routine includes presenting 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 process control system (Rimar, FIG. 9A, FIG. 9B; ¶ 0147 “… 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) …”; ¶ 0149 “… 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 …”). See motivation to combine for claim 1.
For Claim 13, Chauvet-Rimar-Wouhaybi teaches the method of claim 12, wherein executing the visualization routine includes enabling 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 (Rimar, FIG. 8D, FIG. 9A, FIG. 9B; ¶ 0153 “… 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 …”; ¶ 0155 “… 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 …”). See motivation to combine for claim 1.
For Claim 14, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes presenting a graphical depiction including an identification of one or more containers executing on one or more computing nodes (Rimar, FIG. 9A and FIG. 9B exemplifies the user interfaces displaying that the pods (and thus containers and applications) execute on the worker nodes; ¶ 0146 “… 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 …”). See motivation to combine for claim 1.
For Claim 15, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, wherein executing the visualization routine includes presenting 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 the one or more process control logical elements of the process control system (Rimar, FIG. 9A, ¶ 0146 “… 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 …”). See motivation to combine for claim 1.
For Claim 16, Chauvet-Rimar-Wouhaybi teaches the method of claim 1, 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 (Rimar, FIG. 9A and FIG. 9B exemplifies graphical user interface that shows the mapping hierarchy between pods at different time periods and the containerized software applications are nested in the pods; ¶ 0148 “… a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein …”). See motivation to combine for claim 1.
For Claim 21, Chauvet-Rimar-Wouhaybi teaches the method of claim 16, wherein executing the visualization routine further includes enabling a user, via a user interface, to change the manner in which the set of containers are associated with one another during runtime of the process control system (Rimar, FIG. 8D, FIG. 9A, FIG. 9B; ¶ 0153 “… 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. SD. In response, software application 802 executing in pod 808C may process the eleventh request and provide a corresponding response 830 …”; ¶ 0155 “… 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 …”). See motivation to combine for claim 1.
For Claim 22, Chauvet-Rimar-Wouhaybi teaches the method of claim 21, wherein executing the visualization routine further includes enabling a user, via the user interface, to change the manner in which the set of containers are nested with respect to one another during runtime of the process control system (Rimar, FIG. 9A, ¶ 0148 “… When displayed on user interface 900, the nodes of the graph may be interactive, allowing for the level within the hierarchy represented by each node to be modified. For example, a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein. Further, the containerized software applications may be selected to view the different processes that make up the software application …”; ¶ 0149 “… 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 …”). See motivation to combine for claim 1.
For Claim 23, Chauvet teaches an industrial process control system (Chauvet, ¶ 0042 “… 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 …”) 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 one or more other computing nodes in the data cluster (Chauvet, FIG. 1, ¶ 0045 “… 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 …”; ¶ 0047 “… Smart connected devices 115 can comprise of hardware, software, sensors, storage, microprocessor(s), connectivity and the like …”);
a plurality of containers executing on the data cluster, the plurality of containers in communication with a plurality of process control field devices operating to control a physical process in an industrial process plant via one or more input/output elements (Chauvet, ¶ 0111 external interfaces (e.g., Ethernet ports)) disposed between the plurality of containers and the plurality of process control field devices (Chauvet, FIG. 6B, FIG. 8A, ¶ 0095 “… 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 …”; ¶ 0111 “… 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 (i.e. Operational Technology network includes field devices such as sensors and actuators, etc.)). 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. In some embodiments, a compute node can be a smart connected device, which can have a physical part and a virtual part …”),
the plurality of containers executing on the data cluster to perform runtime control operations using the plurality of process control field devices (Chauvet, FIG. 2B, FIG. 8A, ¶ 0054 “… 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 …”; ¶ 0111 “… 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 … 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 (i.e. Operational Technology network includes field devices such as sensors and actuators, etc.)). 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 …”);
a container orchestrator operable to instantiate and manage the plurality of containers on the data cluster (Chauvet, FIG. 10B, ¶ 0133 “… 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) …”); and …
Chauvet does not explicitly teach, but Rimar teaches a visualization routine executing on the data cluster, the visualization routine operable to receive real-time data from at least one of the plurality of containers or from the container orchestrator (Rimar, FIG. 3, FIG. 6, FIG. 8B, ¶ 0111 “… 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 …”; ¶ 0144 “… 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…”; ¶ 0135 “… 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 based on at least a portion of the received real-time data, the graphical depiction representing a system runtime configuration including a physical configuration having one or more physical devices and a process control logical configuration having a plurality of process control logical elements … that is implemented at least partially by one or more of the plurality of containers on the data cluster during runtime of the industrial process control system (Rimar discloses generating the service mappings into a graph to depict the distribution and communicative relationships between the software applications, containers, and worker nodes, FIG. 9A and FIG. 9B exemplify a graphical user interface showing the configuration of software applications, pods and containers, as well as the configuration of the worker nodes; FIG. 3, FIG. 6, FIG. 8B, FIG.9A, FIG. 9B; ¶ 0145 “… 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 …”),
the graphical depiction including an indication of a manner in which at least one of the one or more of the plurality of containers is currently associated with the one or more physical devices and with the one or more of the plurality of process control logical elements … (Rimar discloses the relationship manner between the containers and the software applications, as well as the relationship manner between the containers and the worker nodes in the computing cluster in the GUI; FIG. 6, FIG. 8B, FIG. 9A, FIG. 9B; ¶ 0113 “… 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 …”; ¶ 0116 “… 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 …”; ¶ 0145 “… 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 …”; ¶ 0146 “… 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 …”).
Chauvet and Rimar are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the visualization techniques of Rimar with the system of Chauvet to discover and logically organize representations and relationships of the containerized software applications (Rimar ¶ 0002) and generate service mapping to facilitate analysis of service impacts, help locate outages, and identify other potential issues in a managed network (Rimar, ¶ 0003).
Chauvet-Rimar does not explicitly teach, but Wouhaybi teaches a plurality of process control logical elements that together define a process control strategy (Wouhaybi discloses that the coordination of the function block applications is orchestrated to define a control strategy using a graphical environment; FIG. 9; FIG. 11; ¶ 0170 “… a process engineer (or other operator) defines control flows and applications by combining and configuring existing functional blocks 990 from the library 980. These functional blocks 990 may represent application logic or control loops (e.g., control loops 970, data storage, analytics modules, data acquisition or actuation modules, or the like), control modules … such functional blocks may be utilized to implement end-to-end logic, including control flows or end-to-end applications using a graphical, drag-and-drop environment …”; ¶ 0191 “… 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
one or more of the plurality of containers is also currently associated with the one or more input/output elements through which the one or more of the plurality of containers is communicatively coupled to the 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 (Wouhaybi discloses the input/output elements/points/flow to associate the containerized control applications with the field devices (i.e. sensors, actuators), FIG. 11 and FIG. 26 exemplify the visualization of the process control strategies by using containers; ¶ 0191 “… 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 …”; ¶ 0250 “… FIG. 26 depicts an overview of a control application as represented by an example control application graph 2600, represented at the level of sensors and actuators. As shown, the control application is defined by a control engineer as a graph of software modules in which the outputs of each module (e.g., outputs from Sensor A 2610, and Sensor B 2620) are connected to the inputs of other modules (e.g., inputs into Actuator C 2640, and PID controller 2630). The control engineer may also specify other factors, such as starting values for module parameters. The control engineer may find these software modules in a software library or request that custom modules be implemented by an IT department. In an example, this graph may be defined through use of a graphical user interface, or other visual-based representation. For instance, the example control application graph 2600 may be defined by the control engineer to reflect inputs, outputs, and controllers of an industrial system. The example control application graph 2600 may reflect connections of a physical system, and be used to accomplish the various functional operations (and real-world changes, measurements, and effects) of the control application …”).
Wouhaybi and Chauvet-Rimar are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the orchestrating control strategy in the software-defined industrial system techniques of Wouhaybi with the system of Chauvet-Rimar to “provide the ability, at a distributed application control strategy level, to leverage lower cost commodity hardware and software to achieve better system performance at a control strategy level” (Wouhaybi, ¶ 0183).
For Claim 24, the claim is substantially similar to claim 16 and therefore is rejected for the same reasoning set forth above.
For Claim 30, the claim is substantially similar to claim 5 and therefore is rejected for the same reasoning set forth above.
For Claim 31, the claim is substantially similar to claim 6 and therefore is rejected for the same reasoning set forth above.
For Claim 32, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 23, wherein the visualization routine presents a graphical depiction 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 (Rimar, FIG. 9A, FIG. 9B; ¶ 0147 “… 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) …”; ¶ 0149 “… 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 …”). See motivation to combine for claim 23.
For Claim 33, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 32, 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 second container (Rimar, FIG. 8D, FIG. 9A, FIG. 9B; ¶ 0148 “… When displayed on user interface 900, the nodes of the graph may be interactive, allowing for the level within the hierarchy represented by each node to be modified. For example, a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein. Further, the containerized software applications may be selected to view the different processes that make up the software application …”; ¶ 0149 “… 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 …”; ¶ 0153 “… 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 …”; ¶ 0155 “… 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 …”). See motivation to combine for claim 23.
For Claim 34, the claim is substantially similar to claim 12 and therefore is rejected for the same reasoning set forth above.
For Claim 35, the claim is substantially similar to claim 13 and therefore is rejected for the same reasoning set forth above.
For Claim 36, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 23, wherein the visualization routine presents a graphical depiction further including a performance indication indicating a performance metric of one of the process control logical elements (Rimar, FIG. 3, ¶ 0081 “… 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 …”). See motivation to combine for claim 23.
For Claim 37, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 23, wherein the visualization routine presents a graphical depiction further representing one or more physical elements of the physical configuration, and a performance indication indicating a performance metric of one of the one or more physical elements (Rimar, FIG. 3, ¶ 0066 “… 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 …”; ¶ 0081 “… 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 …”). See motivation to combine for claim 23.
For Claim 38, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 37, wherein the physical element is a computer device or a communication connection (Rimar, FIG. 3, ¶ 0066 “… 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 …”). See motivation to combine for claim 23.
For Claim 39, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 23, 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 (Rimar, FIG. 3, ¶ 0067 “… 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 …”). See motivation to combine for claim 23.
For Claim 40, the claim is substantially similar to claim 14 and therefore is rejected for the same reasoning set forth above.
For Claim 41, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 23, wherein the visualization routine presents a graphical depiction including a health status of each of a plurality of computing nodes (Rimar, FIG. 3, ¶ 0090 “… 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 …”; ¶ 0104 “… 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 …”). See motivation to combine for claim 23.
For Claim 43, the claim is substantially similar to claim 15 and therefore is rejected for the same reasoning set forth above.
For Claim 44, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 43, wherein the configuration hierarchy illustrates a manner in which one or more logical elements are nested in or pinned to other logical elements (Rimar, FIG. 9A and FIG. 9B exemplifies graphical user interface that shows the mapping hierarchy between pods at different time periods and the containerized software applications are nested in the pods; ¶ 0148 “… a node representing a pod may be clicked or otherwise selected to view the containerized software applications executing therein …”). See motivation to combine for claim 23.
For Claim 45, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 43, wherein the configuration hierarchy illustrates a manner in which one or more logical elements are currently pinned to one or more physical elements (Rimar, FIG. 9A, ¶ 0146 “… FIG. 9A shows that requests from remote user(s) 602 are handled by software application 800 executing in pod 806 on worker node 612A …”). See motivation to combine for claim 23.
Claim Rejections - 35 USC § 103
Claims 4, 10 and 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 20180316729 A1, published 11/01/2018; hereinafter Chauvet), in view of Rimar et al. (US 20190379590 A1, published 12/12/2019; hereinafter Rimar), in view of Wouhaybi et al. (US 20200310394 A1, published 10/01/2020; hereinafter Wouhaybi), and in further view of Jangam et al. (US 11451447 B1, filed 11/18/2020; hereinafter Jangam).
For Claim 4, Chauvet-Rimar-Wouhaybi teaches the method of claim 1. Chauvet-Rimar-Wouhaybi does not explicitly teach, but Jangam teaches wherein executing the visualization routine includes presenting a graphical depiction representing a logical configuration that visually indicates the manner in which a first container is pinned to a second container (Jangam discloses container visualization depicting all of the containers in a cluster/pod; FIG. 2B, FIG. 2C; col. 7, l. 62 – col. 8, l. 57 “… FIG. 2B depicts a Network Topology 200B 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 …”).
Jangam and Chauvet-Rimar-Wouhaybi are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the visualization techniques of Jangam with the system of Chauvet-Rimar-Wouhaybi to help depicting the topology of the complex, ever-changing data center with physical and virtualized components (Jangam, col. 1, ll. 48-67).
For Claim 10, Chauvet-Rimar-Wouhaybi teaches the method of claim 9. Chauvet-Rimar-Wouhaybi does not explicitly teach, but Jangam teaches wherein executing the visualization routine includes presenting a graphical depiction that visually indicates the manner in which a first container is pinned to a second container (Jangam discloses container visualization depicting all of the containers in a cluster/pod; FIG. 2B, FIG. 2C; col. 7, l. 62 – col. 8, l. 57 “… FIG. 2B depicts a Network Topology 200B 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 …”). See motivation to combine for claim 4.
For Claim 29, the claim is substantially similar to claim 4 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 17-20, and 25-28, is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 20180316729 A1, published 11/01/2018; hereinafter Chauvet), in view of Rimar et al. (US 20190379590 A1, published 12/12/2019; hereinafter Rimar), in view of Wouhaybi et al. (US 20200310394 A1, published 10/01/2020; hereinafter Wouhaybi), and in further view of Resurreccion et al. (US 20120259436 A1, published 10/11/2012; hereinafter Resurreccion).
For Claim 17, Chauvet-Rimar-Wouhaybi teaches the method of claim 16. Chauvet-Rimar-Wouhaybi does not explicitly teach, but Resurreccion teaches wherein the set of nested containers includes a control container and an I/O server container nested within a subsystem container (Resurreccion, FIG. 3, ¶ 0075 “… the example in FIG. 3 shows that logical containers may be nested to enable process control personnel to further organize process control resources … Further, the 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 …”).
Resurreccion and Chauvet-Rimar-Wouhaybi are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the visualization techniques of Resurreccion with the system of Chauvet-Rimar-Wouhaybi to help organizing “information associated with field devices, controllers, and other process control components into a hierarchical structure” (Resurreccion, ¶ 0004) and “enable process control personnel to manage process control resources by creating logical containers” (Resurreccion, ¶ 0021).
For Claim 18, Chauvet-Rimar-Wouhaybi-Resurreccion teaches the method of claim 17, 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 (Resurreccion, FIG. 2, FIG. 3, ¶ 0050 “… 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 …”). See motivation to combine for claim 17.
For Claim 19, Chauvet-Rimar-Wouhaybi-Resurreccion teaches the method of claim 18, wherein the further container is one of a data collection container, a data processing container, a third party container, and a performance index container (Resurreccion, FIG. 2, FIG. 3, ¶ 0051 “… 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 …”). See motivation to combine for claim 17.
For Claim 20, Chauvet-Rimar-Wouhaybi-Resurreccion teaches the method of claim 16, 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 (Examiner notes that the claimed limitations are not located in the instant specification, examiner considers the instant specification ¶ 0385 and FIG. 43 are close to interpret the claimed limitations for examination such as “For example, the hierarchy 3210 of FIG. 43 indicates that various recipes 3270 are dynamically assignable containers;” Resurreccion, FIG. 2, FIG. 3, ¶ 0050 “… 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 …”). See motivation to combine for claim 17.
For Claim 25, the claim is substantially similar to claim 17 and therefore is rejected for the same reasoning set forth above.
For Claim 26, the claim is substantially similar to claim 18 and therefore is rejected for the same reasoning set forth above.
For Claim 27, the claim is substantially similar to claim 19 and therefore is rejected for the same reasoning set forth above.
For Claim 28, the claim is substantially similar to claim 20 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 42 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 20180316729 A1, published 11/01/2018; hereinafter Chauvet), in view of Rimar et al. (US 20190379590 A1, published 12/12/2019; hereinafter Rimar), in view of Wouhaybi et al. (US 20200310394 A1, published 10/01/2020; hereinafter Wouhaybi), and in further view of Law et al. (US 20180114414 A1, published 04/26/2018; hereinafter Law).
For Claim 42, Chauvet-Rimar-Wouhaybi teaches the industrial process control system of claim 23. Chauvet-Rimar-Wouhaybi does not explicitly teach, but 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 (Law, FIG. 1, FIG. 2, ¶ 0042 “… 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 …”; ¶ 0043 “… Generally speaking, a container may be a physical device, such as a field device, an I/O device, 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 …”).
Law and Chauvet-Rimar-Wouhaybi are analogous art because they are both related to containers.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the visualization techniques of Law with the system of Chauvet-Rimar-Wouhaybi to help depicting control system logic of the process control components (Law, ¶ 0002 and ¶ 0008).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. Biernat et al. (US 20220091572 A1) discloses that a system may include a first computing node of a cluster of computing nodes that are part of a container orchestration system, and a plurality of control systems for controlling a plurality of operations of a plurality of operational technology (OT) devices. A first control system of the plurality of control systems is communicatively coupled to the first computing node, such that the first control system is configured to communicatively couple to a first OT device of the plurality of OT devices (Biernat, ¶ 0006).
ii. Putman et al. (US 20220179398 A1) discloses leveraging container orchestration systems to generate visualizations related to components or operations of an industrial automation system. In particular, a visual manager, a primary node of the container orchestration system, may receive a container image for operating an application of the industrial automation system. A visual manager may identify a container host from a cluster of nodes of the container orchestration system for executing the container in response to the container host meeting container orchestration constraints. Upon execution of the constraint, the container host may transmit configuration details for accessing a visualization associated with the container image to a thin client for display. In some embodiments, the container host, itself, may include a thin client device. Accordingly, the thin client device may execute the container and display the corresponding visualization (Putman, Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444