DETAILED ACTION
This office action is in response to Applicant’s arguments and amendments filed on 7/30/2025. Claims 1-20 have been amended. Therefore, Claims 1-20 are still pending in the present application.
Response to Amendments/Arguments
Applicant’s argument/remarks, on page 10, with respect to rejections to claim(s) 12 under 35 USC § 112 (b) have been fully considered and are persuasive. Therefore, rejections to the claims under 35 USC § 112 have been withdrawn. The amendments overcome the rejections.
Applicant’s argument/remarks, on pages 10-12, with respect to rejections to claims 1-20 under 35 USC § 103(a) have been fully considered and they are persuasive. Therefore, rejections to the claims have been withdrawn based on the amendments. However, upon further consideration, a new ground(s) of rejection is made in view of Kenst et al.
On page 11, the Applicant argues that:
“None of the cited references teach a firmware extension comprising functionality to locate and provide information from CIP objects”. These arguments are respectfully persuasive.
On page 11, the Applicant argues that:
“Rischar also fails to disclose receiving, via a deployment interface, a user selection to activate the firmware extension loaded in the industrial PLC. Rather”. The arguments are respectfully unpersuasive.
Rischar teaches a tool that allows user to download, install and run/activate an extension software program. Also, a program cannot be activated in a remote controller if it is not downloaded first. Lawson also teaches an interface with options to activate, delete and disable software from first computer tool software already loaded in a second remote controller/platform (see Lawson 0071, 0101). Lawson was also cited to teach these limitations.
In response to applicant's argument that Lawson is a nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, the claimed invention is simply directed to an interface with options to activate, delete, and disable a program/software extensions after the program is loaded in a remote system or controller and which Lawson teaches an interface with same options and solves the same problem of remotely configuring a system. Remotely configuring a controller/computer with a interface with options of activating, deleting, and disabling was widely used in a lot of computer systems including computer with Microsoft OS.
On page 13, the Applicant further argues that:
“Rischar teaches away from the use of virtualization”. The arguments are respectfully unpersuasive.
As stated previously (OA of 03/31/2025), and in response to the arguments above, Rischar Paragraph 0011 suggests that it was well known to use virtualization to provide further capabilities in PLC or industrial controllers. Rischar only suggests that virtualization requires more memory in the controllers. However, Richard does not suggest or forbids the use of virtualization in this paragraph.
On page 14, the Applicant further argues that:
“Rischar does not teach a firmware extension. The Office Action has applied an overly broad interpretation of the term "firmware" to read on Rischar' s loadable modules. In Rischar, the operating system and firmware are disclosed as distinct elements, and Rischar explains explicitly that the loadable modules provide functionality to extend the operating system without updating the firmware… Rischar [0013]. Thus Rischar's operating system extension cannot be reasonably interpreted to be a firmware extension as recited in the present claims in view of the knowledge of one of ordinary skill, the disclosure of the present application, and the disclosure of Rischar. The Applicant notes that claims must be given their broadest reasonable interpretation”. These arguments are respectfully unpersuasive.
The objective or result of the current invention is exactly the same objective/result as Rischar’s invention. For instance, the original disclosure of this instant application [0022] recites “the present technology provides a framework for adding new functionality to industrial controllers without the need to perform entire firmware updates…”. The current invention generate extensions called firmware extensions. Rischar generate loadable modules software that bind to and/or use firmware and other resources and which suggests “firmware extensions” modules (see 0013, 0016, 0059).
The disclosure does not explicitly define the terms “firmware” or “firmware extension”, and some other terms which acquire different meaning in the state of the art of computer science. For instance, the published disclosure [0021] recites “executing firmware (i.e., embedded software) extensions”, thus, the disclosure exemplifies the firmware as embedded software. The original disclosure also recites 0031 “extension executable 112 is representative of any extension executable that may be developed in accordance with the present disclosure…A firmware extension, such as extension executable 112, provides one or more components to perform one or more functions not natively available within firmware of controller 131”, thus, a firmware extension is any executable software being installed in the PLC . Based on this broad definition, Rischar clearly teaches extensions as being executables and which performs some function within the PLC (see 0043-0045).
The disclosure does not explicitly teach the algorithm or code included in said firmware extensions and thus, they have been interpreted in the BRI in light of the disclosure and state of the art as “software executables” stored in a PLC.
The Applicant’s simply states that “Thus Rischar's operating system extension cannot be reasonably interpreted to be a firmware extension as recited in the present claims in view of the knowledge of one of ordinary skill”, but does not provide any explicit guidance or evidence on how to interpret the said term “firmware extension”. The Examiner agrees that firmware and operating systems are widely known and distinct software programs, and which bind together to allow a computer system to function properly.
The Applicant’s in a previous office action interpreted and stated in the arguments that “the general understanding of the terms "firmware" and "embedded software core" as referring to code that is specifically adapted to particular hardware” based on the NPL reference Wikipedia “Firmware” cited by the Applicant. The Applicant and the disclosure does not explain which particular hardware is adapted by the firmware or the algorithm of said firmware extension. The same NPL reference provides different broad definitions and interpretation of the term firmware such as “operating system’, “software” “program that will run on the system and provide all of its functions and “machine instructions’, “any computer program that is linked to hardware including machine instructions for BIOS”. The same NPL reference gives examples or definitions of Firmware such as timing and control system for washing machines, BIOS, operating systems, etc. Thus, the term firmware extension acquires different meaning as previously suggested by the Applicant’s cited reference (see Applicant’s response of 01/24/2025 pages 12-13) and, thus, extension has been interpreted as software/program.
Information Disclosure Statement (IDS)
The information disclosure statement (IDS) submitted on 06/10/2025 and 8/20/2025 was filed after the mailing date of the non-final Application 03/31/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-5, 8-9, 11, 15-16, 18, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rischar et al (EP 3059647) in view of Govil et al (US 20080148048), Lawson et al (US 20130212129), and Kenst et al (US 20080109829).
As per claim 1, Rischar teaches an industrial programmable logic controller (PLC) (see Fig. 1 and 3 PLC 12; also, see [0032] “The industrial controllers A and B may be Programmable Logic Controllers (PLC's)”) comprising: one or more computer-readable storage media (see Fig. 1 memory 34; also, see [0034] “Hardware components of the industrial controllers A and B may each include…a memory 34 and a disk 36 or other form of non-volatile storage, including but not limited to Flash memory and/or solid state drives;);
a processing system operatively coupled to the one or more computer-readable storage media (see Fig. 1 processor 30 and also, see [0019] and [0028] and [0067] “An industrial controller comprising a processor executing: an operating system stored in non-transient memory for managing hardware components of the industrial controller…”;); and
program instructions stored on the computer-readable storage media, wherein the program instructions comprise a control program that, when read and executed by the processing system, directs the industrial PLC to (see Fig. 3 PLC 12 and see [0019] “an industrial controller comprises a processor executing: an operating system stored in non-transient memory for managing hardware components of the industrial controller…”; the term “control program” has been interpreted in the BRI in light of the specification as software or operating system executing instructions; also, see [0039] and [0052] “…The first and second application modules 182 and 184 may be modules of a control program running on an industrial controller 40 for controlling a controlled process….”):
load, using a deployment interface (the deployment interface has been interpreted in BRI in light of disclosure wherein it acquire several definitions based examples such as GUI, a CIP protocol or an extension development environment 111 including a computer, see original disclosure figs. 1-3; Rischar further teaches see Fig.1 interface 42 and see [00034] “a control network interface element 42 (allowing connection and communication with the control network 16 and/or 35 other networks”; also, see Fig. 3 interface 120; also, see [0042] “…embedded linker/loader/compiler 120…”, component 120 also is a deployment interface”; also, see claim 1 and 6 CIP connections; also, see [0040] “…the invention. The electronic computer 50 includes a design and configuration environment 100, such as RSLogix 5000 from Rockwell Automation, Inc. The design and configuration environment 100 may employ a graphical user interface or simply a high level computing language such as C++. The user designs, modifies and/or updates the project accordingly and produces a source module 102, which may include source application code, source library code, and/or other source data as generally understood in the art...”), a firmware extension into the industrial PLC (see [0019-0020], [0043-0045]; the term firmware extension has been interpreted in the BRI in light of the disclosure as executables software modules to be stored in a PLC and which provides functions for the PLC, see original disclosure 0031), wherein:
the firmware extension extends functionality of firmware in the industrial PLC (see [0019-0020] “a loadable module manager stored in non-transient memory configured to receive a second application module… The second application module may be configured to extend …at least a portion of the operating system while the first application module controls the at least a portion of the controlled process…”; also, see [0043] “…source modules, as well as executable and object files, may be loaded…”; see Fig. 3 module manager loads application modules including the extension application modules such as second application module Mod-A2 which is an extension software; also, see [0044] “…Accordingly, the loadable module manager 138 binds and places the application module 134 ("EXECUTABLE") into service among the loaded application modules 140 as a running application module 142 ("MOD_A3"). The running application module 142 ("MOD_A3") may, in turn, extend or modify at least a portion of the operating system while one or more of the loaded application modules 140 continues to control the controlled process”; also, see [0045] “loaded application modules 140”; also, see Col 18 lines 25-30 “…wherein the second application module is configured to extend or modify the at least a portion of the operating system without modification to the firmware”, also, loading is interpreted in the BRI as preparing a program for its execution by copying the instructions in memory for execution. That is the purpose of a loader such as the loadable manager 138”),
the firmware extension is loaded in a(see Fig. 5a the extensions are loaded in an execution environment separated from the OS and the kernel space. The kernel is part of the operating system; also, see [0013] “The present invention provides a "loadable module" architecture for industrial controllers in which new control program modules which provide updated functions or features may be loaded to extend or modify the underlying operating system and/or add or modify other services that are part of the industrial controller without updating the firmware and without disrupting or otherwise compromising the ability of the industrial controller to maintain continuous control over the controlled); and
the firmware extension comprises functionality to locate and provide particular information from each of multiple(se [0035] “source code modules may be delivered and then compiled and linked to create [resulting object modules within the industrial controller”; Also, see [0047], [0051], and [0057]);
provide, via the deployment interface, options to activate, (Rischar further teaches in [0040] “…The electronic computer 50 includes a design and configuration environment 100, such as RSLogix 5000 from Rockwell Automation, Inc. The design and configuration environment 100 may employ a graphical user interface or simply a high level computing language such as C++. The user designs, modifies and/or updates the project accordingly and produces a source module 102, which may include source application code, source library code, and/or other source data as generally understood in the art...”, this design environments allow a user the options to send and activate extensions; also, see Fig. 8 the files are sent and executed/activated; also, see [0062] “Finally, in a sixth process block 334, the fully bound modules are loaded and executed…”) after the firmware extension is loaded in the industrial PLC (also, see [0062] “Finally, in a sixth process block 334, the fully bound modules are loaded and executed” an extension or program can only be activated/executed after being loaded);
receive, via the deployment interface, a user selection to activate the firmware extension loaded in the industrial PLC (see Rischar further teaches in [0040] “…The electronic computer 50 includes a design and configuration environment 100, such as RSLogix 5000 from Rockwell Automation, Inc. The design and configuration environment 100 may employ a graphical user interface or simply a high level computing language such as C++. The user designs, modifies and/or updates the project accordingly and produces a source module 102, which may include source application code, source library code, and/or other source data as generally understood in the art...”, this design environments allow a user the options to send and activate extensions, the user select or chooses to send or not send programs to Controllers 12 or 14; also, see [0062]);
in response to the user selection, execute the firmware extension in the industrial PLC (see [0019-0020] “a loadable module manager stored in non-transient memory configured to receive a second application module… The second application module may be configured to extend …at least a portion of the operating system while the first application module controls the at least a portion of the controlled process…”; also, see [0043] “…source modules, as well as executable and object files, may be loaded…”; see Fig. 3 module manager loads application modules including the extension application modules such as second application module Mod-A2 which is an extension software; also, see [0044] “…Accordingly, the loadable module manager 138 binds and places the application module 134 ("EXECUTABLE") into service among the loaded application modules 140 as a running application module 142 ("MOD_A3"). The running application module 142 ("MOD_A3") may, in turn, extend or modify at least a portion of the operating system while one or more of the loaded application modules 140 continues to control the controlled process”; also, see [0045] “loaded application modules 140”; also, see Col 18 lines 25-30 “…wherein the second application module is configured to extend or modify the at least a portion of the operating system without modification to the firmware”, also, loading is interpreted in the BRI as preparing a program for its execution by copying the instructions in memory for execution. That is the purpose of a loader such as the loadable manager 138”);
during execution of the control program, when directed by the control program to perform a native function, call a native component of the firmware to perform the native function (see Fig. 3 and [0019] “an operating system stored in non-transient memory for managing hardware components of the industrial controller; a first application module stored in non-transient memory for controlling at least a portion of a controlled process via the operating system…”; see [0042] “local firmware… In addition, a resource manager 122 in the industrial controller A may reference a data structure 124, a library manager 126, and a local firmware 128 in the industrial controller A, and provide such resource information to the embedded linker/loader/compiler 120”; also, see Col 20 claim 2 “the operating system is configured to communicate with firmware before managing the hardware components”), wherein the native component of the firmware is embedded in hardware of the industrial PLC (see [0042] “local firmware… In addition, a resource manager 122 in the industrial controller A may reference a … a local firmware 128 in the industrial controller A, and provide such resource information to the embedded linker/loader/compiler 120”; thus, the firmware is embedded in hardware of the PLC in an embedded software core 120. The term firmware and embedded software core has been interpreted as suggested in the arguments in the BRI as “the terms "firmware" and "embedded software core" as referring to code that is specifically adapted to particular hardware”); and
during execution of the control program, when directed by the control program to perform an external function, call an external component provided by the firmware extension to perform the external function (see Col 16 lines 25-30 “…wherein the second application module is configured to extend or modify the at least a portion of the operating system without modification to the firmware”; also, see [0052]; also, see Col 20 claim 2).
While Rischar teaches that the system can provide virtualization (see 0011) and also teaches a computer with a design environment for the creation of extension applications (see 0035 and Fig. 3 100), Rischar does not explicitly teach:
the firmware extension is loaded in a virtualized execution environment isolated from an operating system (OS) kernel of the industrial PLC,
provide, via the deployment interface, options to delete, and disable the firmware extension after the firmware extension is loaded in the industrial PLC,
receive, via the deployment interface, a user selection to activate the loaded firmware extension in the industrial PLC; in response to the user selection, execute the firmware extension in the industrial PLC, and
the firmware extension comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC.
However, Govil teaches a computer system and method comprising steps of virtualization wherein, an extension is loaded in a virtualized execution environment isolated from an operating system (OS) kernel of the controller (see the Abstract “Hardware virtualization support is used to isolate kernel extensions …”; see [0010] “The invention isolates kernel extensions (such as device drivers) using hardware virtualization support. An operating system kernel is protected from a kernel extension by executing the kernel and the kernel extension in separate hardware protection domains”; also, see Fig. 3a-c; also, see [0027] “The memory 110 includes a kernel 600 and at least one kernel extension 604. The kernel 600 is a set of computer instructions (also referred to as "kernel code") comprising the core of an operating system. The kernel 600 may include, for example, computer instructions for managing applications, allocating computer resources, and prioritizing the requirements of the devices 103. The computer instructions of the kernel 600 execute with a special execution privilege level on the CPU 104”; also, see [0028] and [0036], [0041], [0045]-[0048]).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s invention to include steps of virtualization wherein an extension is loaded in a virtualized execution environment isolated from an operating system (OS) kernel of the controller as taught by Govil in order to load and execute the firmware extension isolated from the kernel software of the PLC as taught by Richard in order to protect the operating system and Kernel from any action from the extensions than could damage the OS ?kernel of the controller (see [0010] “An operating system kernel is protected from a kernel extension by executing the kernel and the kernel extension in separate hardware protection domains…”).
Rischar-Govil still does not explicitly teach provide, via the deployment interface, options to delete and disable the firmware extension after the firmware extension is loaded in the industrial PLC; receive, via the deployment interface, a user selection to activate the loaded firmware extension in the industrial PLC; in response to the user selection, execute the firmware extension in the industrial PLC.
However, Lawson teaches a system comprising a deployment interface providing, via the deployment interface, options to activate, delete, and disable a program/software after the program is loaded in a remote system or controller (see [0071] “Such applications can include, for example, control panel or dashboard templates that allow an administrator to configure and monitor aspects of a cloud-based industrial system running on cloud resources 812, virtual machine management templates that allow a user to create, start, stop, or delete virtual machines running on the cloud resources 812”, wherein virtual machine are software programs executed in a remote system such as cloud resources/processors and memory…”; also, see [0101] “…When installed and executed on a client device 1406 (or accessed remotely by client device 1406, as in FIG. 8), virtual machine management template 1412 can generate…control panel 1414 can include intuitive interface controls that allow a user to create, start, stop, or delete virtual machines on cloud platform 1402 directly from the control panel. These can include, for example, controls for selecting a type of virtual machine to be deployed, naming the virtual machine, specifying a hostname of a cloud-based host on which the virtual machine is to run, specifying a cloud-based hypervisor that is to perform resource management for the virtual machine, and defining a resource allocation for the virtual machine…”; also, see [0101] “Virtual machine control panel 1414 can include intuitive interface controls that allow a user to create, start, stop, or delete virtual machines on cloud platform 1402 directly from the control panel…”, thus, this suggests to activate, delete, and disable a program/software after the program is loaded in the remote system), receive, via the deployment interface, a user selection to activate the program/software loaded (see [0101] “…These can include, for example, controls for selecting a type of virtual machine to be deployed…”), in response to the user selection, execute the software/program (see [0101] “Virtual machine control panel 1414 can include intuitive interface controls that allow a user to create, start, stop, or delete virtual machines on cloud platform 1402 directly from the control panel.…These can include, for example, controls for selecting a type of virtual machine to be deployed…”; also, see [0071] “…, virtual machine management templates that allow a user to create, start, stop, or delete virtual machines running/executing on the cloud resources 812…”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar-Govil’s combination as taught above to include a deployment interface providing, via the deployment interface, options to activate, delete, and disable a program/software after the program is loaded in a remote system or controller, receive, via the deployment interface, a user selection to activate the loaded program/software, in response to the user selection, execute the software/program as taught by Lawson in order to allow the selection, activation, deletion, disabling of the firmware extensions programs of Rischar by providing a template or user interface with these functions to facilitate and speed up the process of implementing and executing software in automated systems remotely (see [0008] “…embodiments of the present disclosure relate to the use of cloud templates that allow industrial devices and other client devices to quickly and easily implement cloud-based solutions for industrial automation... cloud templates are provided that can be incorporated in a variety of devices, including but not limited to industrial controllers… Virtual machine management templates are also provided that facilitate creation, deployment, and control of cloud-based virtual machines used to monitor or control portions of an automation system via a cloud platform”).
While CIP objects being used by software programs installed in a PLC controller to obtain information are inherent function/ limitations in Rockwell, Allen Bradley PLC, and other brand of controllers including the Logix controllers ® SLC, PLC-5, Micro800, and while Rischar teaches CIP resources including (00420—0046, see page 21 claim 6 the resources is a CIP connection) and software modules using object files (see 0035), Rischar-Govil-Lawson still does not explicitly teach the firmware extension comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC.
Kenst teaches an industrial automation system comprising application/software comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC (see [0004]; see Fig. 2 applications 220 locate and provide particular information from CIP objects 210, see [0023] “Various types of objects can be provided to support communications between layers and between components of a system. These can include CIP-aware application objects that support interfaces to the CIP core layer 220. Link-specific application objects are instantiated by a communications port within the respective link layer 230. These are standard CIP application objects in that they support data flows for CIP accesses but also allow direct association between that link-specific object and its instantiating port…”; also, see [0024] “The CIP Core 220 provides components for an application to link layer interface. This includes the Connection Manager 250 which facilitates connection creation and management and is a facilitator for unconnected message origination. Transports in the core layer 220 provide the connected data interface between application and link objects. The core layer 220 can also include Message Router Services that encapsulates knowledge of message router request and response formats. The core layer 220 can also include a registry for applications that support CIP (or other network protocol) unconnected message target behavior”; also, see [0025]; also, see Fig. 4 applications/software 420 using CIP objects 430, and see [0027-0029] and see [0031-0033]) and because using CIP objects provides a standardized form of communication and at the same time provides safety and security.
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar-Govil-Lawson’s combination as taught above to include application/software comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC as taught by Kenst in order to apply the use of these objects within the firmware extension of Rischar in order to facilitate the communication of data and perform functions within the PLC and outside the PLC (see “[0028-0029] and [0060]).
As per claim 3, Rischar-Govil-Lawson-Kenst teaches the industrial PLC of claim 2, Rischar further teaches wherein the firmware extension comprises one or more constraints that define circumstances in which the control program calls the external component (see Col 16 lines 1-4 “wherein the loadable module manager is further configured to identify a dependency of the second application module and bind the second application module to a resource of the industrial controller to resolve the dependency…” and see lines 32-35 : wherein the loadable module manager is further configured to determine whether an installation requirement is met before the second application module is permitted…”, thus, dependencies and requirements are constraints that mut be satisfied in order to call the external component or second application; also, see [0015] “…loaded module meets admissibility criteria… Accordingly, admissibility criteria may ensure that new loaded modules do not compromise real time control capabilities of the control system”).
As per claim 4, Rischar-Govil-Lawson-Kenst teaches the industrial PLC of claim 1, Rischar further teaches wherein the firmware lacks a native component to perform the external function (an extension or plug-ins are software/program or code that is invoked/called, loaded and used because the system does not a native component that can perform the function of the extension. If the controller had the capability to perform the function, it would not have to call an extension. Rischar teaches that the extension extend the firmware capabilities. also, see Col 18 lines 25-30 “…wherein the second application module is configured to extend or modify the at least a portion of the operating system without modification to the firmware”).
As per claim 5, Rischar-Govil-Lawson-Kenst teaches the industrial PLC of claim 1, Rischar further teaches wherein the control program, when read and executed by the processing system, further directs the industrial PLC to:
once the external component has performed the external function, receive a result of the external function from the external component (the broadest definition of an extension is a function program that adds additional functionality to a PLC; The disclosure does not gives examples of results, thus, in the broadest reasonable interpretation the results of the external function is the results after executing the executable extension (external component) which comprises any output/result of the executable; see Rischar fig. 3 and see [0052] “The first application module 182 may have a dependency on the second application module 184, and the second application module 184 may have a dependency on the first application module 182…”; also, see [0062]; also, see Col 17 lines 1-3 “wherein the loadable module manager binds the second application module to at least one of the operating system and the first application module…”); and
use the result of the external function to perform at least one additional native function performed by an additional native component of the firmware (see Rischar fig. 3 and see [0052] “The first application module 182 may have a dependency on the second application module 184, and the second application module 184 may have a dependency on the first application module 182…”; also, see [0062] bound and binding the first and second applications; also, see Col 17 lines 1-3).
As per claim 8, Rischar teaches a computing apparatus (see Fig. 1 computing apparatus 50 and 12; also, see [0035]) comprising:
one or more computer-readable storage media (see Fig. 1 memory 34; also, see [0034] “Hardware components of the industrial controllers A and B may each include…a memory 34 and a disk 36 or other form of non-volatile storage, including but not limited to Flash memory and/or solid state drives; also, see Fig. 1 computing apparatus 50 and see [0035]);
a processing system operatively coupled to the one or more computer-readable storage media (see Fig. 1 processor 30 and also, see [0019] and [0028] and [0067] “An industrial controller comprising a processor executing: an operating system stored in non-transient memory for managing hardware components of the industrial controller…”; also, see [0035]); and
program instructions stored on the computer-readable storage media, wherein the program instructions, when read and executed by the processing system (Firmware interpreted in the broadest reasonable interpretation is software/program comprising code or instruction that are executed to provide functions or execute further software of the controller; also, see Fig. 3 PLC 12 and see [0019] “an industrial controller comprises a processor executing: an operating system stored in non-transient memory for managing hardware components of the industrial controller…”; the term “control program” has been interpreted in the BRI in light of the specification as software or operating system executing instructions; also, see [0039] and [0052] “…The first and second application modules 182 and 184 may be modules of a control program running on an industrial controller 40 for controlling a controlled process….” also, see [0035] computer 50 is a computing system for ), direct the computing apparatus to:
generate a firmware extension for an industrial programmable logic controller (PLC), wherein the firmware extension provides an external component to perform an external function, wherein existing firmware lacks a native component to perform the external function (see [0035]);
instruct the industrial PLC to install the firmware extension (see [0035]), using a deployment interface (the deployment interface has been interpreted in BRI in light of disclosure wherein it acquire several definitions based examples such as GUI, a CIP protocol or an extension development environment 111 including a computer, see original disclosure figs. 1-3; Rischar further teaches see Fig.1 interface 42 and see [00034], [0042] , [0040], and see claim 1 above same rationale applies herein), wherein:
the firmware extension is loaded in a(see Fig. 5a the extensions are loaded in an execution environment separated from the OS and the kernel space. The kernel is part of the operating system; also, see [0013] “The present invention provides a "loadable module" architecture for industrial controllers in which new control program modules which provide updated functions or features may be loaded to extend or modify the underlying operating system and/or add or modify other services that are part of the industrial controller without updating the firmware and without disrupting or otherwise compromising the ability of the industrial controller to maintain continuous control over the controlled); and
the firmware extension comprises functionality to locate and provide particular information from each of multiple(se [0035] “source code modules may be delivered and then compiled and linked to create [resulting object modules within the industrial controller”; Also, see [0047], [0051], and [0057])
provide, via the deployment interface, options to activate, (Rischar further teaches in [0040] “…The electronic computer 50 includes a design and configuration environment 100, such as RSLogix 5000 from Rockwell Automation, Inc. The design and configuration environment 100 may employ a graphical user interface or simply a high level computing language such as C++. The user designs, modifies and/or updates the project accordingly and produces a source module 102, which may include source application code, source library code, and/or other source data as generally understood in the art...”, this design environments allow a user the options to send and activate extensions), loaded in the industrial PLC (also, see [0062] “Finally, in a sixth process block 334, the fully bound modules are loaded and executed” an extension or program can only be activated/executed after being loaded);
receive, via the deployment interface, a user selection to activate the firmware extension loaded in the industrial PLC (see Rischar further teaches in [0040] “…The electronic computer 50 includes a design and configuration environment 100, such as RSLogix 5000 from Rockwell Automation, Inc. The design and configuration environment 100 may employ a graphical user interface or simply a high level computing language such as C++. The user designs, modifies and/or updates the project accordingly and produces a source module 102, which may include source application code, source library code, and/or other source data as generally understood in the art...”, this design environments allow a user the options to send and activate extensions, the user select or chooses to send or not send programs to Controllers 12 or 14);
in response to the user selection, execute the firmware extension in the industrial PLC (see [0019-0020] “a loadable module manager stored in non-transient memory configured to receive a second application module… The second application module may be configured to extend …at least a portion of the operating system while the first application module controls the at least a portion of the controlled process…”; also, see [0043] “…source modules, as well as executable and object files, may be loaded…”; see Fig. 3 module manager loads application modules including the extension application modules such as second application module Mod-A2 which is an extension software; also, see [0044] “…Accordingly, the loadable module manager 138 binds and places the application module 134 ("EXECUTABLE") into service among the loaded application modules 140 as a running application module 142 ("MOD_A3"). The running application module 142 ("MOD_A3") may, in turn, extend or modify at least a portion of the operating system while one or more of the loaded application modules 140 continues to control the controlled process”; also, see [0045] “loaded application modules 140”; also, see Col 18 lines 25-30 “…wherein the second application module is configured to extend or modify the at least a portion of the operating system without modification to the firmware”, also, loading is interpreted in the BRI as preparing a program for its execution by copying the instructions in memory for execution. That is the purpose of a loader such as the loadable manager 138”);
provide, to the industrial PLC, a control program comprising logic for controlling an industrial automation process, wherein the logic of the control program directs the industrial PLC to, during execution of the control program (see [0035] and see Fig. 3 PLC 12 and see [0019] “an industrial controller comprises a processor executing: an operating system stored in non-transient memory for managing hardware components of the industrial controller…”; the term “control program” has been interpreted in the BRI in light of the specification as software or operating system executing instructions; also, see [0039] and [0052] “…The first and second application modules 182 and 184 may be modules of a control program running on an industrial controller 40 for controlling a controlled process….”):
call a native component of the firmware to perform a native function (and see Fig. 3 and [0019] “an operating system stored in non-transient memory for managing hardware components of the industrial controller; a first application module stored in non-transient memory for controlling at least a portion of a controlled process via the operating system…”; see [0042] “local firmware… In addition, a resource manager 122 in the industrial controller A may reference a data structure 124, a library manager 126, and a local firmware 128 in the industrial controller A, and provide such resource information to the embedded linker/loader/compiler 120”; also, see Col 20 claim 2 “the operating system is configured to communicate with firmware before managing the hardware components”), wherein the native component of the existing firmware is embedded in hardware of the industrial PLC (see [0042] “local firmware… In addition, a resource manager 122 in the industrial controller A may reference a … a local firmware 128 in the industrial controller A, and provide such resource information to the embedded linker/loader/compiler 120”; thus, the firmware is embedded in hardware of the PLC in an embedded software core 120. The term firmware and embedded software core has been interpreted as suggested in the arguments in the BRI as “the terms "firmware" and "embedded software core" as referring to code that is specifically adapted to particular hardware”); and
call the external component provided by the firmware extension to perform the external function (see Col 16 lines 25-30 “…wherein the second application module is configured to extend or modify the at least a portion of the operating system without modification to the firmware”; also, see [0052]; also, see Col 20 claim 2).
While Rischar teaches that the system can provide virtualization (see 0011) and also teaches a computer with a design environment for the creation of extension applications (see 0035 and Fig. 3 100), Rischar does not explicitly teach the firmware extension is loaded in a virtualized execution environment isolated from an operating system (OS kernel of the industrial PLC,
provide, via the deployment interface, options to delete, and disable the firmware extension, the firmware extension comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC, receive, via the deployment interface, a user selection to activate the firmware extension in the industrial PLC; in response to the user selection, execute the firmware extension in the industrial PLC.
However, Govil teaches a computer system and method comprising steps of virtualization wherein, an extension is loaded in a virtualized execution environment isolated from an operating system (OS) kernel of the controller (see the Abstract “Hardware virtualization support is used to isolate kernel extensions …”; see [0010] “The invention isolates kernel extensions (such as device drivers) using hardware virtualization support. An operating system kernel is protected from a kernel extension by executing the kernel and the kernel extension in separate hardware protection domains”; also, see Fig. 3a-c; also, see [0027] “The memory 110 includes a kernel 600 and at least one kernel extension 604. The kernel 600 is a set of computer instructions (also referred to as "kernel code") comprising the core of an operating system. The kernel 600 may include, for example, computer instructions for managing applications, allocating computer resources, and prioritizing the requirements of the devices 103. The computer instructions of the kernel 600 execute with a special execution privilege level on the CPU 104”; also, see [0028] and [0036], [0041], [0045]-[0048]).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s invention to include steps of virtualization wherein an extension is loaded in a virtualized execution environment isolated from an operating system (OS) kernel of the controller as taught by Govil in order to load and execute the firmware extension isolated from the kernel software of the PLC as taught by Richard in order to protect the operating system and Kernel from any action from the extensions than could damage the OS ?kernel of the controller (see [0010] “An operating system kernel is protected from a kernel extension by executing the kernel and the kernel extension in separate hardware protection domains…”).
Rischar-Govil still does not explicitly teach provide, via the deployment interface, options to delete and disable the firmware extension; receive, via the deployment interface, a user selection to activate the firmware extension in the industrial PLC; in response to the user selection, execute the firmware extension in the industrial PLC.
However, Lawson teaches a system comprising a deployment interface providing, via the deployment interface, options to activate, delete, and disable a program/software (see [0071] “Such applications can include, for example, control panel or dashboard templates that allow an administrator to configure and monitor aspects of a cloud-based industrial system running on cloud resources 812, virtual machine management templates that allow a user to create, start, stop, or delete virtual machines running on the cloud resources 812”, wherein virtual machine are software programs executed in a remote system such as cloud resources/processors and memory…”; also, see [0101] “…When installed and executed on a client device 1406 (or accessed remotely by client device 1406, as in FIG. 8), virtual machine management template 1412 can generate…control panel 1414 can include intuitive interface controls that allow a user to create, start, stop, or delete virtual machines on cloud platform 1402 directly from the control panel. These can include, for example, controls for selecting a type of virtual machine to be deployed, naming the virtual machine, specifying a hostname of a cloud-based host on which the virtual machine is to run, specifying a cloud-based hypervisor that is to perform resource management for the virtual machine, and defining a resource allocation for the virtual machine…”), receive, via the deployment interface, a user selection to activate the program/software (see [0101] “…These can include, for example, controls for selecting a type of virtual machine to be deployed…”), in response to the user selection, execute the software/program (see [0101] “…These can include, for example, controls for selecting a type of virtual machine to be deployed…”; also, see [0071] “…, virtual machine management templates that allow a user to create, start, stop, or delete virtual machines running/executing on the cloud resources 812…”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar-Govil’s combination as taught above to include a deployment interface providing, via the deployment interface, options to activate, delete, and disable a program/software, receive, via the deployment interface, a user selection to activate the program/software, in response to the user selection, execute the software/program as taught by Lawson in order to allow the selection, activation, deletion, disabling of the firmware extensions programs of Rischar by providing a template or user interface with these functions to facilitate and speed up the process of implementing and executing software in automated systems (see [0008] “…embodiments of the present disclosure relate to the use of cloud templates that allow industrial devices and other client devices to quickly and easily implement cloud-based solutions for industrial automation... cloud templates are provided that can be incorporated in a variety of devices, including but not limited to industrial controllers… Virtual machine management templates are also provided that facilitate creation, deployment, and control of cloud-based virtual machines used to monitor or control portions of an automation system via a cloud platform”).
While CIP objects being used by software programs installed in a PLC controller to obtain information are inherent function/ limitations in Rockwell, Allen Bradley PLC, and other brand of controllers including the Logix controllers ® SLC, PLC-5, Micro800, and while Rischar teaches CIP resources including (00420—0046, see page 21 claim 6 the resources is a CIP connection) and software modules using object files (see 0035), Rischar-Govil-Lawson still does not explicitly teach the firmware extension comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC.
Kenst teaches an industrial automation system comprising application/software comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC (see [0004]; see Fig. 2 applications 220 locate and provide particular information from CIP objects 210, see [0023] “Various types of objects can be provided to support communications between layers and between components of a system. These can include CIP-aware application objects that support interfaces to the CIP core layer 220. Link-specific application objects are instantiated by a communications port within the respective link layer 230. These are standard CIP application objects in that they support data flows for CIP accesses but also allow direct association between that link-specific object and its instantiating port…”; also, see [0024] “The CIP Core 220 provides components for an application to link layer interface. This includes the Connection Manager 250 which facilitates connection creation and management and is a facilitator for unconnected message origination. Transports in the core layer 220 provide the connected data interface between application and link objects. The core layer 220 can also include Message Router Services that encapsulates knowledge of message router request and response formats. The core layer 220 can also include a registry for applications that support CIP (or other network protocol) unconnected message target behavior”; also, see [0025]; also, see Fig. 4 applications/software 420 using CIP objects 430, and see [0027-0029] and see [0031-0033]) and because using CIP objects provides a standardized form of communication and at the same time provides safety and security.
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar-Govil-Lawson’s combination as taught above to include application/software comprises functionality to locate and provide particular information from each of multiple, distinct common industrial protocol (CIP) objects in the industrial PLC as taught by Kenst in order to apply the use of these objects within the firmware extension of Rischar in order to facilitate the communication of data and perform functions within the PLC and outside the PLC (see “[0028-0029] and [0060]).
As per claim 9, Rischar-Govil-Lawson-Kenst teaches the computing apparatus of claim 8, Rischar further teaches wherein to instruct the industrial PLC to install the firmware extension, the program instructions, when read and executed by the processing system, direct the computing apparatus to use an industrial communication protocol (the instant application exemplifies an industrial communication protocols as interfaces or API that allow the communication of devices (see original disclosure 0023). Rischar further teaches see [0032] “”…connected together via a control network 16, which may be an EtherNeUIP net-work or other control network and which may implement Common Industrial Protocol (CIP)…”, thus, the computing apparatus uses a CIP protocol).
As to claim 11, this claim is the apparatus claim corresponding to the controller claim 3 and is rejected for the same reasons mutatis mutandis.
As to claim 15, this claim is the method claim corresponding to the controller/apparatus/system claim 1 and is rejected for the same reasons mutatis mutandis.
As to claim 16, this claim is the method claim corresponding to the controller/apparatus/system claim 4 and is rejected for the same reasons mutatis mutandis.
As to claim 18, this claim is the method claim corresponding to the controller/apparatus/system claim 3 and is rejected for the same reasons mutatis mutandis.
As to claim 19, this claim is the method claim corresponding to the controller/apparatus/system claim 5 and is rejected for the same reasons mutatis mutandis.
Claim(s) 2, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rischar et al (EP 3059647) in view of Govil et al (US 20080148048), Lawson et al (US 20130212129) and Kenst et al (US 20080109829) as applied to claims 1, 8, 15, respectively, above, and further in view of Levac et al (US 20190303123).
As per claim 2, Rischar-Govil-Lawson-Kenst teaches the industrial PLC of claim 1, While Rischar teaches loading and installing the extensions into memory space of the PLC controller (see Fig. 3), it does not explicitly teach install the extension from an extension repository, but wherein the firmware extension is loaded from an extension repository comprising a plurality of firmware extensions.
However, Levac teaches a plug-in (extensions) distribution system comprising an extension repository, and a step of install the extension from an extension repository (in the broadest reasonable interpretation a repository is an external data store, database or central system where software such as extensions software/plug-in can be stored and be accessed from. See Levac Fig. 1 extension repository 104; also, see [0002] “…referred to extensions…” also, see [0011] “The first application installs the display plug-in and saves the monitoring plug-in and other files of the installation package to a centralized database. The first application then sends an instruction/command to a second application running on a second computing device to retrieve the monitoring plug-in from the database and install the monitoring plug-in in the second application running on the second computing device”; also, see Fig. 1 and 3 and see [0021] “…Upon receiving such command, the agent program 310 is configured to process the command and to retrieve the monitoring plug-in 206 and its necessary references (i.e., references to common components 208 and/or external libraries 210) from the centralized database 306 as part of stage #3…”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include an extension repository, and a step of install the extension from an extension repository as taught by Levac in order to distribute extension/plug-in software components in a secure manner (see [0002 and [0012] “By distributing and deploying the monitoring plug-in to a remote computing device, the proposed approach supports remote monitoring management (RMM) of the remote computing device...As such, the monitoring plug-in can be deployed dynamically over a network to any client device/endpoint to be monitored remotely for security and other purposes. Compared to manual installation of monitoring agents, such an approach ensures that the monitoring plug-in is always secure, up-to-date, and can be selectively deployed to any remote computing device needs to be monitored at any time”).
As per claim 10, Rischar-Govil-Lawson-Kenst teaches the computing apparatus of claim 8, wherein the program instructions, when read and executed by the processing system, further direct the computing apparatus to:
While Rischar-Govil-Lawson teaches loading and installing the extensions into memory space of the PLC controller (see Fig. 3), Rischar-Govil-Lawson-Kenst does not explicitly teach upload the firmware extension to an extension repository; and prior to instructing the industrial PLC to install the firmware extension, instruct the industrial PLC to download the firmware extension from the extension repository.
However, Levac teaches a plug-in (extensions) distribution system comprising an extension repository, uploading the firmware extension to an extension repository (see [0021] “…At stage #2, the individual files extracted from the plug-in package are saved to a centralized database 306 running on a database server 304 so that the files can be made available to one or more agent programs/distributed applications 310 running on a computing device 308…”), and a step of prior to instructing a controller to install the firmware extension, instruct the controller to download the firmware extension from the extension repository (in the broadest reasonable interpretation a repository is an external data store, database or central system where software such as extensions software/plug-in can be stored and be accessed from. See Levac Fig. 1 extension repository 104; also, see [0002] “…referred to extensions…” also, see [0011] “The first application installs the display plug-in and saves the monitoring plug-in and other files of the installation package to a centralized database. The first application then sends an instruction/command to a second application running on a second computing device to retrieve the monitoring plug-in from the database and install the monitoring plug-in in the second application running on the second computing device”; also, see Fig. 1 and 3 and see [0017] “the plug-in source server 104 can be managed by a plug-in developer and/or provides a library of plug-ins available for download…” and see [0021] “…Upon receiving such command, the agent program 310 is configured to process the command and to retrieve the monitoring plug-in 206 and its necessary references (i.e., references to common components 208 and/or external libraries 210) from the centralized database 306 as part of stage #3…”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include an extension repository, uploading the firmware extension to an extension repository, and a step of prior to instructing a controller to install the firmware extension, instruct the controller to download the firmware extension from the extension repository as taught by Levac in order to distribute extension/plug-in software components in a secure manner (see [0002 and [0012] “By distributing and deploying the monitoring plug-in to a remote computing device, the proposed approach supports remote monitoring management (RMM) of the remote computing device...As such, the monitoring plug-in can be deployed dynamically over a network to any client device/endpoint to be monitored remotely for security and other purposes. Compared to manual installation of monitoring agents, such an approach ensures that the monitoring plug-in is always secure, up-to-date, and can be selectively deployed to any remote computing device needs to be monitored at any time”).
As per claim 17, Rischar-Govil-Lawson-Kenst teaches the method of claim 15, Rischar teaches a memory storing a plurality of extensions (see Fig. 3 modules 140), but it does not explicitly teach wherein the firmware extension is loaded from an extension repository comprising the plurality of extensions.
However, Levac teaches a plug-in (extensions) distribution system comprising an extension repository, uploading the firmware extensions to an extension repository (see [0021] “…At stage #2, the individual files extracted from the plug-in package are saved to a centralized database 306 running on a database server 304 so that the files can be made available to one or more agent programs/distributed applications 310 running on a computing device 308…”), and wherein the firmware extension is loaded from an extension repository comprising the plurality of extensions (in the broadest reasonable interpretation a repository is an external data store, database or central system where software such as extensions software/plug-in can be stored and be accessed from. See Levac Fig. 1 extension repository 104; also, see [0002] “…referred to extensions…” also, see [0011] “The first application installs the display plug-in and saves the monitoring plug-in and other files of the installation package to a centralized database. The first application then sends an instruction/command to a second application running on a second computing device to retrieve the monitoring plug-in from the database and install the monitoring plug-in in the second application running on the second computing device”; also, see Fig. 1 and 3 and see [0017] “the plug-in source server 104 can be managed by a plug-in developer and/or provides a library of plug-ins available for download…” and see [0021] “…Upon receiving such command, the agent program 310 is configured to process the command and to retrieve the monitoring plug-in 206 and its necessary references (i.e., references to common components 208 and/or external libraries 210) from the centralized database 306 as part of stage #3…”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include an extension repository, uploading the firmware extensions to an extension repository, and to download the firmware extension from the extension repository as taught by Levac in order to distribute extension/plug-in software components in a secure manner (see [0002 and [0012] “By distributing and deploying the monitoring plug-in to a remote computing device, the proposed approach supports remote monitoring management (RMM) of the remote computing device...As such, the monitoring plug-in can be deployed dynamically over a network to any client device/endpoint to be monitored remotely for security and other purposes. Compared to manual installation of monitoring agents, such an approach ensures that the monitoring plug-in is always secure, up-to-date, and can be selectively deployed to any remote computing device needs to be monitored at any time”).
Claim(s) 6, 13, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rischar et al (EP 3059647) in view of Govil et al (US 20080148048), Lawson et al (US 20130212129) and Kenst et al (US 20080109829) as applied to claims 1, 8, 15, respectively, above, and further in view of Miyasaka (US 20210240154).
As per claim 6, Rischar-Govil-Lawson-Kenst teaches the industrial PLC of claim 1, wherein the control program, when read and executed by the processing system, further directs the industrial PLC to:
once the external component has performed the external function, receive a result of the external function from the external component (the broadest definition of an extension is a function program that adds additional functionality to a PLC; The disclosure does not gives examples of results, thus, in the broadest reasonable interpretation the results of the external function is the results after executing the executable extension (external component) which comprises any output/result of the executable; see Rischar fig. 3 and see [0052] “The first application module 182 may have a dependency on the second application module 184, and the second application module 184 may have a dependency on the first application module 182…”; also, see [0062]; also, see Col 17 lines 1-3 “wherein the loadable module manager binds the second application module to at least one of the operating system and the first application module…”); and
The combination of Rischar-Govil-Lawson-Kenst does not explicitly teach return the result of the external function to one or more external programs in communication with the industrial PLC controller.
However, Miyasaka a system comprising a PLC with extensions, wherein an external component (extensions) perform function and receive a result of the external function from the external component, return the result of the external function to one or more external programs in communication with the industrial controller (see Fig. 1 and 4 PLC 1 and extensions 4a, 4b. PC 2B and 2a comprises external programs that receive the results; [0040] “An extension unit 4a, for example, is a data utilization unit that collects data to be collected from the basic unit 3 and the extension unit 4b, executes a user program (data utilization program), such as a flow, to perform data processing on the data to be collected and create data to be displayed, and creates display data (source data) for displaying a dashboard on a display part 7 or a PC 2”; also, see [0046]-0047] “<PC Used to Display Dashboard>; also, see [0053] “…a flow for performing processing related to the collected data; a dashboard that displays the execution results of the flows; and a transmission part that transmits the results of the flows to the outside…”; also, see [0166]).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include a PLC with extensions, wherein an external component (extensions) perform function and receive a result of the external function from the external component, return the result of the external function to one or more external programs in communication with the industrial controller as taught by Miyasaka in order to displays the results in an external apparatus to be viewed and/or monitored by an operator (see [0041] “…. The PC 2a may be referred to as a program creation support apparatus (setting apparatus). The PC 2 is, for example, a portable notebook type or tablet-type personal computer or smart phone and is an external computer including the display part 7 and an operation part 8. The external computer is a computer located outside the PLC 1…”; also, see [0095] and [0166]).
As per claim 13, Rischar-Govil-Lawson-Kenst teaches the computing apparatus of claim 8, Rischar further teaches wherein, once the external component has performed the external function, the program instructions (the broadest definition of an extension is a function program that adds additional functionality to a PLC; The disclosure does not gives examples of results, thus, in the broadest reasonable interpretation the results of the external function is the results after executing the executable extension (external component) which comprises any output/result of the executable; see Rischar fig. 3 and see [0052] “The first application module 182 may have a dependency on the second application module 184, and the second application module 184 may have a dependency on the first application module 182…”; also, see [0062]; also, see Col 17 lines 1-3 “wherein the loadable module manager binds the second application module to at least one of the operating system and the first application module…”), when read and executed by the processing system, further direct (see Rischar fig. 3 and see [0052] “The first application module 182 may have a dependency on the second application module 184, and the second application module 184 may have a dependency on the first application module 182…”; also, see [0062] bound and binding the first and second applications; also, see Col 17 lines 1-3; also, see [0035]).
However, Rischar does not explicitly teach the computing apparatus (host computer 50) to receive results from the external functions of the PLC.
However, Miyasaka a system comprising a PLC with extensions, wherein an external component (extensions) perform function and receive a result of the external function from the external component, return the result of the external function to a computing apparatus in communication with the industrial controller (see Fig. 1 and 4 PLC 1 and extensions 4a, 4b. PC 2B and 2a comprises external programs that receive the results; [0040] “An extension unit 4a, for example, is a data utilization unit that collects data to be collected from the basic unit 3 and the extension unit 4b, executes a user program (data utilization program), such as a flow, to perform data processing on the data to be collected and create data to be displayed, and creates display data (source data) for displaying a dashboard on a display part 7 or a PC 2”; also, see [0046]-0047] “<PC Used to Display Dashboard>; also, see [0053] “…a flow for performing processing related to the collected data; a dashboard that displays the execution results of the flows; and a transmission part that transmits the results of the flows to the outside…”; also, see [0166]).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include a PLC with extensions, wherein an external component (extensions) perform function and receive a result of the external function from the external component, return the result of the external function to a computing apparatus in communication with the industrial controller as taught by Miyasaka in order to displays the results in an external apparatus to be viewed and/or monitored by an operator (see [0041] “…. The PC 2a may be referred to as a program creation support apparatus (setting apparatus). The PC 2 is, for example, a portable notebook type or tablet-type personal computer or smart phone and is an external computer including the display part 7 and an operation part 8. The external computer is a computer located outside the PLC 1…”; also, see [0095] and [0166]).
As per claim 14, Rischar-Govil-Lawson-Kenst teaches the computing apparatus of claim 8, Rischar further teaches wherein the logic of the control program further directs the industrial PLC to:
once the external component has performed the external function, receive a result of the external function from the external component (the broadest definition of an extension is a function program that adds additional functionality to a PLC; The disclosure does not gives examples of results, thus, in the broadest reasonable interpretation the results of the external function is the results after executing the executable extension (external component) which comprises any output/result of the executable);
Rischar-Govil-Lawson does not explicitly teach return the result of the external function to one or more external programs in communication with the industrial PLC controller.
However, Miyasaka a system comprising a PLC with extensions, wherein an external component (extensions) perform function and receive a result of the external function from the external component, return the result of the external function to one or more external programs in communication with the industrial controller (see Fig. 1 and 4 PLC 1 and extensions 4a, 4b. PC 2B and 2a comprises external programs that receive the results; [0040] “An extension unit 4a, for example, is a data utilization unit that collects data to be collected from the basic unit 3 and the extension unit 4b, executes a user program (data utilization program), such as a flow, to perform data processing on the data to be collected and create data to be displayed, and creates display data (source data) for displaying a dashboard on a display part 7 or a PC 2”; also, see [0046]-0047] “<PC Used to Display Dashboard>; also, see [0053] “…a flow for performing processing related to the collected data; a dashboard that displays the execution results of the flows; and a transmission part that transmits the results of the flows to the outside…”; also, see [0166]).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include a PLC with extensions, wherein an external component (extensions) perform function and receive a result of the external function from the external component, return the result of the external function to one or more external programs in communication with the industrial controller as taught by Miyasaka in order to displays the results in an external apparatus to be viewed and/or monitored by an operator (see [0041] “…. The PC 2a may be referred to as a program creation support apparatus (setting apparatus). The PC 2 is, for example, a portable notebook type or tablet-type personal computer or smart phone and is an external computer including the display part 7 and an operation part 8. The external computer is a computer located outside the PLC 1…”; also, see [0095] and [0166]).
As to claim 20, this claim is the method claim corresponding to the controller/apparatus/system claim 6 and is rejected for the same reasons mutatis mutandis.
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Rischar et al (EP 3059647) in view of Govil et al (US 20080148048), Lawson et al (US 20130212129) and Kenst et al (US 20080109829) as applied to claim 1 above, and further in view of Smith et al (US 8621632).
As per claim 7, Rischar-Govil-Lawson-Kenst teaches the industrial PLC of claim 1, but it does not explicitly teach wherein the firmware, when read and executed by the processing system, further directs the industrial PLC to check for recently added firmware extensions.
However, Smith teaches a system comprising a processing system comprising instructions when read and executed by the processing system directs a controller to check for recently added extensions (see Col 1 lines 40-45 “the set of interrelated executable objects may include, for example, an executable program and dynamically linked libraries and/or plug-ins associated with the executable program. A monitoring module may identify an executable object recently added to the set of interrelated executable objects (e.g., a recently installed plug-in)”; also, see Col 3 lines 27-37 “monitoring module 114 may be programmed to identify an executable object recently added to the set of interrelated executable objects…”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination to include processing system comprising instructions when read and executed by the processing system directs a controller to check for recently added extensions as taught by Smith in order to detect any recently added firmware extensions as taught by Rischar to detect a malicious behavior caused by the recent added extension and perform a security action (see Col 3 lines 27-37 “monitoring module 114 may be programmed to identify an executable object recently added to the set of interrelated executable objects. Attribution module 116 may be programmed to attribute the malicious behavior to the recently added executable object based on when then recently added executable object was added to the set of interrelated executable objects, and remediation module 118 may be programmed to perform a security action on the recently added executable object. Although illustrated as separate elements, one or more of modules 110 in FIG. 1 may represent portions of a single module or application”).
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Rischar et al (EP 3059647) in view of Govil et al (US 20080148048), Lawson et al (US 20130212129) and Kenst et al (US 20080109829) as applied to claims 8 above, and further in view of Gurikar et al (US 20140130036).
As per claim 12, Rischar-Govil-Lawson teaches the computing apparatus of claim 8, Rischar further teaches wherein the program instructions comprise further instructions, that when read and executed by the processing system, cause the processing system to receive a (see [0040] “…The user designs, modifies and/or updates the project accordingly and produces a source module 102, which may include source application code, source library code, and/or other source data as generally understood in the art”; also, see Fig. 3 design environment and see [0040], [0041], [0042], [0046-0047], [0051], and [0053]. All the firmware, executables, code, operating system are transferred and loaded from a computer 50 to the PLC controllers 12 and 14 by a user. The updating will require a user to choose/select to install the firmware extension again).
Lawson teaches an interface that allows a user to select, start, stop, or delete a program, but Rischar-Govil-Lawson does not explicitly teach to receive a second a user selection of the firmware extension, instructing the industrial PLC to install the firmware extension in response to the second user selection.
However, Gurikar teaches a system comprising code that causes a processing system to receive a second user selection of software program instructing the system or a remote system, to install the software program in response to the second user selection (This has been interpreted as a redeployment. See [0092] “The UI module 206 may obtain the list of all the previous deployments performed by the user from the configuration module 210 and display it to the user. The UI module 206 may also provide the user with options to initiate a new deployment or perform redeployment. In case of a new deployment, the UI module 206 may obtain the list of registered applications and target platforms 104 from the configuration module 210, for which the user is entitled to. In case the user opts for redeployment, then some or all of the necessary details of the previously performed deployment may be loaded in the UI module 206 for the user to incorporate any changes, if deemed necessary by the user”).
Therefore, it would have been obvious to one of ordinary skilled in the art before effective filing date of the claimed invention to which said subject matter pertains to have modified Rischar’s combination as taught above to include code that causes a processing system to receive a second user selection of software program instructing the system or a remote system, to install the firmware extension in response to the second user selection as taught by Gurikar in order to allows a user to redeploy, install, and execute the firmware extension of Rischar when a firmware extension needs to be redeployed when new updates are present or problems occurred during the deploying (see [0006] and see [0032]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon, as cited in PTO form 892, is considered pertinent to applicant's disclosure.
Callaghan (US 7565351) teaches a PLC controller and systems comprising Cip object that provide data or attributes when called (see Col 7 lines 29-35).
Xu et al (US-20160373323-A1) teaches an industrial system comprising CIP objects being object oriented functions wand which provide services or data (see 0014).
Pierce (US 20190049917) teaches a program environment for generating software that use Cip models (0007), wherein CIP encompasses a comprehensive suite of messages and services for the collection of manufacturing automation applications, including control, safety, synchronization, motion, configuration and other information and CIP maximizes compatibility among devices in an industrial system, and typical control networks implementing CIP include EtherNet/IP, DeviceNet, ControlNet and similar networks whose specifications are published and whose protocols are used broadly by a number of manufacturers and suppliers (see 0007).
Viste (US 9921563) teaches a software program that binds to another program, wherein binding occurs when software component depends on (or refers to) another machine-readable component in order to operate.
ODVA "COMMON INDUSTRIAL PROTOCOL (CIP™) AND THE FAMILY OF CIP NETWORKS", teaches that Cip is a standard and object oriented platform that provides a plurality of CIP objects to perform different functions or methos (see page 12-14, 16), and which provides the ability to mix safety devices and standard devices (see page 8).
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. Applicant must also show how the amendments avoid or differentiate from such references or objections. See 37 CFR 1.111 (c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLVIN LOPEZ ALVAREZ whose telephone number is (571) 270-7686 and fax (571) 270-8686. The examiner can normally be reached Monday thru Friday from 9:00 A.M. to 6:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Robert Fennema, can be reached at (571) 272-2748. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/O. L./
Examiner, Art Unit 2117
/ROBERT E FENNEMA/Supervisory Patent Examiner, Art Unit 2117
Prosecution Insights