DETAILED ACTION
This action is responsive to the Applicant’s response filed 5/01/26.
As indicated in Applicant’s response, claims 1, 4-5, 8, 11-12 have been amended and claims 3, 10 cancelled. Claims 1-2, 4-9, 11-14 remain and are pending a next office action.
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.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2 step Analysis.
Step I: the claim is statutorily directed to a method/process category
Step II, A:
Prong one:
The step recited as "extracting (from description data), a workflow task model" (associated
with a control object) can be viewed, absent further details, as mimicking a task that can be performed mentally by a human such as reviewing, organizing received information. That is, this
"extraction" is viewed as a step of analyzing to create a conceptual model without specific use of
unconventional technique. Accordingly, this extracting step can be considered an abstract idea, per
step2A or Alice test. MPEP 2106.04(a)
Prong Two:
The elements recited as controllable machines, workstation, programming tool with HMI to receive input amounts to well-known computer components provided as tool by which the extracting step to operate; hence cannot be seen as a novel implementation of the Abstract Idea of extracting data in terms of solving a computer issue in this information extracting field. The elements recited as “multiple blocks” associated with control object and relationships between control blocks amount to mere static description of data subjected to the extracting step and cannot be seen as an improvement to the abstract Idea. The elements recited as “receiving user input” via a HMI in form of workflow description fall into the standard scenario of analyzing data via a acquiring step considered well-known by the circuits as activities of a Mental Process type exception. The elements recited as "generating a text-based script" (including text description of model blocks) and "executing" (the script) to allow creation of “function block of workflow” can be considered well-known, standard computer activities (via use of pen/paper) provided as extra-solution or post-activity that makes use of result from the abstracted step of extracting, and as such, these elements fail to teach a specific improvement to the technical field of extracting data, cannot transform the mental process of "extracting" into a practical application. MPEP 2106.05(a), (c) (g)
Step II, B:
Considered together with the mental process of "extracting", the additional elements of
"receiving" (via a HMI) is construed as mere generic computer function (e.g. input/output) that amounts to a extra-solution or pre-activity step in support for the step of acquiring data for a mental extraction, as this does not upconvert this Abstract Idea into a patent-eligible practical application. Likewise, the additional element observed as “generating a text-based script”, “executing” the script such as to “allow creation of function block” can be viewed as extra-solution activity (e.g. per use of pen/paper) to make use of result from an Abstract Idea, set forth in step IIA. Besides, generating function block based on a script amounts to no unconventional technique to improve computer technology associated with extraction of information, as the script-based rendering of blocks at best is a tool that makes use of extracted data, and in all, the additional elements fail to add significantly more to the abstract Idea itself. MPEP 2106.05.(a), (c ), (e), (g)
The method claim is not tied to non-conventional improvement showing how engineering tool/functions (computer-based HMI, text-based script) have specifically provided improvement to his data extracting field, since the rather use of cognitive process performed by a human like mental capability is deemed a method that cannot make the Judicial Exception of step 2A for it to amount to significantly more than it is.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a
judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without
significantly more. Claim(s) 8 is/are directed to Abstract Idea. The claim(s) does/do not include
additional elements that are sufficient to amount to significantly more than the judicial exception as detailed in the following 2 steps analysis
Step I: the claim is directed to a apparatus/product category
Step IIA
Prong One:
The step recited as (parser to) "extract (from description data), a workflow task model"
(associated with a control object) can be viewed, absent further details, as mimicking parsing
capability of a human that mentally extracts data based on the received information for reviewing,
re-organizing. That is, this "extraction" is viewed as a step of parsing, analyzing and deriving, reorganizing received data by a mental capability to create a conceptual model without
specific use of unconventional technique. MPEP 2106.04(a). The claim is directed to a Abstract Idea of a Mental Process subcategory.
Prong Two:
The elements recited as communication interface, HMI, parser, script engine/generator are concepts recited in high level of generality and are mostly viewed a computer components similar to using a generic computer as means to acquire and extract information typical to a Mental Process subcategory of a Judicial Exception, and so, even in consideration of elements recited as “generating a text-based script”, “executing” the script such as to “allow creation of function block” which are viewed as extra-solution insignificant activity (e.g. per use of pen/paper) to make use of result from an Abstract Idea, set forth in step IIA. The claim as a whole, describes receiving function block description via a HMI using a parser to extract blocks and block relationships followed by a script execution to allows creation of function blocks and based on the flow of actions, the claim does not express a significant improvement or transformation to the computer field of analyzing data, notably when only tools are used to provide one or more pre-activity and post-activity to this abstract idea limitation set forth in step IIA. MPEP 2106.05(a ) (c )(e) (g)
As a whole, and in view of the above elements the claim 8 cannot integrate the above Abstract Idea into a Practical Application.
Step IIB:
The additional elements recited as communication interface, HMI, parser, script engine/generator are concepts recited in high level of generality and are mostly viewed computer components similar to using a generic computer as means to acquire and extract information typical to a Mental Process subcategory of a Judicial Exception. The additional elements recited as “generating a text-based script”, “executing” the script such as to “allow creation of function blocks” are viewed as extra-solution insignificant activity (e.g. per use of pen/paper) to make use of result from an Abstract Idea, set forth in step IIA. In all, the additional elements fail to show a significant improvement or transformation to the computer field of analyzing data, notably when only tools (interface, HMI, parser, script engine/generator ) are provided to enable one or more pre-activity and post-activity to this abstract idea limitation set forth in step IIA. MPEP 2106.05(a ) (c )(e) (g)
The apparatus claim 8 is therefore deemed non-eligible under the 35 USC § 101 statute.
Eligibility under step IIB for dependent claims.
Claim 2 recites communicating via a middleware to realize monitoring of execution of the
workflow task, mapping state data and process data via a script engine and receiving control
information relating to the execution process from executing the script engine. The standard
technique to monitor and obtaining execution data is construed as insignificant post-activities using
support from conventional computer technology and cannot be seen, per step 2B, as non-
conventional techniques that bring forth novelty or technical improvement to the "extracting"
process of method claim 1.
Claim 4 recites generating textual description of blocks, overloading function and parameter setting, and as such the detailed non-functional aspect of the workflow description cannot be seen, per step 2B, as inventive technique that improve the abstract Idea of claim 1.
Claim 5 recites initiating a function block via virtual machine to execute block of a script
engine; but use of execution to carry out result from an abstracted action that mentally extract a
model, can be viewed as computer means deemed well-known to provide post-activity that is
follows a Judicial exception. Hence, claim 5 fails to bring forth any inventive addition to the Judicial
exception of claim 1.
Claim 6 recites first and second control object, and executing the first and second object by a script engine on a first and second executor, and realizing scheduling of the control object via
middleware. These implementation details on control object associated with script engine belongs to post-activity stage that in fact fails to render the abstract Idea deficiency of claim 1 to amount to significantly more than a mental process.
Claim 7 specifies a standard for generating description data and this cannot be seen as a non-conventional means to clearly improve state of generating a abstract model from the extraction step of claim 1.
Claims 9, 11-14 are mere respective replica of claims 2, 4-7, hence fail to render the abstract Idea of claim 8 significantly much more than a Judicial exception.
In all, claims 1-2,4-9, 11-14 are deemed non-eligible under the 35 USC § 101 statute.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5, 8, 12 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Stump et al, USPubN: 2022/0299982 (herein Stump) in view of Crisan et al, USPubN: 2003/0191769 (herein Crisan).
As per claim 1, Stump discloses a computer-implemented method for executing a
workflow task (workflows – para 0052; flow control - para 0059, 0065; para 0067-0068, 0118; flow control process - para 0115) across control objects (tanks, valves, pumps etc. - para 0075; pumps, tanks, motors, motor drives - para 0055, 0058; pumps, controllers, stations, conveyors, drives - para 0061; valves, pumps – para 0068; motor drives, valves, pumps - para 0086-0087; industrial asset (e.g. a pump, a tanks, a stramping press - para 0103; collection of automation objects tanks, pumps, valves, motor drives, conveyers - para 0115; para 0122) comprising controllable machines, the computer- implemented method comprising:
receiving user input (user interface component via interaction with the IDE interfaces,
industrial design input that defines aspects of an industrial automation project - para 0003; design
input received via the user interface as well as industrial knowledge, predefined code modules and
visualizations objects maintained by the IDE system - para 0049) from an engineering station host running a programming tool accepting the user input via an interactive human-machine interface (HMI – configuration platform and a associated HMI – para 0040; interface component 204 – para 0057; IDE – Fig. 5; interface component 204 – para 0102), the user input including description data (design input 512 – Fig. 5; para 0103; definitions maintained in library - para 0105; model library – para 0115; library 1502 - Fig. 15; model library 1502 - para 0120; control logic, structured text, sequential function charts - para 0057; definition to all instances of automation objects used throughout a control project - para 0045; para 0043; design specifications, design input - para 0048-0049) associated with a workflow task (motor drive parameter definitions - para 0079; definitions of the conditions that trigger the alarm, alarm definitions defined by the automation object - para 0092; object test properties can include definitions that define test scenarios run against the automation object and associated project elements - para 0093; definition of how many pumps, controllers conveyors, drives - para 0061; automation object definition to all instances of automation objects used throughout a control project - para 0045) executed across at least one control object (various automation objects industrial devices or assets of an automation tanks, valves, pumps etc. - para 0075);
extracting, from the description data (design input 512 – Fig. 5; para 0004-0005; design specifications, design input - para 0048-0049), a workflow task model (e.g. model 602a generation component 206 editor 224 project model 302 - Fig. 15; model 602 – para 0075; Fig. 6) associated with the at least one control object (tanks, pumps, valves, motor drives, conveyors - para 0115; Pump AO, Valve AO, Tank AO, Process AO – Fig. 6; target devices … controllers, terminals, drives, devices etc - para 0054),
generating a text-based script (test scripts - Fig. 10-11; para 0050; para 0094-0096, 0098) and interpreting and executing the script for realizing the workflow task (component 210 can execute one or more scripts 1002 - para 0095-0096) using a script engine (component 210 - para 0094; Fig. 10) to control operation (e.g. interface with known data items generated by the industrial asset … so that the data associated with these data items can be processed by the scripts – para 0091; designed to test and debug the automation object …selected automation objects 222 … to verify responses -para 0093-0094; control code … sequence defined by the test script 1002 – para 0095; automation object 222 [Wingdings font/0xDF][Wingdings font/0xE0] industrial asset 402 – Fig. 4; execute … in accordance with each defined test scenario in sequence ..validate proper operation – para 0098; scripted control code such as a industrial DSL – para 0126 ; feeding simulated inputs to control code …of system project ..according to … sequence defined by the script, setting values or …variables… according to defined sequence … control routines … linkage between control routines … test results or responses of the project 302 … interactions defined by the script 1002 - para 0095) of the control objects (sensor, actuator, output devices – para 0134; see industrial asset 402 – Fig. 4; target devices … controllers, terminals, drives, devices etc - para 0054; drives, actuators, devices, robot control , valves, pumps – para 0034).
Stump does not explicitly disclose receiving definition data via a HMI and generating a text-based script terms of
receiving, workflow description data; and extracting, from the workflow description data, a workflow task model associated with the at least one control object; and
generating on basis of the workflow task model, a text-based script (for realizing the
workflow task to control operation of the control objects)
Description in form XML schema structure (Fig.3) from a WSDL repository in terms of
interface or service description used for binding a developed invocation of a service is shown in
Crisan (para 0038), where SOAP message and XML documents (para 0110-0111; Fig. 8) associated with this WSDL methodology enable in/out parameters bindings of URL, ports to be extracted to implement queries to a workflow model database from which to configure workflow tasks (para 0130) of a computer model, one such workflow model instances provided via a runtime DB as by a workflow definition language (para 0132; Fig. 11) into a workflow engine, in which a function generator maps (para 0146; Fig. 12-14) the workflow language from a workflow description file (e.g. a WSDL , para 0024) into input and output of objects or workflow constituted from user define functions (WSDL 82, derive UDF 86 - Fig. 10; Workflow 220[Wingdings font/0xE0]UDF 208a, 208b … 208n – Fig. 11) each as a building elements of the workflow comprising in workflow calls (para 0135) or functions invoked in the workflow (para 0137-0139); e.g. using information from the workflow description file (para 0143; Fig. 16), the function generator using the return values, function definition (para 0144) thereof in generating an executable script to call one or more UDF sources as part of the calls to invoke the workflow (para 0145)
Hence, mapping constructs and definition in a workflow description file with parameters,
return type of a function or UDF component representing each a functional block of the workflow used to implement calls as part of script invocations that comprise execution of a workflow task model comprised of functional components is recognized.
Therefore, based on Stump's use of predefined models from which to distribute project
objects to IDE clients (para 0111-0112) according to which model/design description can be
selectively fetched by the designers/users, among a repository of model definitions (see library
definition data from above) with which a designer/developer can configure or parameterize function for generating workflow tasks in form of script to operate industrial control or archive to record items defined by a configuration of automation objects (para 0100), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the use of configuration archiving and models store so that workflow model description file associated therewith would provide programmatic and model definition with which IDE's user can select for implementing logic, parameterization of automation objects, and operations involving automation objects associated with a workflow task executed across at least one control object as in Stump, the workflow model description file received into a programming tool as in Crisan, where a text-based script (for realizing the workflow task) is generated via mapping with the information parsed or extracted (from the model description - as in Crisan) in the implementation of the workflow task model; because
use of WSDL and database of model in form of workflow description structure or file
accessible via remote query or protocol compliant messaging for import into a programming
framework or modeling interface as set forth in Stump would not only benefits from the
vulnerabilities protection and data confidentiality provided by services under RDBMs and SOAP
protocols but would also afford latest update to be added to the pre-deployed or pre-developed
resource or assets thereby to consolidate or enrich usability of descriptive information underlying the reusability of the assets stored in form of models store or workflow model as set forth above, where descriptive information provided in terms of workflow model definition - as per the workflow description file in Crisan- can be accessible for use in a modeling tools or programming frameworks such as one to configure and implement task execution of a workflow model as in Stump, affording thereby use of parameter setting and function definition imported from remote repository/DB, in order to assemble call constructs in the effect of building a text-script as in Stump to invoke functions required to implement tasks of a workflow functionality modeled after definition and programmatic settings extracted from the imported workflow description structure.
B) Nor does Stump explicitly disclose
(i) wherein the workflow task model describes multiple function blocks associated with the at least one control object, and at least one connection relationship between respective ones of the multiple function blocks;
(ii) the text-based script including textual descriptions of respective ones of the multiple function blocks of the workflow task model;
(iii) such that the interpretable and executable text-based script allows dynamic creation of at least one function block of the workflow task model without re-compiling.
As for (i)
Stump discloses project data in terms of hierarchical relationship with one another include relationship between a first automation object as a tank(parent object) and a second AO as a valve (child object) whose control logic can be linked by the project to form a portion of the system project based on aggregation of control code associated with respective automation objects defined by the data model and the relationships between objects of the model (para 0089); hence connection relationships between multiple functional blocks of a workflow or a workflow model set as obvious per rationale A is recognized - referred herein as (*)
As for (ii)
In Stump, scripts are text interpreted logical programs that can be executed by an interpreter directly without a standard compilation, such that functional settings in a script entails text expression of code calling, defined variables, types and functions based thereon to impart a control flow for script functions or objects to interact with each other via calls, which can be seen as script constructs describing inputs to control code of system project 602 (Fig. 12) according to sequence defined by the script, setting values or variables according to defined sequence, control routines ad linkage (para 0095) between control routines associated with interaction between automated objects (AOs – Fig. 12; AOs 222 – Fig 15) so that test results or responses of the project 302 are part of interactions defined by the script, in that interaction between the project automated objects can translate into interoperability of industrial assets or real-world control objects/devices (target devices … controllers, terminals, drives, devices etc - para 0054; drives, actuators, devices, robot control , valves, pumps – para 0034) represented by the AOs of the project model; hence text-based programming of AO calls and interactions of devices represented by the model AOs via expression of a interpretable script defining how functions or objects interact with each other via calls entails that, as programmed, the text-script describes – referred herein as (**) - one or more functions respective each to function block of a industrial workflow of AOs or control objects of the Project model or workflow model set as obvious per rationale A from above.
As for (iii),
As script execution in Stump include realization of interaction between logic of AOs under the direction and logical order set by the script for test actions to be performed and results from the AO logic to be collected and reported (see para 0091, 0093-0094, 0098) via the script, it entails that runtime interpretation of script code allows dynamic creation and direct invocation of at least one function block among hierarchy of function block in the workflow task model (see rationale A from above) under logic control of the interpretable script without need for this function block to be compiled or re-compiled; referred herein as (***)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement model generation per extraction of description/design data and generation of script based on the generated model in Stump so that
1) extracted description or design data enable a workflow operations in the model to be generated as set forth above in rationale A, in terms of workflow task model describing multiple function blocks associated with one or more control objects and at least one connection relationship between respective ones of the multiple function blocks as set forth above in (*);
2) the text-based script includes textual descriptions of respective ones of the multiple function blocks of the workflow task model – as per (**) from above; such that
3) the interpretable and executable text-based script allows dynamic creation of at least one function block of the workflow task model – as set forth in (***) - without re-compiling; because
an industrial process configured via a model customized using a HMI and graphical interactive design approach and then evaluated from a model instance via objects execution from a script-based testing and result assessment based thereon entails a industrial flow of actions observable via software logic control associated with objects of the workflow model which upon execution under direction of a interpretable text script, exhibit interactions between the model objects (e.g. automated objects) and runtime interdependency among objects from one with another, where each such object action reflects operation of a real-world industrial control entities like pump, valve, sensor and actuator, motor drives underlying a definite interdependency or sequencing of operations intended by a industrial process, and by using descriptive design input to generate of a task model depicting this intended industrial workflow or functional linkage (workflow task model) as set forth above, this indispensable converting stage would serve as designer springboard by which further SW implementation or customization of interlinked functionalities included with the task model to be tested and evaluated as intended by the framework, and by providing a text-based script programmed with textual definition and declaration of variables and/or functions associated with code calling or dynamic flow linkage between the task elements or objects of the model, simulating the model tasks functions under control of the script-based description/declarations can be realized via a runtime interpreter without need for a compiler where achieved test data and acquired state of the interactions or simulated real-world functional dependencies among workflow tasks reflective of runtime behavior of industrial objects underlying workflow task model observed from the result of running the script control logic would facilitate evaluation by the developers on validity of the model at a given point of its development, so that further amelioration or customization can be provided to improve the intended behavior of this industrial model.
As per claim 5, Stump discloses method as claimed in claim 1, wherein interpreting and
executing the script by means of a script engine comprises instantiating, on a virtual machine (e.g.
virtual machines - para 0046; suitable virtualization for a given object based on object type and
visualization context - para 0059; para 0148), a function block associated with the at least one
control object (refer to claim 1), and executing the function block (refer to claim 3)
As per claim 8, Stump discloses an apparatus for executing a workflow task across control
objects comprising controllable machines, the apparatus comprising:
a communication interface (refer to receive in claim 1)configured to receive, from a programming tool accepting user input (refer to claim 1) via an interactive human-machine interface (HMI – refer to claim 1), workflow description data associated with a workflow task (refer to claim 1) executed across at least one control object (refer to claim 1);
a parser configured to extract (refer to extract in claim 1), from the workflow description data, a workflow task model (refer to rationale A of claim 1) associated with the at least one control object, wherein the workflow task model describes multiple function blocks associated with the at least one control object, and a connection relationship between the multiple function blocks (refer to rationale B(i) of claim 1);
a script generator configured to generate, on the basis of the workflow task model (refer to rationale B of claim 1), a text-based script for realizing the workflow task, the text-based script including (refer to rationale B(ii) of claim 1) textual descriptions of respective ones of the multiple function blocks of the workflow task model; and
a script engine module configured to interpret and execute the text-based script (refer to claim 1) to control the operation of the control objects (refer to claim 1); such that the interpretable and executable text-based script allows dynamic creation of at least one function block (refer to rationale B(iii) of claim 1) of the workflow task model without re-compiling (refer to rationale B(iii) of claim 1).
As per claim 12, refer to rejection of claim 5.
Claims 2, 9 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Stump et al, USPubN: 2022/0299982 (herein Stump) in view of Crisan et al, USPubN: 2003/0191769 (herein Crisan) further in view of Xu et al, CN 110417760 (translation), 11-05, 2019, 12 pgs (herein
XuDong) and Haswell et al, USPubN: 2005/0193269 (herein Haswell) and Miao, Ze-feng, CN
101483562, (translation), 07-15-2009, 14 pgs (herein Miao) and Xu, Yan-bin et al, CN 107995026
(translation), 5-04-2018, 11 pgs (herein XuYan)
As per claim 2, Stump does not explicitly disclose method as claimed in claim 1, further comprising:
communicating with the programming tool via middleware to realize visual monitoring
and control of an execution process of the workflow task, including at least one of:
mapping, to the middleware, state data and process data relating to the execution process
by means of the script engine, so that the programming tool acquires the state data and the process
data;
receiving control information relating to the execution process from the programming tool via the middleware by means of the script engine.
Stump, however, discloses project data models as a hierarchical relationship between the
automation objects, the latter provided as input into a project generation component by a developer
(para 0114) using objects from repository 502 (Fig. 14) for visualization inside a project generation
component (para 0110) -- for editing and development (para 0113) - using knowledge afforded from the models store/library in regard to automation objects or relationships thereof associated with industrial assets (para 0115), for developing a type of industrial machine or process (para 0116) via selection of a data model, code modules or snippets, which include components for monitoring the project and make recommendation (para 0117; component 206 configured to monitor generate recommendations during subsequent development sessions - para 0063). Further, Stump discloses collection of test data (test results 1006 - Fig. 10) and use of industrial storage to retain collection of state data and process data via instructions set with control programs under instrumentation or monitoring modules (persisted data values, measured or calculated values, operational states, captured time series, status information for points in time – para 0035)
Acquisition of state data and the process data relevant to execution of the workflow
model tasks associated with control objects per effect of developer's selected configuration and code modules coordinated with knowledge information on automation objects is also recognized in
Stump.
That is, operational and statistical data as well as alarm conditions returned from reporting
scripts in Stump for insight yielding and visualization to induce possible adjustment by the
developer (para 0076) entails that acquiring of state data and the process data relevant to
execution of the workflow modules or tasks for controlling industrial assets such as control
objects via use of script execution is recognized - referred herein as (IV).
Use of messaging middleware as a secure means to transfer, communicate and relay
interaction type events, data and instructions is shown in Miao, XuYan, Haswell, and XuDong.
Miao discloses interface associated with test environment for workflow of test routine
associated with testing communication equipment, using unified management of the plurality of test tasks (pg. 3) coupled with a communication proxy through which messages transmitting execution result for each device testing are returned, the managing starting from registering (pg. 7) a message, initializing loading configuration and user parameters (pg. 5) for testing a device and identifying a service end and relevant channels for receiving test tasks and execution state - from instant test monitoring, the channel registering using technical specification of message oriented middleware channel (pg. 4); hence use of message middleware to transport test tasks to tested equipment and to return test result from instant monitoring is recognized.
XuYan discloses middleware-based management method for controlling and managing
nodes under management via a corresponding message middleware module to send out control
command intended for one such node and using another message-oriented middleware module for
receiving from each managed node results from executed commands back to a centralized
management node (pg. 2-3), where registration of a new managed node utilizes a script configured to realize bidirectional communication between the node and the management node (pg. 8). Hence, use of a script as a bidirectional support to enable commands from a centralized module to be directed to managed nodes and to receive results from the executed commands, per a communication facilitated with use of message-oriented middleware is recognized.
Haswell discloses test/integration environment including implementation of fest script using
object-oriented programming methodology (para O107-0108) coupled with testing tools, class
libraries (para 0121-0128) by which the programmer creates (user-defined) objects representing
real-world entities -- such as pistons or valves - and associated functions (para 0109-0111) in
conjunction with a GUI framework to implement various designs and automated script scenarios
(para 0158-0159) that allow test status reporting (para 0160) using report services implemented with HTTP protocol and tracking tools (para 0400; ASP framework - Fig 18; test data generation tools - para 0898) in association with fest script creation and reporting (para 0923-0925); wherein the Object-Oriented modeling and design utilize presentation tools (para -840) and integration tools that rely on wrapper components (para 0864) and message-oriented Middleware (para 0868) to pass information between the development context and the services that deploy/integrate the developed components. Hence, use of middleware as protocol-compliant methodology to transfer development or design data and test data between various test, design and integration and test evaluation contexts as well as using scripting language as a programmatic means by which to generate mapping of state data and process data into a text instruction of a reporting script for tracking of monitored test data
and process state is recognized.
Moreover, XuDong discloses use of messaging middleware as a means to transport
information to triggers operation associated with run-time engine of an event-driven technology (pg. 3), the executed operation and use of the middleware for realizing interactive operation of an
industrial edge layer as part of multi-layer factory production scheduling and coordination workshop (pg. 3-4) where standard protocol message communication of the middleware is for pre-configuring different connecting points of the production process by which to send and receive forwarding rule (e.g. speed, address type, volume attribute) and content/conditioning information that affects or drives transaction/data of participating portions (mechanical claw, shaft) of the production process (pg. 5); e.g. connecting points of a material loading control system having ports and modules being affected by pre-configured rules or programming acting as triggering condition of a script sent to actuate the arm of the automated guiding vehicle (AGV - pg. 6)
Hence, use of message transporting protocol for receiving control information relating to the execution process from the programming tool, in terms of communication middleware via use of a triggering script is recognized.
Therefore, based on use of script to carry test on tasks of the industrial process workflow and for reporting test results on control objects in Stump, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement use of script and orchestration of test code formation and test monitoring (as per (IV) from above) in Stump so that middleware is utilized as a protocol compliant message (bidirectional) communication technology as in Miao or Xy Yan in terms of communicating with the programming tool via middleware to realize visual monitoring and control of an execution process of the workflow task according to effect of communicating test task instruction, condition and test state from and back to a programming tool, where the script formation includes mapping, to the middleware, state data and process data - as in Miao and Haswell - relating to the execution process by means of the script engine, so that the programming tool acquires the state data and the process data; and by means of the script engine or configuration script - as in Miao, XuYan and XuDong- for receiving control information relating to the execution process from the programming tool via the middleware; because
use of protocol-compliant and secure services provided in form of reliable communication
middleware to secure bidirectional communication of information, such as control type or rule-based directives or commands directed as objects or entities under the management by a centralized layer as well as returned results or execution data received back from the managed entities would benefit from the reliability with which bidirectional transmission of information can be secured and achieved as result from NW vulnerability check and protocol-compliant setting specifically endorsed by a given middleware; and use a programmatic means to convey developer's control directives or setting conditions in terms of parameterizing a scripting language as in Stump SO to configure both transmission of commands or conditions to the target entities such as control devices of industrial workflow context and reception of execution state or process data from these entities would benefit from the user-friendly aspect with which script generation or execution can ease developers in their intent for testing a target model and obtaining feedback therefrom for analytics purposes, notably when the developers in a web-based or HTTP-bound framework as in Stump are less endowed with expert conventional source code programming but more familiar with text-based interpreter code forming.
As per claim 9, refer to rationale of claim 2.
Claims 4, 11 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Stump et al, USPubN: 2022/0299982 (herein Stump) in view of Crisan et al, USPubN: 2003/0191769 (herein Crisan) further in view of Thaller et al, USPubN: 2021/0082183 (herein Thaller) and Nuss, USPubN: 2004/0225999 (herein Nuss)
As per claim 4, Stump does not explicitly disclose method as claimed in claim 1, wherein
generating, on the basis of the workflow task model, a text-based script for realizing the workflow
task, comprises (i) generating a textual description of an imported function block, (ii) a textual description of an overloaded function block, (iii) a textual description of function block parameter settings, and (iv) a textual description of event scheduling.
As for (iv)
Stump discloses writing scripts to perform verification on linkages and relationships across
the design in terms of control code, layout definition, wiring schedule or piping diagrams (para
0096) where interrelated states and events may be represented as state diagram and interaction
diagrams (para 0125) and where visualization of the monitored operations, time series data or
events relate to control objects or diagnostics of the automation system (para 0035); hence use of
reporting scripts (para 0076) to capture interaction operation on monitored control objects and
related event, data in terms of script-based scheduling of time-related capture of states/events
for monitoring purposes is recognized- referred herein as (V)
As for (i) and (iii),
Thaller discloses identification and selection of prestored scripts to implement deployment
of an application (Fig. 5) to compose a 3D scene or shape (Fig. 8A), where building a library of
scripts (para 0066) includes preprocessing via a multi-pass compiler that translates each script into
its machine C++ code (para 0061) in form of DLLs stored with the script (para 0062) where realization of the compiled script entails execution of its DLLs which is achievable via interpreting the script (para 0120); each script comprising of modules that each, consists of import declarations, variable and function declarations and rules, such as parametric rules on variable declaration and expressions of operators and relational Boolean. (para 0129); hence obtaining declaration or textual description of an imported function block, description of function block parameter settings as part of constructing a script is recognized.
As for (ii)
Nuss discloses a VM engine using a composition engine coupled with a translation of
grammar constructs and script translator to form interpretable code for an interpreter engine that
executes the translated scripts supplied from the VM engine (Figure 1, 2) where regular expressions
as primitives to C-style programming languages as seen in C++, Javascript in terms of their basic
grammar for functions, statement, expressions are well known as the regular-expression syntax
adopts overloads to introduce new operators and rules on precedence and associativity aspect that
enrich its grammar and syntax (para 0024; claims 3-4, pg. 76), the overloading of operators for
C-interpreter allowing binding/precedence rules or enhanced associativity to govern expressions in
a manner independent of the data type (para 0174-0175; para 0206-0207).
Hence, function declaration for expression blocks including rules based on grammar regular-
expressions that afford overloading of operators to enhance on associativity and precedence usability of C-style and/or Javascript expressions formed from the operators overloads for enhancing their usability in script interpreter environment is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement formation of script content for realizing a workflow task in Stump modeling framework so that generating a script associated with workflow block design would include textual description of
1) an imported function block and function block parameter settings as per the declaration for variables and functions as in Thaller,
2) an overloaded function block as in the C-style grammar and Regular expressions provided in Nuss interpreter code formation;
3) an event scheduling from information derived from script library to schedule script calls
for state data and process data capture as per (V) from above; because
inclusion of declaration describing parameter setting and requisites for a function as well as
parameter setting (e.g. for sequencing capture events by a reporting script) as part of external
description used for translating a script-included function call into its executable/native language in
which the function is being compiled enables embedding the one or more of such native calls within the flow of scripting language, according to which the underlying functions in this native form can be realized via the sequence of interpreting the syntax of a script; so to invoke sequence of actions or time-related events by the script interpreter, in the sense that actual execution of native code underlying the script execution would realize prompt invocation of tasks expected of the workflow construed from function blocks arranged on a workflow design interface or prompt realization of script-based recording of task execution data; whereas inclusion of descriptive information of function overloads as part of the external meta- information in support of native code translation to embed within a script file would enrich the precedence and associativity aspect of binding operators forming the expressions or sub-expressions to be realized with the call invocation of the script, thereby enriching the applicability scale of function calls written a given programming language expressions for use in translating internal native calling code of a given script interpreter engine.
As per claim 11, Stump discloses apparatus as claimed in claim 10, wherein the script
comprises: a textual description of an imported function block, a textual description of an overloaded function block, a textual description of function block parameter settings, and a textual description of event scheduling.
(all of which having been addressed in claim 4)
Claim(s) 6, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stump et al,
USPubN: 2022/0299982 (herein Stump) in view of Crisan et al, USPubN: 2003/0191769 (herein
Crisan) further in view of Miao, Ze-feng, CN 101483562, (translation), 07-15-2009, 14 pgs (herein
Miao) Xu et al, CN 110417760 (translation), 11-05, 2019, 12 pgs (herein XuDong) and Haswell et al, USPubN: 2005/0193269 (herein Haswell) and Xu, Yan-bin et al, CN 107995026 (translation), 5-04-2018, 11 pgs (herein XuYan) and further of Stump et al, USPubN: 2021/0096978 (herein Stump2)
As per claim 6, Stump discloses method as claimed in claim 1, wherein:
the at least one control object comprises a first control object and a second control object
operated in cooperation (para 0089; functionality that can be shared across multiple components
controllers can cooperate with various network devices - para 0134); interpreting and
executing the script by means of a script engine (refer to claim 1)
Stump does not explicitly disclose interpreting and executing the script (using a script
engine) in terms of:
(i) executing a script associated with the first control object by means of a first script engine
on a first runtime executor, and executing a script associated with the second control object by
means of a second script engine on a second runtime executor;
(ii) realizing, by means of middleware, control object scheduling between the first runtime
executor and the second runtime executor.
Obviousness in using middleware as a message service to enable bidirectional passing of
control and receiving execution data from control objects due to relationships between automation
objects invoked as part of a runtime cooperation between control objects (tanks, valves, pumps etc. - motors, motor drives, controllers, stations, conveyors, drives - see claim 1) has been rendered
obvious as set forth in claim 2, according to which the middleware (by virtue of obviousness) would convey state data and process data as part of control and monitoring instructions from a script associated with sequence of flow passed between a workflow/graphical framework and the control objects of the industrial process, where the script can be configured to schedule events associated with realizing a workflow or also to collect runtime data therefrom (e.g. as a reporting script), the scheduling of events by a script set as obvious in claim 4.
Passing information (e.g. via messaging middleware - per claim 2) between cooperative
automation objects in Stump's industrial workflow can include information exchange between two
execution runtimes, each associated with corresponding control objects operations set by the
automation objects being orchestrated or scheduled by a script (per claim 4).
Hence, realizing, by means of middleware, control object scheduling between different
execution contexts in which, because of the operational interdependency, corresponding automation objects (AOs) interrelate with each other is recognized.
Workflow execution contexts having each automation objects for a respective set of control
objects in terms of first execution engine using a first script interpretation instance or a second script interpretation instance is shown in Stump2; that is, Stump2 describes a IDE type of graphical design for configuring input and components for visualizing/defining an industrial project in terms of automation objects that represent instances of industrial assets which also have respective test scripts associated therewith (para 0003-0005) where the industrial control environment would be able to control processes and machines in executing respective control programs destined for the industrial assets under control by the environment (para 0032)
Hence, first script execution engine having relationship with a second execution script engine as part of different test scripts of corresponding set of automation objects defined and created under orchestration or scheduling by a visualization framework or configuration layer of the industrial project is recognized.
Therefore, based on the inter-relationship and cooperative aspect (para 0089) among
controllers (or PLC) of automation objects, of industrial objects dependency on each other to realize an industrial operation in Stump (para 0134) in accordance with interaction diagrams depicting inter- related states between events (para 0125), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the workflow framework in Stump so that configuring script for realizing components of the workflow design would include
(1) one or more respective scripts for each set of automation object and control objects,
whereby to enable executing a script associated with the first control object by means of a first script engine on a first runtime executor, and executing a script associated with the second control
object by means of a second script engine on a second runtime executor - as set forth in Stump2;
and
(2) realizing, by means of middleware (as per rationale in claim 2), control object scheduling
between the first runtime executor and the second runtime executor, as per the inter-cooperation or
functional dependency between different automation runtimes which utilize each a respective script executer - as per Stump2; because
possibility to obtain state of process and events underlying the interaction and cooperative
dependency between contexts of automation objects and control objects under direction and setting from the workflow modeling/configuration layer via use of middleware to report or convey state information from of respective script execution engine associated with each automation contexts would benefit from secure and protocol-compliant bidirectional transport provision by the
middleware and instantiation of respective script execution(s) so to realize control action by each
automation object set and collecting data returned therefrom as set forth above, would enable a
centralized data collection layer to aggregate behavior of the respective automation objects in
association with specific control objects for its correlation with that of other automation sets in
order to not only estimate efficiency or conformance of the functional cooperation among objects
automated for the industrial project/design; but also to detect imperfection in the arrangement of
equipment and automated logic for a specific automation process intended by a developer design, so that developer's adjustment to the control software can be imparted to the control code, including for instance, corrective reconfiguration made to one or more corresponding scripts destined for one or more instances of workflow rendering or monitoring, all of which in tum, construed as observables used for evaluating response of respective automation set by a centralized analytic aspect of the automation framework, so to finetune quality of the overall workflow design.
As per claim 13, refer to rationale of claim 6.
Claim(s) 7, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stump et al,
USPubN: 2022/0299982 (herein Stump) in view of Crisan et al, USPubN: 2003/0191769 (herein
Crisan) further in view of Chouinard et al, USPubN: 2010/0082133 (herein Chouinard)
As per claim 7, Stump does not explicitly disclose method as claimed in claim 1, wherein the workflow description data is generated in accordance with IEC 61499 standard.
Chouinard discloses flexible architecture and HMI support (para 0025-0026; Fig. 1, Fig.6)
to expose control models and features of automation collaborative framework via effect of
developers setting and designing per effect of technology such as Abstract Automation Model
derived from a common based model such as IEC 61499 as part of development interfaces
associated with a development program or environment (para 0027)
Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the automation objects model in Stump so that abstracted representation as basis for the design included workflow description data generated in accordance
with IEC 61499 standard as set forth in Chouinard; because
this descriptive automation language standard would support the majority of known
automation languages in the modern world thus can be serve as basis for developers to apply
programming standard therefrom as well as adapting the abstract model description thereof in
defining control structures and abstract data objects having configuration, resource and program that necessary benefit from world-level technological advance and conformance to a known and modern standards, thereby alleviate exposure of developers and modeling effort to ill-effects and flaws caused by non-conformance to established standards
As per claim 14, refer to rationale of claim 7.
Response to Arguments
Applicant's arguments filed 5/01/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
Applicants have submitted that no rationale is provided to explain the underpinnings that support the legal conclusion rendered by the 103 rejection on the alleged obviousness of features “receiving … workflow description data” , “extracting from … description data … a workflow task model”, “generating on basis of the … task model, a text-based script for realizing the workflow task” and “interpreting the script”, notably on basis of Stump by the Office Action, when in fact, test scripts as cited is for test and debug automation objects associated with project (Applicants Remarks pg. 7)
There is insufficient showing of facts pointing out precisely where the cited portions from Stump fail to meet a specific limitation of the claim; instead, what is perceived is a short statement as to the fact that testing ad debugging aspect in Stump’s script cannot be enough to render obvious the limitations “receiving”, “extracting”, “generating” and “interpreting” mentioned above. Clearly, the above remark about Stump script amounts to a largely improperly presented prima facie case of rebut. Moreover, the language of the above limitations has changed substantially and the merits of the amended feature have been addressed with a different ground of rejection. In other words, the Applicant’s allegation is deemed largely non conformant with a prima facie case of correspondence between a specific limitation and a specific prong of rejection or at best MOOT in view of the amendments.
In all, the features provided with the current Amendment stand rejected as set forth in the office action from above.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
May 26, 2026
Prosecution Insights