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 . Claim 14 was added as a new claims and claims 1-13 were amended. Therefore,, Claims 1-14 are pending in this Application.
Response to Amendments/Remarks
Applicant’s argument/remarks, on page 7, with respect to objections to the specification have been fully considered and are persuasive. Therefore, objections to the specification have been withdrawn due to the amendments. The amendments to the specification of 7/02/2026 are entered since no new matter has been introduced.
Applicant’s argument/remarks, on page 7, with respect to rejections to the claims under 35 USC § 112(a) have been fully considered and are persuasive. Therefore, rejections to the claims under 35 USC § 112(a) have been withdrawn.
Applicant’s argument/remarks, on pages 7-8, with respect to rejections to claims 1-13 under 35 USC § 101 have been fully considered but they are respectfully unpersuasive. Therefore, rejections to the claims have been maintained.
On page 8, the Applicant argues that:
“Step 2A, Prong Two: Even if an Abstract Idea Were Recited, Amended Claim 1 Integrates Any Abstract Idea Into a Practical Application…
But amended claim I does not stop at detecting or identifying an error based on the ruleset. Rather, amended claim I further recites taking concrete action to address the detected error by preventing use of the function module in the modular industrial plant and "displaying the error via a graphical user interface to prompt remediation of the error." Thus, even if the recited steps involve a mental process as the Office Action contends, the claim uses such steps in a practical engineering workflow that prompts correction of the faulty function module before deployment… The claimed prevention of use and GUI-based display of the error to prompt remediation further tie the verification to a concrete engineering workflow for correcting the function module before deployment, thereby improving the reliability of modular industrial plant engineering, enabling detecting and remediation of problems earlier on in the process when they are more readily addressed”. These arguments are unpersuasive.
In response to the arguments above, “Displaying an error to prompt remediation” does not integrate the abstract idea into a practical application because it simply displays results of the analyses. The courts have provided examples that have indicated may not be sufficient to show an improvement to technology include: “…iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48” (see MPEP 2106.05(a)II iii); also, see MPEP 2106.05(h) vi “Limiting the abstract idea of collecting information, analyzing it, and displaying certain results of the collection and analysis to data related to the electric power grid”). Also, outputting data or the results of an analysis is simply an insignificant extra solution activity including a post-solution activity (see MPEP 2106.05(g)). The claimed subject matter as recited does not include any automatic “concrete action to address the detected error by preventing use of the function module”.
On page 9-10, the Applicnat further argues that:
“B. Step 2B: Amended claim 1 recites significantly more than an abstract idea…
Amended claim 1 recites significantly more than any alleged abstract idea because the ordered combination of limitations provides a specific improvement to the technical field of industrial automation engineering, namely, design-stage verification and validation of control software in the form of function modules for modular industrial process plants…
Claim 1 addresses that technical deficiency by with a ruleset of requirements for I/O channels and connections that are necessary conditions for the function module to perform its intended function, checking the function module's 1/O channels and connections against those technical requirements, and determining that the function module design has an error when the requirements are not met…. These limitations are not generic computer implementation of a result. Instead, they are directed to the internal technical structure of industrial control software, including I/O channels that represent parameters and/or variables used for communication between logics and between the function module and the modular industrial plant...”. These arguments are respectfully unpersuasive.
In response to the arguments above, the order of the combination of steps which include the collection of data, evaluation/checking and judgment which are steps are not significantly more than any alleged abstract idea because the order of steps is simply a logical order of steps to perform the abstract idea. The order of steps doe not improve a system. Collecting the data from the software and then comparing it against a ruleset, is the same as obtaining the ruleset first and then obtaining the data from the software for the purpose of performing a comparison.
Also, the Applicant argues that the limitations are directed to the “internal structure of industrial control software, including I/O channels that represent parameters and/or variables used for communication”. This simply represents data collection from software. However, the claims do not recite the details how the data is collected. This is not different than running a software and debugging a software to find errors in the structure of piece of software. As explained in the rejection, finding errors in the design of software was a step that could be easily done by simply looking at the software code. The invention is simply directed to the automatization of finding the error by using a computer. The computer retrieves a database of a set rules (ruleset) and compares the observed data against the ruleset. Again, as explained in the rejection, these steps can be easily performed by a person by simply comparing the data from the software and the ruleset.
On page 10, the Applicant argues that:
“The claim also recites significant post-detection action that confines the alleged abstract idea to a particular useful technological application. When a rule is not met, amended claim 1 recites determining that the function module design has an error, preventing use of the function module in the modular industrial plant, and displaying the error via a graphical user interface to prompt remediation of the error. The Specification discloses that the system may refuse to upload faulty function module software to hardware of a physical process module, alert the designer to the concrete identified error, and force remediation before use…
The claim improves the technical process for engineering modular industrial plants by verifying whether function-module 1/0 channels and connections satisfy technical requirements needed for intended plant operation, blocking use of faulty function module software, and presenting the specific error through a GUI to prompt remediation.”. These arguments are unpersuasive.
Displaying the error is simply an insignificant post-solution activity of outputting data. The claims does not recite any specific steps tom refuse to upload faulty function module software to hardware of a physical process module, alert the designer to the concrete identified error, and force remediation before use. Again, these steps, even if recited in the claims, would be an insignificant post-solution activity of outputting data or mere instructions to apply an exception. (See MPEP 2106.05(f)(1) “the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished). For instance, the claims do not recite any specific structure or step to prevent the use of the function module, and it seems that this function is achieved by simply outputting an error or alert that there is a problem in the software. The disclosure paragraph [0005] clearly suggests that the invention is directed to the checking of software in the testing phase and there is no communication to a possible physical module. Thus, the “prevention use of the function module/software” is simply an intended result or idea of a solution and not a specific programmed function within the system. as long as an error is found and provided, the software will never be deployed. Thus the arguments are respectfully unpersuasive.
Applicant’s argument/remarks, on pages 12-13, with respect to rejections to claims 1-13 under 35 USC § 102(a)(1) and 103(a) have been fully considered but they are unpersuasive. Therefore, rejections to the claims have been maintained.
On page 12, the Applicant argues that:
“With respect to amended claim 1, Stump does not relate to a modular industrial plant, much less verifying a design of a "function module" used in a modular process plant, the function module being built to run on a physical process module of the modular industrial plant as amended claim 1 recites. Stump further fails to disclose a "ruleset" as claimed that specifies requirements for I/O channels and connections for the function module to perform an intended function in a modular industrial plant. Instead, Stump discloses running tests scripts with simulated test inputs and expected responses to detect proper operation and to debug. (Paragraphs [0086]-[0087].) Stump thus fails to disclose using such a "ruleset" in the manner recited in each step of the claim to verify the design of the modular industrial plant function module”. These arguments are respectfully unpersuasive.
Stump clearly teaches that the intended use of the project software is a modular plant (see Fig. 1 industrial and modular components or devices to control a plant; also, see 0055 “Based on design and programming input from one or more developers 304, IDE system 202 generates a system project 302 comprising one or more project files. The system project 302 encodes one or more of control programming; HMI, AR, and/or VR visualizations; device or sub-system configuration data (e.g., drive parameters, vision system configurations, telemetry device parameters, safety zone definitions, etc.); or other such aspects of an industrial automation system being designed…; also, see [0066] “bottling plant”; also, see [0091]). The function module is suggested as software in the instant Application (see PGPUB 0004, [0005] “A function module is software that is built to run on a physical process module of the modular industrial plant”; also, see 0036). Stump clearly teaches a function module that is software that is built to run on a physical process module of the modular industrial plant (see Stump [0033], [0056] and see [0074] “the system project 302 generated by IDE system 202 for a given automaton system being designed can be built upon an object-based architecture that uses automation objects 222 as building blocks.).
In response to the argument that Stump further fails to disclose a "ruleset" as claimed that specifies requirements for I/O channels and connections for the function module to perform an intended function in a modular industrial plant, Stump clearly teaches in the broadest reasonable interpretation in light of the disclosure a ruleset (see 0086-0087 “one or more test scripts 902 associated with respective one or more automation objects 222 against system project 302… verifying data linkages between control routines, verifying relationships between program elements and drawing elements, confirming that device configuration settings or parameter values are appropriate for a given industrial application being carried out by the system project 302… thus, ruleset are rules or tests scripts with rules to validate/verify linkages/connections of the function module routines, and the requirements (parameter values, setpoints, units, ranges or settings) for I/O channels which are parameter or variables are appropriate; also, see [0088], [0089], [0090]; also, see [0091] “Some embodiments of the IDE system 202 can also include a commissioning component 212 configured to generate a validation checklist based on analysis of the system project 302 and output this validation checklist via the user interface component 204. FIG. 10 is a diagram illustrating generation of validation checklist data 1008 according to one or more embodiments. Commissioning component 212 analyzes the system project to determine on-site tests and checks that should be performed in connection with commissioning the automation system for which system project 302…”). Thus, the arguments are found to be unpersuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract without significantly more.
Claim 1, recites in part:
“..method for verifying a design of a function module for use in a modular industrial plant…;
obtaining a ruleset comprising at least requirements for I/O channels and connections that are necessary conditions for the function module to perform an intended function in the modular industrial plant;
checking whether the input/output channels of the function module and their connections meet the rules in the ruleset; and
in response to determining that at least one rule in the ruleset is not met, determining that the design of the function module has an error and preventing use of the function module in the modular industrial plant”
Under the broadest reasonable interpretation, the terms of the claim are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP 2111.
These limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers steps of obtaining/collecting data, evaluation/checking and judgment which are steps that can be easily performed mentally and belong to the group of mental processes abstract idea but for the recitation of generic components or terms such as computer implemented. That is other, than reciting “a computer implemented method” without reciting the computer, nothing in the claim precludes these steps from practically being performed in the human mind. However, the courts do not distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer (see 2106.04III). Thus, the claims recites a mental process. For instance, a programmer given a program can easily identify or visualize and determine that there are errors in a program by simply comparing rules/semantics/syntax of the program with the received program and the programmer can prevent the use of the design program by not signing off on the approval of the document. Thus, a user can perform the steps by using his mind and pen and paper.
This judicial exception is not integrated into a practical application because the additional elements such as “verifying a design of a function module for use in a modular industrial plant, wherein the function module is software that is built to run on a physical process module of the modular industrial plant comprises control logic configured to accept sensor data and actuate the physical process module such that at least one process quantity and/or state quantity of the physical process module can be kept near a desired set-point value, the function module further comprising logic to accept commands from a superordinate management system, and communication between logics and between the function module and a rest of the modular industrial plant through input/output (I/O) channels representing parameters and/or variables” recited at a high level of generality simply represents a program or design/template for a controller, and represents no more than instructions to generally link the use of the judicial exception to the verification/validation of programs of a technological environment of function module programs which cannot provide an inventive concept as stated by the courts (see MPEP 2106.05(f) and 2106.05(h)). The additional limitations of obtaining a ruleset (rules) of requirements refers to the collection of data to be used in the abstract idea for comparison and which is recited in a high level of generality and is considered insignificant extra solution and pre-solution activities of mere data gathering (see MPEP 2106.05(g)). The additional element of preventing the use of a functional module/software in a modular plant, which is recited at high level of generality, is an insignificant extra solution activity of intended use of the abstract idea (see 2106.05(g)-(h)). The additional element of “Displaying the error via a GUI to prompt remediation”, recited at high level of generality, does not integrate the abstract idea into a practical application because it simply displays results of the analyses, and simply represents an insignificant post-solution activity of outputting data. The courts have provided examples that have indicated may not be sufficient to show an improvement to technology include: “…iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48” (see MPEP 2106.05(a)II iii); also, see MPEP 2106.05(h) vi “Limiting the abstract idea of collecting information, analyzing it, and displaying certain results of the collection and analysis to data related to the electric power grid”). Also, outputting data or the results of an analysis is simply an insignificant extra solution activity including a post-solution activity of outputting data (see MPEP 2106.05(g)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “verifying a design of a function module for use in a modular industrial plant, wherein the function module is software that is built to run on a physical process module of the modular industrial plant and comprises control logic configured to accept sensor data and actuate a physical process module such that at least one process quantity and/or state quantity of the process module can be kept near a desired set-point value, the function module further comprising logic to accept commands from a superordinate management system, and communication between logics and between the function module and a rest of the modular industrial plant through input/output (I/O) channels representing parameters and/or variables” recited at a high level of generality simply represents a program or design/template for a controller, and represents no more than instructions to generally link the use of the judicial exception to the verification/validation of programs of a technological environment of function module programs which cannot provide an inventive concept as stated by the courts (see MPEP 2106.05(f) and 2106.05(h)). The additional limitations of obtaining a ruleset (rules) of requirements refers to the collection of data to be used in the abstract idea for comparison and which is recited in a high level of generality and is considered insignificant extra solution and/or pre-solution activities of mere data gathering (see MPEP 2106.05(g)). The additional element of preventing the use of a functional module/software in a modular plant, which is recited at high level of generality, is an insignificant extra solution activity of intended use of the abstract idea (see 2106.05(g)-(h)) which is a very well understood and conventional activity in the commissioning (validation, debugging, verification, and installation) of software. For instance, Stump et al (US 20210096824) teaches a system for preventing the use of a software program until the program is verified and/r signed off (see [0087-0092] when the function module/project program has issues the program is not signed off until it is debugged, validated, and/or verified and signed off/approved; also, see [0099]). The additional element of “Displaying the error via a GUI to prompt remediation”, recited at high level of generality, represents an insignificant post-solution activity of outputting data. The courts have provided examples that have indicated may not be sufficient to show an improvement to technology include: “…iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48” (see MPEP 2106.05(a)II iii); also, see MPEP 2106.05(h) vi “Limiting the abstract idea of collecting information, analyzing it, and displaying certain results of the collection and analysis to data related to the electric power grid”). Also, outputting data or the results of an analysis is simply an insignificant extra solution activity including a post-solution activity of outputting data (see MPEP 2106.05(g)). Accordingly, these additional elements do not integrate the abstract idea into a practical application, do not amount to significantly more than the judicial exception, and do not impose any meaningful limits on practicing the abstract idea. Therefore, the claims are not patent eligible.
Claims 2-14 depend from claim, and thus recite or inherit the limitations and the abstract ideas of their parent claim.
Claims 2-11 also recites additional elements that simply cover the abstract ideas described above and simply expands the abstract ideas and cover elements of mere data collection/gathering (claim 2 ruleset,) and the claims are abstract idea of itself (claim 3, abstract idea of itself that involves collection of data, comparison and judgement), (claim 4, abstract idea of itself that involves collection of data, comparison and judgement), (claim 5, abstract idea of itself that involves collection of data, comparison and judgement), (claim 6, abstract idea of itself that involves collection of data, comparison and judgement), (claim 7, abstract idea of itself that involves collection of data, comparison and judgement), (claim 8, abstract idea of itself that involves collection of data, comparison and judgement), (claim 9, abstract idea of itself that involves collection of data, comparison and judgement), (claim 10, abstract idea of itself that involves collection of data, comparison and judgement), (claim 11, abstract idea of itself that involves collection of data, comparison and judgement). Accordingly, these additional elements do not integrate the abstract idea into a practical application, do not amount to significantly more than the judicial exception, and do not impose any meaningful limits on practicing the abstract idea of claim 1. Therefore, the claims are not patent eligible.
Claim 12 recites the additional element of executing the function module in a virtualized execution environment, and monitoring, during the execution of the function module, at least one input/output channel, property of a node in the topology of the function module, and/or state of at least one service, which represents the use of a computer to monitor and perform the abstract idea of checking the function module using a computer and a simulation recited at high level of generality represents no more than instructions “to apply” the abstract idea on a computer or to generally link the use of the judicial exception to the technological environment of a computer which cannot provide an inventive concept as stated by the courts (see MPEP 2106.05(f) and 2106.05(h). Accordingly, these additional elements do not integrate the abstract idea into a practical application, do not amount to significantly more than the judicial exception, and do not impose any meaningful limits on practicing the abstract idea of claim 1. Therefore, the claims are not patent eligible.
Claim 13 recites the additional limitations of “in response to determining that the design of the function module has no error: approving the function module for use in the modular industrial plant, and executing an industrial process on the modular industrial plant with participation of this function module. These additional element of preventing the use of a functional module/software in a modular plant, which is recited at high level of generality, is an insignificant extra solution activity of intended use of the abstract idea (see 2106.05(g)-(h)). The additional element of preventing the use of a functional module/software in a modular plant, which is recited at high level of generality, is an insignificant extra solution activity of intended use of the abstract idea (see 2106.05(g)-(h)) which is a very well understood and conventional activity in the commissioning (validation, debugging, verification, and installation) of software. For instance, Stump et al (US 20210096824) teaches a system for preventing the use of a software program until the program is verified and/r signed off (see [0087-0092] when the function module/project program has issues the program is not signed off until it is debugged, validated, and/or verified and signed off/approved; also, see [0099]). Jundt et al (US 20180224832) teaches a system for commissions software modules wherein only approved modules are downloaded and executed on controllers (see [0066] and [0176]) Accordingly, these additional elements do not integrate the abstract idea into a practical application, do not amount to significantly more than the judicial exception, and do not impose any meaningful limits on practicing the abstract idea. Therefore, the claims are not patent eligible.
Claim 14 recites the additional limitations of “creating an error report including any identified errors; and wherein displaying the error via a graphical user interface includes displaying the identified errors of the error report”, and which is recited at high level of generality, and simply represents an insignificant extra solution activity including a post-solution activity of outputting data. The courts have provided examples that have indicated may not be sufficient to show an improvement to technology include: “…iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48” (see MPEP 2106.05(a)II iii); also, see MPEP 2106.05(h) vi “Limiting the abstract idea of collecting information, analyzing it, and displaying certain results of the collection and analysis to data related to the electric power grid”). Also, outputting data or the results of an analysis is simply an insignificant extra solution activity including a post-solution activity of outputting data (see MPEP 2106.05(g)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 and 13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stump et al (US 20210096824, cited in the IDS).
As per claim 1, Stump teaches a computer-implemented method for verifying a design of a function module for use in a modular industrial plant (see [0062] “‘some embodiments of IDE system 202 can support goal-based automated programming. For example, the user interface component 204 can allow the user to specify production goals for an automation system being designed (e.g., specifying that a bottling plant being designed must be capable of producing at least 5000 bottles per second during normal operation) and any other relevant design constraints applied to the design project (e.g., budget limitations, available floor space, available control cabinet space, etc.). Based on this information, the project generation component 206 will generate portions of the system project 302 to satisfy the specified design goals and constraints. Portions of the system project 302 that can be generated in this manner can include, but are not limited to, device and equipment selections (e.g., definitions of how many pumps, controllers, stations, conveyors, drives, or other assets will be needed to satisfy the specified goal), associated device configurations (e.g., tuning parameters, network settings, drive parameters, etc.), control coding, or HMI screens suitable for visualizing the automation system being designed”; also, see [0091] “… the IDE system 202 can also include a commissioning component 212 configured to generate a validation checklist based on analysis of the system project 302 and output this validation checklist via the user interface component 204…” ; also, see Fig. 2 the IDE system 202 and see [0047] and [0052] teaches a computer implemented method; also, see Fig. 5 the function module or project 302 includes software, see [0055]),
wherein the function module is software that is built to run on a physical process module of the modular industrial plant and comprises control logic configured to accept sensor data and actuate the physical process module such that at least one process quantity and/or state quantity of the physical process module can be kept near a desired set-point value (see [0033], [0056] and see [0074] “the system project 302 generated by IDE system 202 for a given automaton system being designed can be built upon an object-based architecture that uses automation objects 222 as building blocks. FIG. 6 is a diagram illustrating an example system project 302 that incorporates automation objects 222 into the project model. In this example, various automation objects 222 representing analogous industrial devices, systems, or assets of an automation system (e.g., a process, tanks, valves, pumps, etc.) have been incorporated into system project 302 as elements of a larger project data model 602. The project data model 602 also defines hierarchical relationships between these automation objects 222…Each automation object 222 has associated therewith object properties or attributes specific to its corresponding industrial asset (e.g., those discussed above in connection with FIG. 4), including executable control programming for controlling the asset (or for coordinating the actions of the asset with other industrial assets) and visualizations that can be used to render relevant information about the asset during runtime.”; also, see [0076] “..Project deployment component 208 can compile or otherwise translate a completed system project 302 into one or more executable files or configuration files that can be stored and executed on respective target industrial devices of the automation system (e.g., industrial controllers 118,…”; [0103] “…This can include setting or resetting digital data tags or writing new analog values (e.g., setpoints) to analog data tags….”; also, see Fig. 6 the system; [0128] “…the term PLC or automation controller as used herein can include functionality that can be shared across multiple components, systems, and/or networks. As an example, one or more PLCs or automation controllers can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, Input/Output (I/O) device, sensor, actuator, and human machine interface (HMI) that communicate via the network, which includes control, automation, and/or public networks…”),
the function module further comprising logic to accept commands from a superordinate management system (the project/program once is deployed to the physical modules (118, 306, PLC, assets,) accept commands from other controllers in a hierarchical manner, see Fig. 7 and see [0036] “…HMIs 114 can also be configured to allow operators to submit data to specified data tags or memory addresses of the industrial controllers 118, thereby providing a means for operators to issue commands to the controlled systems (e.g., cycle start commands, device actuation commands, etc.), to modify setpoint values, etc. HMIs 114 can generate one or more display screens through which the operator interacts with the industrial controllers 118, and thereby with the controlled processes and/or systems …”; also, see [0128]), and communication between logics (see Fig. 4-5 and Fig. 6; also, see [0087] “…verifying data linkages between control routines, verifying relationships between program elements and drawing elements, confirming that device configuration settings or parameter values are appropriate for a given industrial application being carried out by the system project 302,…”) and between the function module and a rest of the modular industrial plant through input/output (I/O) channels representing parameters and/or variables (see [0087]-[0088] and see [0128] “the term PLC or automation controller as used herein can include functionality that can be shared across multiple components, systems, and/or networks. As an example, one or more PLCs or automation controllers can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, Input/Output (I/O) device, sensor, actuator, and human machine interface (HMI) that communicate via the network, which includes control, automation, and/or public networks. The PLC or automation controller can also communicate to and control various other devices such as standard or safety-rated I/O modules including analog, digital, programmed/intelligent I/O modules, other programmable controllers, communications modules, sensors, actuators, output devices, and the like.”, all of the previous limitations are an intended sue of the software module checked before is used in a real or physical process module ), the method comprising:
obtaining a ruleset comprising at least requirements for I/O channels and connections that are necessary conditions for the function module to perform an intended function in the modular industrial plant (see [0086-0087] “According to an example testing procedure, project testing component 210 can execute one or more test scripts 902 associated with respective one or more automation objects 222 against system project 302… verifying data linkages between control routines, verifying relationships between program elements and drawing elements, confirming that device configuration settings or parameter values are appropriate for a given industrial application being carried out by the system project 302, or otherwise interacting with system project 302 according to testing procedures defined by the test scripts 902. During testing, the project testing component 210 can monitor test results 906 or responses of the system project 302 to the test interactions defined by the test scripts 902 and determine whether these test results 906 match expected results defined by the test scripts 902. In this way, proper operation of the system project 302 can be verified prior to deployment without the need to develop custom test scripts to debug the system project code.”; thus, ruleset are rules or tests scripts with rules to validate/verify linkages/connections of the function module routines, and the requirements (parameter values, setpoints, units, ranges or settings) for I/O channels which are parameter or variables are appropriate; also, see [0088], [0089], [0090]; also, see [0091] “Some embodiments of the IDE system 202 can also include a commissioning component 212 configured to generate a validation checklist based on analysis of the system project 302 and output this validation checklist via the user interface component 204. FIG. 10 is a diagram illustrating generation of validation checklist data 1008 according to one or more embodiments. Commissioning component 212 analyzes the system project to determine on-site tests and checks that should be performed in connection with commissioning the automation system for which system project 302 is being developed. These validation checks may comprise tests that should be performed on the automation system's hardware, electrical connections, and responses to control routines that cannot be performed via software testing of the system project 302 alone”; checklist is ruleset or set of rules; also, [0092] “…i/o points (e.g., digital and analog inputs and outputs) defined by the control programming or 1/0 module configurations of industrial controllers that make up the automation system”);
checking whether the input/output channels of the function module and their connections meet the rules in the ruleset (see [0086-0092]; thus, rule set are rule or tests scripts with rules to validate/verify/check linkages/connections of the function module routines, and the requirements (parameter values, setpoints, units, ranges or settings) for I/O channels which are parameter or variables are appropriate; also, see [0092] “…commissioning component 212 can examine system project 302 to identify I/O points (e.g., digital and analog inputs and outputs) defined by the control programming or I/O module configurations of industrial controllers that make up the automation system, and translate these I/O points to an I/O verification checklist that can be used by an on-site engineer to track which I/O points have had their electrical paths from the controller to their corresponding field devices verified. Commissioning component 212 may also identify control routines defined in the system project 302 whose operation should be verified in the field prior to putting the automation system online, and list these routines—together with instructions as to how the routines should be exercised and validated—as part of the validation checklist data 1008”); and
in response to determining that at least one rule in the ruleset is not met, determining that the design of the function module has an error and preventing use of the function module in the modular industrial plant (see [0046] “… commissioning features supported by the industrial IDE can facilitate intelligent deployment of the system project to appropriate industrial devices (e.g., industrial controllers, drives, HMI terminals, etc.). In some embodiments, the IDE system can generate validation checklists that can be used during commissioning to validate the system and manage project validation sign-off procedures…”; also, [0087-0092] and see [0087] and [0089] “the test results 906 indicate an improper operation of one or more aspects of system project 302, project testing component 210 may generate and render one or more design recommendations 908 indicating possible modifications to the system project 302 that would correct operation of the project. These design recommendations 908 may include, for example, control code modifications or replacements, recommended corrections of data tag addresses, recommended corrections to HMI graphical object references, recommended corrections to mechanical or electrical drawings for consistency with the control code (e.g., to add a missing output device to an electrical drawing corresponding to an output device referenced by the control programming), recommended modifications to an industrial device's configuration parameters, or other such corrections”; , thus, when error or improper operation the system does not deploy the function module until the program/function module is fixed/corrected; also, see “…[0092] “Commissioning component 212 may also identify control routines defined in the system project 302 whose operation should be verified in the field prior to putting the automation system online, and list these routines—together with instructions as to how the routines should be exercised and validated—as part of the validation checklist data 1008”; commissioning and verification are steps that involve the prevention of uploading/downloading software to controller unless the modules are validated/verified and signed off; also, see [0099] “… the IDE system's project deployment component 208 can be configured to deploy components of system project 302 (e.g., control code, HMI visualization applications, device configurations, etc.) to their corresponding field devices only after all necessary signatures 1104 indicating approval of those components have been received by the commissioning component 212”), and displaying the error via a graphical user interface to prompt remediation of the error (see [0049] “User interface component 204 can be configured to receive user input and to render output to the user in any suitable format (e.g., visual, audio, tactile, etc.)… Output data rendered by various embodiments of user interface component 204 can include program code, programming feedback (e.g., error and highlighting, coding suggestions, etc.), programming and visualization development screens, project testing results, etc.”; also, see [0067], [0087], and [0089] “] If the test results 906 indicate an improper operation of one or more aspects of system project 302, project testing component 210 may generate and render one or more design recommendations 908 indicating possible modifications to the system project 302 that would correct operation of the project. These design recommendations 908 may include, for example, control code modifications or replacements, recommended corrections of data tag addresses, recommended corrections to HMI graphical object references,… recommended modifications to an industrial device's configuration parameters, or other such corrections”).
As per claim 13, Stump teaches the method of claim 1, further comprising: Stump further teaches in response to determining that the design of the function module has no error (see [0087-0092] when the function module/project program has issues the program is not signed off until it is debugged, validated, and/or verified and signed off/approved; also, see [0099]): approving the function module for use in the modular industrial plant (see commissioning and verification are steps that involve the prevention of uploading/downloading software to controller unless the modules are validated/verified and signed off; sign-off suggest approving the model; see [0046] “… commissioning features supported by the industrial IDE can facilitate intelligent deployment of the system project to appropriate industrial devices (e.g., industrial controllers, drives, HMI terminals, etc.). In some embodiments, the IDE system can generate validation checklists that can be used during commissioning to validate the system and manage project validation sign-off procedures…”; see [0051]; see [0099] “At the IDE system 202, the digital signatures 1104 are received from the client device, and commissioning component 212 maintains a record of the received signatures 1104 as sign-off tracking data 1102, which tracks which signatures 1104 have been received for each item on the validation checklist, and from whom the signatures 1104 have been received. This sign-off tracking data 1102 can subsequently be referenced for auditing purposes. In some embodiments, the IDE system's project deployment component 208 can be configured to deploy components of system project 302 (e.g., control code, HMI visualization applications, device configurations, etc.) to their corresponding field devices only after all necessary signatures 1104 indicating approval of those components have been received by the commissioning component 212.”);
and executing an industrial process on the modular industrial plant with participation of this function module (commissioning and verification are steps that involve the prevention of uploading/downloading software to controller unless the modules are validated/verified and signed off, see [0099] “…see [0099] “… the IDE system's project deployment component 208 can be configured to deploy components of system project 302 (e.g., control code, HMI visualization applications, device configurations, etc.) to their corresponding field devices only after all necessary signatures 1104 indicating approval of those components have been received by the commissioning component 212”).
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) 2 is rejected under 35 U.S.C. 103 as being unpatentable over Stump (US 20210096824, cited in the IDS) in view of Manolios et al (EP 3107017).
As per claim 2, Stump teaches the method of claim 1, While Stump teaches that rules and checklists of rules are checked, validated and verified (0046, 0066, 0087), and while some of the following rules are widely used in software modules, Stump does not explicitly teach wherein at least one rule in the ruleset stipulates that:
all parameters and/or variables must have a measurement unit attached;
and/or whenever a parameter and/or variable is passed from one logic or entity to another, the measurement unit associated with this parameter and/or variable on the sending end must match the measurement unit associated with this parameter and/or variable on the receiving end;
and/or nested ranges for parameters and/or variables must be consistent;
and/or set-points for parameters and/or variables must be in the allowed range for these parameters and/or variables;
and/or values to be written to a parameter and/or variable must be compatible with the type of the parameter and/or variable;
and/or connections between entities are all between an output channel of the one entity and an input channel of the other entity;
and/or all input channels that are required for operation of the function module and/or of one of its logics are connected.
However, Manolios teaches a system for validating and verifying requirements for a software module comprising at least one rule in the ruleset stipulates that (rule has been interpreted in the BRI in light of the disclosure as requirements or constraint for the software program or parameter/variables in the software program; Manolios teaches a system for validating and verifying a plurality of requirements/rules , 0004, 0007, 0011, 0021 a system, 0022-0027): all parameters and/or variables must have a measurement unit attached (see [0098] “…the rationale is for applying the set conflicting analysis is that when one set of requirements states that a controlled variable must have one value, while another set of requirements states that it must have a different value, a conflict exists.”), values to be written to a parameter and/or variable must be compatible with the type of the parameter and/or variable (see [0041] “the requirements to determine that all ex-
10 pressions used to formalize the requirements are well typed, as specified by semantic typing rules. This analysis may catch errors such as assigning a single float to a double, a variable that is in units of mph (miles/hr) to one in kph {km/hr),
etc. In one or more embodiments, after identification of a type-safe error by the type-safety module 302, the error localization module 303a may isolate errors by highlighting the type violations in the requirements and may provide an error explanation 305a including a counter-example...”; also, see [0079], [0080]) or set-points for parameters and/or variables must be in the allowed range for these parameters and/or variables ([0042]; the rules are in the alternative, thus only one is sufficient to read in the claims).
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 Stump’s invention to include at least one rule in the ruleset stipulates that: all parameters and/or variables must have a measurement unit attached, values to be written to a parameter and/or variable must be compatible with the type of the parameter and/or variable, or set-points for parameters and/or variables must be in the allowed range for these parameters and/or variables as taught by Manolios in order to validate or verify a function module to determine errors with respect to the at least one rule above and allow a user to correct the error (see [0002], [0054] “…The determination of the dependent core of requirements may indicate to the user the cause of the independence failure and how to correct…”; [0100]) at the earliest time to reduce costs (see [0001] and [0008] “… Typically, the larger the distance between error introduction and error discovery, the larger the cost associated with fixing the error”).
Claim(s) 3-5 are rejected under 35 U.S.C. 103 as being unpatentable over Stump (US 20210096824, cited in the IDS) in view of Vincent et al (US 20010049682).
As per claim 3, Stump teaches the method of claim 1, while Stump teaches that the design of function module is represented by a graph/hierarchically represented 9see Fig. 10 302), Stump does not explicitly teach further comprising:
determining a topology of the function module; determining from the topology of the function module a graph of dependencies in which the function module and/or at least one of its logics are involved; traversing the graph of dependencies and recording encountered nodes of the graph; and determining from the recorded encountered nodes based on at least one predetermined criterion whether the design of the function module has an error.
However, Vincent teaches a system comprising a deployment tool module (see Abstract and see Fig. 9) determining a topology of the function module (see Fig. 1 a graph is generated; see [0019] “Also a method for generating a cyclic graph of dependencies based on the complete dependency information and their relationship with one another is claimed…Also claimed is a method of debugging code objects…using the complete dependency graph of the particular code object.”; also, see [0051]), determining from the topology of the function module a graph of dependencies in which the function module and/or at least one of its logics are involved (see Fig. 1 a graph and dependencies is determined; also, see [0019] “Also a method for generating a cyclic graph of dependencies based on the complete dependency information and their relationship with one another is claimed…Also claimed is a method of debugging code objects…using the complete dependency graph of the particular code object”; also, see [0030] and [0051] “ The present invention provides a method and apparatus for generating the complete dependency graph of a stored code object. In a preferred embodiment, the method generates the complete dependency graph of a stored code object in an Oracle database. The method takes into consideration, getting the dependencies of object-oriented code objects that have implementations that are separate from specifications…”), traversing the graph of dependencies and recording encountered nodes of the graph (see [0045] “…. A true debugger should let the developer step through the code traversing dependencies at will, without any special effort. The level of complexity in large applications can easily reach 5 to 10 levels of dependency and the dependency tree can include hundreds of objects”; also, see ), and determining from the recorded encountered nodes based on at least one predetermined criterion whether the design of the function module has an error (see Fig. 1 and see [0058] “… INVALID objects in the complete dependency graph identifies code paths that can result in runtime errors. This functionality is indispensable for database programmers since otherwise a tremendous amount of time may be spent trying to identify the source of a run-time error. Component 14 scans the dependency array and for each object in the array, checks whether that object is part of a cyclic dependency. A well-known graph traversal algorithm is used for the purpose. Cyclic elements of the graph are then highlighted in a User Interface component that displays the dependency graph”).
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 Stump’s invention to include a deployment tool module and system determining a topology of the function module, determining from the topology of the function module a graph of dependencies in which the function module and/or at least one of its logics are involved, traversing the graph of dependencies and recording encountered nodes of the graph, and determining from the recorded encountered nodes based on at least one predetermined criterion whether the design of the function module has an error as taught by Vincent in order to identify errors in code objects and allow the user or system to fix the error before the code is executed (see [0005] “ It would be advantageous to have a method for automatically generating debug versions of a subprogram and all its dependencies. The method should allow fixing coding errors much faster by eliminating the need for generating debug versions of all dependent subprograms in a manual fashion. The method should also allow detecting potential runtime errors, before the subprogram is debugged or executed”) and to easily identify the error by highlighting the invalid objects (see [0058] “…This step ensures transparent "Step Into" operation from the Debugging facility. If any of the objects that are compiled in debug mode are INVALID, Component 15 shows the complete dependency graph with INVALID objects highlighted…”).
As per claim 4, Stump-Vincent teaches the method of claim 3, Vincent further teaches wherein, in response to determining from the encountered nodes that there is a circular dependency of nodes, determining that the design of the function module has an error (see [0058] “…. If any of the objects that are compiled in debug mode are INVALID, Component 15 shows the complete dependency graph with INVALID objects highlighted. INVALID objects in the complete dependency graph identifies code paths that can result in runtime errors. This functionality is indispensable for database programmers since otherwise a tremendous amount of time may be spent trying to identify the source of a run-time error. Component 14 scans the dependency array and for each object in the array, checks whether that object is part of a cyclic dependency. A well-known graph traversal algorithm is used for the purpose. Cyclic elements of the graph are then highlighted in a User Interface component that displays the dependency graph….”).
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 Stump’s invention to include a step of wherein, in response to determining from the encountered nodes that there is a circular dependency of nodes, determining that the design of the function module has an error as taught by Vincent in order to identify errors in code objects and allow the user or system to fix the error before the code is executed (see [0005] “ It would be advantageous to have a method for automatically generating debug versions of a subprogram and all its dependencies. The method should allow fixing coding errors much faster by eliminating the need for generating debug versions of all dependent subprograms in a manual fashion. The method should also allow detecting potential runtime errors, before the subprogram is debugged or executed”) and to easily identify the error by highlighting the invalid objects (see [0058] “…This step ensures transparent "Step Into" operation from the Debugging facility. If any of the objects that are compiled in debug mode are INVALID, Component 15 shows the complete dependency graph with INVALID objects highlighted…)
As per claim 5, Stump-Vincent teaches the method of claim 3, Vincent further teaches further comprising: determining whether all encountered nodes possess a set of required properties (see [0013] “..The debug process involves an object and all its dependencies. If a logical problem exists with a value returned or set by a called object, then the coding error might exist in either the called object itself, or one of the called objects. A true debugger should let the developer step through the code traversing dependencies at will, without any special effort…”; also, see [0019] “…a method for generating debug versions of stored code objects and all its dependencies…”; it is known that debugging software is the systematic process of identifying, analyzing, and removing errors (bugs) from code…inspecting variable values to check the program state, and stepping through code line-by-line to track flow. [0058] “ Component 14 scans the tracking array and compiles the objects in debug mode. This step ensures transparent "Step Into" operation from the Debugging facility. If any of the objects that are compiled in debug mode are INVALID, Component 15 shows the complete dependency graph with INVALID objects highlighted…”; also, see ), and/or whether all these properties conform to a predetermined specification (see [0058]); and when an outcome of this determining is negative, determining that the design of the function module has an error (see [0058] “ Component 14 scans the tracking array and compiles the objects in debug mode. This step ensures transparent "Step Into" operation from the Debugging facility. If any of the objects that are compiled in debug mode are INVALID, Component 15 shows the complete dependency graph with INVALID objects highlighted).
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 Stump-Vincent’s combination as taught above to include determining whether all encountered nodes possess a set of required properties, and/or whether all these properties conform to a predetermined specification and when an outcome of this determining is negative, determining that the design of the function module has an error as taught by Vincent in order to identify errors in code objects and allow the user or system to fix the error before the code is executed (see [0005] “ It would be advantageous to have a method for automatically generating debug versions of a subprogram and all its dependencies. The method should allow fixing coding errors much faster by eliminating the need for generating debug versions of all dependent subprograms in a manual fashion. The method should also allow detecting potential runtime errors, before the subprogram is debugged or executed”) and to easily identify the error by highlighting the invalid objects (see [0058] “…This step ensures transparent "Step Into" operation from the Debugging facility. If any of the objects that are compiled in debug mode are INVALID, Component 15 shows the complete dependency graph with INVALID objects highlighted…”).
Claim(s) 6-8 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Stump (US 20210096824, cited in the IDS) in view of Gang et al (Deadlock Avoidance Based on Banker’s Algorithm for FMS, cited in the IDS).
As per claim 6, Stump teaches the method of claim 1, Stump further teaches wherein the function module has a set of services (see [0039] “…Using such development platforms, a designer can write control programming (e.g., ladder logic, structured text, function block diagrams, etc.) for carrying out a desired industrial sequence or process and download the resulting program files to the controller 118…”, services are functions to be performed by the function module/software; also, see [0058], [0079], [0117] and see Fig. 6),
While Stump teaches that the model 306 is simulated and tested with respect to tests scripts for determining the functionality of each service/object (see 0085-0090), and while is known that function modules/programs when executed will be in one of a set of states, Stump does not explicitly teach each of the set of services being in one of a set of states at any one time, and wherein the method further comprises determining based at least in part on the set of states and/or transitions between states according to at least one predetermined criterion, whether the design of the function module has an error (the disclosure states that services verification tool are well known and they include service verifiers 53 uses a verification tool, such as NuSMV, NuXMV, SPIN or Promela).
Gang teaches a method and system for verifying services of a model comprising a tool for verifying services, each of set of services being in one of a set of states at any one time, and wherein the method further comprises determining based at least in part on the set of states and/or transitions between states according to at least one predetermined criterion, whether the design of the function module has an error (see page 2370 Col 1 “The simulation model is translated into a format suitable for model checking. That is, the model is written into PROMELA, the input language of the popular model checker SPIN. After that, SPIN is used to verify that the model does not have deadlock. This algorithm proves to be highly effective in practice….A deadlock is a state where a set of parts is in “circular waiting” i.e. each part in the set waits for a resource held by another part in the same set. In general, three strategies are used for dealing with deadlocks”; also, see page 2371 Col 2 “…Deadlock is a kind of system status, in which a set of parts enter into a waiting loop, each part in the set waits the resource occupied by another part in the set. Just like what the shadow in Fig.1…”; also, see page 2372 Col 2 pars. 2-3 “Given a PROMELA model, SPIN can perform simulations or exhaustive verifications of the system state space, during which it checks for the absence of deadlocks and for un-executable code. It can also verify linear time temporal constraints. Exhaustive verification can show conclusively whether a model contains errors. The model simulation tool provided in SPIN allows users to interactively simulate execution of PROMELA models. This tool is invaluable in the initial development and refinement of the model for the controller…. It can be seen that the system is deadlocked: process M1 (corresponding to M:2 process) and M2 (corresponding to M:3 process) wait for each other for ever, and the system can’t evolve.”, thus, the services/functions/jobs are in one of a set of states such as executing, waiting, and wherein a deadlock is identified the system is determined that the system is in deadlock or error; also, see page 2374 Col 2).
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 Stump’s invention to include a tool for verifying services, each of set of services being in one of a set of states at any one time, and wherein the method further comprises determining based at least in part on the set of states and/or transitions between states according to at least one predetermined criterion, whether the design of the function module has an error as taught by Gang in order to identify errors such as deadlocks (see page 2372 Col 2) and adopt policies to prevent the error (see Page 2370 Col 2 par. 1 “Every time a resource is requested or released, a check is made to see if any deadlocks exist. If exist, some policy will be adopted to
recover the system from deadlock…).
As per claim 7, Stump-Gang teaches the method of claim 6, Gang further teaches wherein, in response to determining that the reachability at least one state is dependent on at least one condition that cannot be fulfilled, and/or on at least two conditions that are mutually exclusive, it is determined that the design of the function module has an error ( is it determined a service cannot reach a completed state depending on another process holding the resources at the same time or when there is a circular dependency such as deadlock, see page 2370 Col 1 last par. “deadlock is a state where a set of parts is in “circular waiting” i.e. each part in the set waits for a resource held by another part in the same set. In general, three strategies are used for dealing with deadlocks”; also, se Fig. 1 see page 2370 Col 1 “The simulation model is translated into a format suitable for model checking. That is, the model is written into PROMELA, the input language of the popular model checker SPIN. After that, SPIN is used to verify that the model does not have deadlock. This algorithm proves to be highly effective in practice….A deadlock is a state where a set of parts is in “circular waiting” i.e. each part in the set waits for a resource held by another part in the same set. In general, three strategies are used for dealing with deadlocks”; also, see page 2371 Col 2 “…Deadlock is a kind of system status, in which a set of parts enter into a waiting loop, each part in the set waits the resource occupied by another part in the set. Just like what the shadow in Fig.1…”; also, see page 2372 Col 2 pars. 2-3 “Given a PROMELA model, SPIN can perform simulations or exhaustive verifications of the system state space, during which it checks for the absence of deadlocks and for un-executable code. It can also verify linear time temporal constraints. Exhaustive verification can show conclusively whether a model contains errors. The model simulation tool provided in SPIN allows users to interactively simulate execution of PROMELA models. This tool is invaluable in the initial development and refinement of the model for the controller…. It can be seen that the system is deadlocked: process M1 (corresponding to M:2 process) and M2 (corresponding to M:3 process) wait for each other for ever, and the system can’t evolve.”, thus, the services/functions/jobs are in one of a set of states such as executing, waiting, and wherein a deadlock is identified the system is determined that the system is in deadlock or error; also, see page 2374 Col 2).
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 Stump’s invention to include a tool for verifying services, wherein, in response to determining that the reachability at least one state is dependent on at least one condition that cannot be fulfilled, and/or on at least two conditions that are mutually exclusive, it is determined that the design of the function module has an error as taught by Gang in order to identify errors such as deadlocks (see page 2372 Col 2) and adopt policies to prevent the error (see Page 2370 Col 2 par. 1 “Every time a resource is requested or released, a check is made to see if any deadlocks exist. If exist, some policy will be adopted to recover the system from deadlock…).
As per claim 8, Stump-Gang teaches the method of claim 6, Gang further teaches wherein, in response to determining that at least one dependency for the reachability of at least one state is a circular dependency, it is determined that the design of the function module has an error (deadlock represents a circular dependency of services, see page 2370 Col 1 last par. “deadlock is a state where a set of parts is in “circular waiting” i.e. each part in the set waits for a resource held by another part in the same set. In general, three strategies are used for dealing with deadlocks”; also, se Fig. 1 see page 2370 Col 1 “The simulation model is translated into a format suitable for model checking. That is, the model is written into PROMELA, the input language of the popular model checker SPIN. After that, SPIN is used to verify that the model does not have deadlock. This algorithm proves to be highly effective in practice….A deadlock is a state where a set of parts is in “circular waiting” i.e. each part in the set waits for a resource held by another part in the same set. In general, three strategies are used for dealing with deadlocks”; also, see page 2371 Col 2 “…Deadlock is a kind of system status, in which a set of parts enter into a waiting loop, each part in the set waits the resource occupied by another part in the set. Just like what the shadow in Fig.1…”; also, see page 2372 Col 2 pars. 2-3 “Given a PROMELA model, SPIN can perform simulations or exhaustive verifications of the system state space, during which it checks for the absence of deadlocks and for un-executable code. It can also verify linear time temporal constraints. Exhaustive verification can show conclusively whether a model contains errors. The model simulation tool provided in SPIN allows users to interactively simulate execution of PROMELA models. This tool is invaluable in the initial development and refinement of the model for the controller…. It can be seen that the system is deadlocked: process M1 (corresponding to M:2 process) and M2 (corresponding to M:3 process) wait for each other for ever, and the system can’t evolve.”, thus, the services/functions/jobs are in one of a set of states such as executing, waiting, and wherein a deadlock is identified the system is determined that the system is in deadlock or error; also, see page 2374 Col 2).
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 Stump’s invention to include a tool for verifying services, wherein, in response to determining that at least one dependency for the reachability of at least one state is a circular dependency, it is determined that the design of the function module has an error as taught by Gang in order to identify errors such as deadlocks (see page 2372 Col 2) and adopt policies to prevent the error (see Page 2370 Col 2 par. 1 “Every time a resource is requested or released, a check is made to see if any deadlocks exist. If exist, some policy will be adopted to recover the system from deadlock…).
As per claim 11, Stump-Gang teaches the method of claim 6, Gang further teaches wherein, in response to determining that two services are in a running state simultaneously despite being mutually exclusive according to a predetermined safety condition, it is determined that the design of the function module has an error (see deadlock error is determined when two threads/services which are mutually exclusive) cannot run at the same time to access the same resource; see page 2371 col 2 “The fig.1 describes two jobs competing for two resources. Each job needs exclusive use of resource for a certain period of time. The component of the system can be depicted using CSP as following:… Deadlock is a kind of system status, in which a set of parts enter into a waiting loop, each part in the set waits the resource occupied by another part in the set. Just like what
the shadow in Fig.1”; see page 2372 Col 1 par. 1 “…Releasing M1 occurs only when Job1 get M2. When all the operations of Job have been finished, the Job
will be unloaded from the machine automatically. The same is to Job2. So, if the Job1 and Job2 run as the execution of 3 or 4, the system will deadlock” and see page 2372 Col 2 par. 2 “Given a PROMELA model, SPIN can perform simulations or exhaustive verifications of the system state space, during which it checks for the absence of deadlocks and for un-executable code. It can also verify linear time
temporal constraints. Exhaustive verification can show conclusively whether a model contains errors”).
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 Stump’s invention to include a tool for verifying services, wherein, in response to determining that two services are in a running state simultaneously despite being mutually exclusive according to a predetermined safety condition, it is determined that the design of the function module has an error as taught by Gang in order to identify errors such as deadlocks (see page 2372 Col 2) and adopt policies to prevent the error (see Page 2370 Col 2 par. 1 “Every time a resource is requested or released, a check is made to see if any deadlocks exist. If exist, some policy will be adopted to recover the system from deadlock…).
As per claim 12, Stump teaches the method of claim 1, further comprising:
Stump does not explicitly teach executing the function module in a virtualized execution environment; and monitoring, during the execution of the function module, at least one input/output channel, property of a node in the topology of the function module, and/or state of at least one service.
Gang teaches a method and system for verifying services of a model comprising a tool for verifying states services, executing the function module/functions in a virtualized execution environment/simulation (see page 2370 Col 2 last par. “…The first part is based on the petri net reachable graph, while the second part is based on a lookahead procedure that searches for deadlock situations by simulating the evolution process of system for a preestablished number of steps…”; ), and monitoring, during the execution of the function module, at least one input/output channel, property of a node in the topology of the function module, and/or state of at least one service (see page 2370 Col 1 “The simulation model is translated into a format suitable for model checking. That is, the model is written into PROMELA, the input language of the popular model checker SPIN. After that, SPIN is used to verify that the model does not have deadlock. This algorithm proves to be highly effective in practice….A deadlock is a state where a set of parts is in “circular waiting” i.e. each part in the set waits for a resource held by another part in the same set. In general, three strategies are used for dealing with deadlocks”; also, see page 2371 Col 2 “…Deadlock is a kind of system status, in which a set of parts enter into a waiting loop, each part in the set waits the resource occupied by another part in the set. Just like what the shadow in Fig.1…”; also, see page 2372 Col 2 pars. 2-3 “Given a PROMELA model, SPIN can perform simulations or exhaustive verifications of the system state space, during which it checks for the absence of deadlocks and for un-executable code. It can also verify linear time temporal constraints. Exhaustive verification can show conclusively whether a model contains errors. The model simulation tool provided in SPIN allows users to interactively simulate execution of PROMELA models. This tool is invaluable in the initial development and refinement of the model for the controller…. It can be seen that the system is deadlocked: process M1 (corresponding to M:2 process) and M2 (corresponding to M:3 process) wait for each other for ever, and the system can’t evolve.”, thus, the services/functions/jobs are in one of a set of states such as executing, waiting, and wherein a deadlock is identified the system is determined that the system is in deadlock or error; also, see page 2374 Col 2).
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 Stump’s invention to include a tool for verifying states services, executing the function module/functions in a virtualized execution environment/simulation, and monitoring, during the execution of the function module, at least one input/output channel, property of a node in the topology of the function module, and/or state of at least one service as taught by Gang in order to identify errors such as deadlocks before the software is executed in a real device/controller (see page 2372 Col 2) and adopt policies to prevent the error (see Page 2370 Col 2 par. 1 “Every time a resource is requested or released, a check is made to see if any deadlocks exist. If exist, some policy will be adopted to recover the system from deadlock…”).
Claim(s) 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Stump (US 20210096824, cited in the IDS) in view of Gang et al (Deadlock Avoidance Based on Banker’s Algorithm for FMS, cited in the IDS) as applied to claim 6 above, and further in view of Ott et al (US 20040193290).
As per claim 9, Stump-Gang teaches the method of claim 6, but it does not explicitly teach wherein the set of states and/or transitions between states is evaluated based at least in part on a cause-effect matrix of states and transitions between states.
However, Ott teaches a system comprising wherein the set of states and/or transitions between states is evaluated based at least in part on a cause-effect matrix of states and transitions between states (see 0007 “…logic specified by a traditional cause and effect matrix. Such a cause and effect function block, which is easy to create, use, test, debug and document, includes one or more cause inputs and one or more effect outputs and is programmed so that the arrival of a cause signal at one of the cause inputs results in one or more of the effect outputs being set to a tripped or safe state….”; also, see [0008] “The cause and effect function block may include a cause and effect matrix logic or multiplexer coupled to one or more state machines, with a separate state machine existing for each effect output. The multiplexer receives and decodes each of the cause inputs and, based on the cause inputs and a previously identified cause and effect matrix logic, provides a trip signal to one or more of the state machines… Moreover, each state machine can provide a signal indicating the current state of the state machine as well as a signal indicating the first cause which resulted in the state machine forcing its associated effect signal to the tripped or safe state”; also, see [0009]; also, see Fig. 3-4 state of the services/state machines blocks based on cause and effect matrix; also, see [0030] “…a cause and effect function block as contemplated herein can have any reasonable number of causes and effects (inputs and outputs) associated therewith and that the cause and effect matrix will generally include the same number of causes and effects as there are cause inputs and effect outputs of the cause and effect function block…”; also, see [0039-0042] the transitions are evaluated and determined with respect to the cause and effect matrix).
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 Stump-Gang’s combination as taught above to include a step of wherein the set of states and/or transitions between states is evaluated based at least in part on a cause-effect matrix of states and transitions between states as taught by Ott in order to determine the current state of services/functions including normal, abnormal, waiting or trip states (see Fig. 4 and see 0039-0042] and [0044-0046]) and control the operation of safety system within a modular plant (see [0001] and se Fig. 1).
As per claim 10, Stump-Gang-Ott teaches the method of claim 9, Ott further teaches wherein, in response to determining that at least one cause is tied to multiple effects, and/or multiple causes are tied to a same effect (see [0030] “The cause and effect matrix 105, which may be used in the cause and effect function block 92 includes seven causes listed down the left-hand side of the matrix (with each cause associated with a different row of the matrix 105) and has two effects listed along the top of the matrix (with each effect associated with a different column of the matrix 105), it is determined that the design of the function module has an error (see Fig. 4 tripped mode is an error; also, see [0038-0039] “…the state machine 112 may enter into the tripped state 132 from any of the states 134, 136, 138, 140 and 142 in which it is currently located in response to the state machine 112 receiving an active cause at the trip signal input 108. Thus, when the state machine 112 is in the normal operating state 140 and the Effect1 signal 116 is in the normal state, the presence of one or more active causes on the trip signal line 108 will cause the state machine 112 to enter into the tripped state 132.”).
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 Stump-Gang’s combination as taught above to include a step of wherein, in response to determining that at least one cause is tied to multiple effects, and/or multiple causes are tied to a same effect, it is determined that the design of the function module has an error as taught by Ott in order to determine the current state of services/functions including normal, abnormal, waiting or trip states (see Fig. 4 and see 0039-0042] and [0044-0046]) and control the operation of safety system within a modular plant (see [0001] and se Fig. 1).
Claim(s) 14 is rejected under 35 U.S.C. 103 as being unpatentable over Stump (US 20210096824, cited in the IDS) in view of Vion-Dury et al (US 20090254812).
As per claim 14, Stump teaches the method of claim 1, further comprising:
While Stump clearly teaches displaying errors during the checking, and displaying the errors (see [0049] “User interface component 204 can be configured to receive user input and to render output to the user in any suitable format (e.g., visual, audio, tactile, etc.)… Output data rendered by various embodiments of user interface component 204 can include program code, programming feedback (e.g., error and highlighting, coding suggestions, etc.), programming and visualization development screens, project testing results, etc.”; also, see [0067], [0087], and [0089] “If the test results 906 indicate an improper operation of one or more aspects of system project 302, project testing component 210 may generate and render one or more design recommendations 908 indicating possible modifications to the system project 302 that would correct operation of the project. These design recommendations 908 may include, for example, control code modifications or replacements, recommended corrections of data tag addresses, recommended corrections to HMI graphical object references,… recommended modifications to an industrial device's configuration parameters, or other such corrections), but Stump does not explicitly teach in response to the checking, creating an error report including any identified errors, and displaying the error via a graphical user interface includes displaying the identified errors of the error report.
Vion-Dury teaches a validation system comprising in response to a checking, creating an error report including any identified errors (see the Abstract “a report generator configured to generate an error report identifying SGML errors corresponding with errors detected by the validation and linking the identified SGML errors with corresponding locations in the SGML document….”; also, see [0022], [0038]), and displaying the error via a graphical user interface includes displaying the identified errors of the error report (see [0016] “The SGML document 10 is input to an SGML validation system shown in FIG. 1 for the purpose of validating the SGML document against the SGML standard including the SGML DTD 12 and any associated rules 14…”; see [0031] “The entity resolution schema or schema component 52a is configured to verify external entities and notation references. The content model verification schema or schema component 52b addresses content model verification, that is, checking that all tags are embedded and sequenced in accordance with the content model defined in the SGML DTD 12, and also that attributes such as names and values are also compliant with the SGML DTD 12…”; also, see 0011 “ identifying SGML errors corresponding with errors detected by the validating; and displaying a report indicating the identified SGML errors”; also, see [0022] and [0040]. see page 9 claim 6 and claim 6).
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 Stump’s invention to include in response to a checking, creating an error report including any identified errors (see the Abstract “a report generator configured to generate an error report identifying SGML errors corresponding with errors detected by the validation and linking the identified SGML errors with corresponding locations in the SGML document….”; also, see [0022], [0038]), and displaying the error via a graphical user interface includes displaying the identified errors of the error report as taught by Vion-Dury in order to allow a user to visualize the error and help the user to fix any problems and identify the location where a constraint was not met (see [0005] “a report that identifies the location in the document at which the constraint is not met and identifies which constraint is not met”, see [0009-0010]; also, see [0040]).
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.
Darringer and Zhang teaches systems and method to generate error reports and display the reports (see Darringer abstract, and Zhang Abstract and Fig. 6).
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
/DARRIN D DUNN/Patent Examiner, Art Unit 2117
Prosecution Insights