DETAILED ACTION
This action is responsive to the Applicant’s response filed 8/27/26.
As indicated in Applicant’s response, claims 1, 8 have been amended, and claims 3, 10, 15-19 cancelled. Claims 1-2, 4-9, 11-14 remain and are pending prosecution.
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 an Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the following 2-step analysis.
Step 1: the claim is statutorily directed to a method/process category
Step 2A:
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.
The step recited as generating text script by “converting description data to text-based script” can be reasonably be performed by a mental process or via use of pen/paper.
Accordingly, this “extracting” and the “converting” (to textual description) step can be considered activities that fall into flow of a Mental processes as one Abstract Idea subgroup. MPEP 2106.04(a)
Prong Two:
The elements recited as controllable machines, station host, runtime executor, function block of virtual machine, script engine, programming tool with HMI are viewed as mere description of generic functionalities or computer tools (recited in a high-level of generality) to receive input and interpret text, all of which being well-known computer components provided as one or more tools by which the Abstract idea operates; hence these elements, absent detailed interaction with the deep hardware layer of a computer, cannot be seen as a novel implementation to the abstracted step of extracting data indicative of transforming the process that is based on information extracting and text interpreting.
The elements recited as "multiple blocks" associated with control object and relationships between control blocks in form of “text descriptions” 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 recital of “runtime executor”, “executing … on a virtual machine”, “interpreting … using a script engine” amounts to mere enumeration of descriptive function without deep implementation details: mere listing of functions expressed in a very high level of generality fails to demonstrate that these limitations achieve a non-conventional transformation worthed of a patentable application. The elements recited as "generating a text-based script" (including text description of model blocks) and "executing" (the script) to allow “instantiation of function block of workflow", “executing the function block on a virtual machine” can be considered well-known computer functions, standard computer activities using known tools provided as extra-solution or post-activities that make use of result from the abstracted steps of “extracting” and text “converting”, and as such, these elements fail to teach a specific improvement to the technical field of extracting and text description generation; nor can they transform of the mental processes of "extracting" and “converting” (data to text) into a practical application. MPEP 2106.05(a), (c) (g)
Step 2B:
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" or “executing the function block on a virtual machine” can be viewed as well-understood computer functions provided otherwise – MPEP 2106.05(g) - as extra-solution support functionalities that make use of result from an Abstract Idea, set forth in step IIA. In fact, the recital of “runtime executor”, “executing … on a virtual machine”, “interpreting … using a script engine” amounts to mere enumeration of descriptive function without deep implementation details; i.e. mere listing of functions expressed in a very high level of generality fails to demonstrate that these limitations achieve a non-conventional transformation worthed of a patentable application – MPEP 2106.05 (a)(b)( c)(d)( e) - For instance, generating function block based on a script or interpreting text by a executor (without recompiling) falls into the broadly-known computer interpreting capability and as such, cannot amount to un-conventional technique that effectively improves computer technology associated with extraction of information, as the script-based creation of function block at best is construed as 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 of claim 1 is not tied to non-conventional improvement showing how engineering tool/functions (computer-based HMI, text-based script, runtime executor, text interpreting) have specifically provided improvement or technical transformation to this computer core or HW layer of this 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 1 is non-eligible under the 35 USC § 101 statute.
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: claim 8 is directed to a apparatus/product category
Step 2A
Prong One:
The step recited as (parser to) "extract (from description data), a workflow task model" (associated with a control object), “converting description to text” 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 (via converting) and 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 controllable machines, function block of virtual machine, script engine, programming tool with HMI are viewed as mere description of generic functionalities or computer tools (recited in a high-level of generality) to receive input and interpret text, all of which being well-known computer components provided as one or more tools by which the Abstract idea operates; hence these elements, absent detailed interaction with the deep hardware layer of a computer, cannot be seen as a novel implementation to the abstracted step of extracting data indicative of transforming the process that is based on information extracting and text interpreting.
The elements recited as "multiple blocks" associated with control object and relationships between control blocks in form of “text descriptions” 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 or pre-activity step considered well-known by the circuits as part of the flow action of a Mental Process type exception. MPEP 2106.05(g) - The recital of “executable script”, “executing … on a virtual machine”, “interpreting … using a script engine” amounts to mere enumeration of descriptive functions without deep implementation details: mere listing of functions expressed in a very high level of generality fails to demonstrate that these limitations achieve a non-conventional transformation worthed of a patentable application. MPEP 2106.05(d) - The elements recited as "generate … a text-based script" (including text description of model blocks) and "executing" (the script) to allow “instantiation of function block of workflow", “executing the function block on a virtual machine” can be considered well-known computer functions, standard computer activities (via use of pen/paper) provided as extra-solution or post-activities that make use of result from the abstracted steps of “extracting” and text “converting”, and as such, these elements fail to teach a specific improvement to the technical field of extracting and text description generation; nor can they transform of the mental processes of "extracting" and “converting” (data to text) into a practical application. MPEP 2106.05(a), (c) (g)
As a whole, and in view of the above elements of claim 8 cannot integrate the above
Abstract Idea from prong One into a Practical Application.
Step 2B:
Considered together with the mental process, 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. Likewise, the additional element observed as "generating a text-based script" such as to "allow creation of function block" or “executing the function block on a virtual machine” can be viewed as well-understood computer functions provided as extra-solution support functionalities that make use of result from an Abstract Idea, set forth in step 2A. In fact, the recital of “interpret and execute… text-based script (by an engine) and/or “dynamic creation of … function block …without recompilation” amount to mere enumeration of descriptive function (expressed in its nominal terms) without deep implementation details; i.e. mere listing of functions expressed in a very high level of generality fails to demonstrate that these limitations achieve a non-conventional transformation worthed of a patentable application – MPEP 2106.05 (a)(b)( c)(d)( e) - nor can these additional elements be viewed as non-conventional technique that effectively improves computer technology associated with extraction of information, as the script-based creation of function block at best is construed as 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 apparatus claim 8 is therefore deemed non-eligible under the 35 USC § 101 statute.
Eligibility under step 2B 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) and Mueck, USPubN: 2019/0004834 (herein Mueck)
As per claim 1, Stump discloses a computer-implemented method for a runtime executor
to execute 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 (see configuration platform below; industrial IDE … implement set of services and workflows spanning not only design but also commissioning, operation and maintenance … controller programming and HMI development- para 0052) running a programming tool accepting the user input via an interactive human-machine interface (see 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 workflow description data (control logic, structured text, sequential function charts - para 0057; 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; 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),
wherein the workflow task model (para 0052) describes multiple function blocks (ladder logic, function blocks – para 0060) associated with the at least one control object (Fig. 6; para 0054), and at least one connection relationship between respective ones of the multiple function blocks (control logic, structured text, sequential function charts - para 0057; automation objects defined by the model 602 … any relationships between the objects 222 defined by the model – para 0119; automation objects and their functional relationships … reflect arrangement of industrial assets … make up the automation process for which the system project 302 is being developed – para 0121)
generating, a text-based script (test scripts - Fig. 10-11; para 0050; para 0094-0096, 0098) for realizing (component 210 can execute one or more scripts 1002 - para 0095-0096) the workflow task by converting the workflow description data to the text-based script (translate state machine drawings to a corresponding programming sequence – para 0060), the text-based script (translate to … a corresponding programming sequence – para 0060 - Note1: programming sequence in form of script – para 0095-0096 - reads on text-based script converted from state machine drawings or control logic, structured text, sequential function charts – see para 0057) including textual descriptions of respective ones of the multiple function blocks (structured text, function block … for carrying out a desired industrial sequence – para 0039) of the workflow task model (control code or other elements of the system project according to a sequence defined by the test scripts … initiating control routines of the project 302 according to a defined sequence … linkages between control routines – para 0095; scripts … define testing sequences verify linkages… e.g. control code – para 0096); and
interpreting and executing the text-based script using a script engine (component 210 - para 0094; Fig. 10) using runtime executor to control (see para 0095, 0096 from above) the operation of the control objects, including instantiating a function block (control programming … function block diagrams etc. – para 0108; control programs controlling signals generated by controllers …including ladder logic … function block diagram – para 0033; function block … for carrying out a desired industrial sequence – para 0039; automation objects … building blocks for the industrial automation system project – para 0129) associated with the at least one control object (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 generating and executing a text-based script in terms of
(i) generating, on basis of the workflow task model, 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
(ii) executing instantiated function block with execution of the function block on a virtual machine;
As for (i)
Script execution in Stump includes realization of interaction between logic of AOs under
the direction and logical order set by the script sequencing 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, which entails that runtime interpretation of script code allows dynamic creation of executable object and direct invocation of object corresponding to at least one function block among hierarchy of function blocks in the workflow model (e.g. control logic, structured text, sequential function charts - para 0057) or workflow task model, i.e. the dynamic creation and invocation of function block under logic control of the interpretable script without need for this function block to be compiled or re-compiled – this dynamic creation/invocation referred herein as (*)
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 constituted from user-defined
functions (WSDL 82, derive UDF 86 - Fig. 10; Workflow 220 UDF 208a, 208b 208n- Fig. 11)
each as a building element 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 thereof in generating an executable script file (para 0144) 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.
As for (ii)
Stump discloses use of virtual machines (para 0148) with a virtualization embodiment implementing runtime processes of the automation process and the IDE environment (para 0046)
Muek discloses resources for implementation adaptable to certain applications (cellular, automotive) such as Radio Apps or industrial environment/automation (para 0092), where software components include SW calls invoking HW processing elements via use virtual machine function (para 0094-0096), where HW processing elements control VM operation of radio components (Fig. 5) expressed via an Abstract Processing Elements (APEs) configuration fabric (Fig. 6), where examination of APEs identifies a respective virtual machine configured to execute a function block defined as configcode elements of the radio application represented on the abstract fabric (para 0055) of RVM (“radio virtual machines”) workflow. Hence, use of a VM for each to implement execution or calls to a corresponding design functional block representing the function invoked by a corresponding VM is recognized.
Therefore, based on dynamic creation and invocation of function block under logic control of the interpretable script without need for this function block to be compiled or re-compiled as set forth in (*) it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement execution of workflow tasks in script-based industrial control process execution in Stump so that
1) generation and execution of script is based on the workflow task model 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 shown in Crisan; and
2) where for each function block of the workflow model, a VM machine can be implemented to execute code of the function block as shown in VM calls implementation by Mueck via observation of a design fabric; because
implementing interpretable text-script to execute workflow task of a industrial process would facilitate programming of control software which is basically interpreter-oriented and would not require complex and language-compliant compiler resources, notably when the text-based instruction flow of the script calling reflects the very workflow design of the developers after which function calling is being modeled to control the industrial process and use of virtual machine to implement code execution of functional block observed from the workflow design as part of a virtualization scheme would alleviate extraneous binding of physical resources (physical memory allocation) by the host platform on which the industrial process modeled with its interconnected functional block is being built and tested via a control script as set forth in Stump.
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 (function block … for carrying out a desired industrial sequence – para 0039; para 0033).
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(i) 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
claim 1);
a script generator configured to generate, on 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 A(i) 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 A(i) of claim 1) of the workflow task model without re-compiling (refer to rationale A(i)
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) and Mueck, USPubN: 2019/0004834 (herein Mueck), 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) and Mueck, USPubN: 2019/0004834 (herein Mueck), 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 (**)
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)
Claims 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) and Mueck, USPubN: 2019/0004834 (herein Mueck), 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 set forth with said middleware reporting.
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 inter-dependency, 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.
Claims 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) and Mueck, USPubN: 2019/0004834 (herein Mueck), 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 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 8/27/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
The Applicant has submitted that claim 1, as amended, includes computer-implemented runtime executor with script engine instantiating function block associated with control object and execution of the block on virtual machine. Thus, as a whole and including the script-based dynamic rendering of workflow functions in the Specifications, the claim is not directed to the alleged “mental processes” in prong one, and does not merely rely on generic computer tools to perform the abstract idea; nor the ordered steps of receiving, extracting, converting, instantiating and executing function block as claimed amount to mere post-solution activities as alleged in step 2B (Applicant's Remarks pg. 7-8). The 101 rejection analyzes each prong (of the Alice/Mayo) in relation to whether the additional elements surround the abstract steps of extracting and converting can demonstrate a transformation of significance that improve the core hardware and functioning of the system on which the extracting and converting take place. Also analyzed, is whether the additional elements in a combined order of operation or linkage would convey that a transformation of significance has taken place to improve mechanism of the Abstract Idea beyond a high level of generality, because mere enumeration of descriptive functionalities without in-depth detail on interaction and cooperation at the level of HW and software granularity, would make it hard to persuade that evidence of a technical transformation has raised the Abstract Idea significantly more than one such generic enumeration of known or well-understood concepts, the concepts of the likes of virtual machine, script executor, invoked function block by a interpreter, dynamic creation of function block associated with text-based script, converting description into text. Besides, raised on patentability merits on newly added limitations would be deemed largely moot in view of the adjusted grounds of rejection necessitated by the addition.
The Applicant has submitted that alleged that claim 1, as amended, describes workflow model, workflow task description and conversion of a text-based script based therefrom, which when executed dynamically instantiates a respective function block, for execution to control the operations, such that, in regard to which, the script execution in Stump merely verifies responses from simulated test input, as opposed to converting workflow data into a script which executes to dynamically instantiates function blocks and execute them (Applicant's Remarks pg. 10). Script is not a programming record that operates with compiled objects, but instead, converts at runtime textual instruction into script objects then invokes the executable portion underlying these objects on the fly. The script execution and dynamic creation scenario just described by the Applicant falls smack into how a script file normally operates and invokes its text-interpreted objects using a interpreter engine. The allegation on Stump is deemed non-persuasive.
The Applicant has submitted that Crisan is about a script that registers objects oriented classes usable within a DBMs context associated with WSDL information passing, not a script to interpret function blocks to control machines, and if combined to Stump, Crisan teachings will fail to yield expected result, which might demise the purpose of the obviousness rationale (Applicant's Remarks pg. 11-12). The claim feature in regard to controlling operations of a industrial process by dynamic instantiation of function blocks as relied upon by the applicant, when construed from the claim language, is deemed largely insufficient a syntax to establish actual capability of the script in the sense that, concurrent each dynamic instantiating (emphasis here), the script executes respective function (of newly instantiated block control) in directing/affecting a given operation or equipment (emphasis here) of the industrial process. What appears to be a non-analogous art deficiency as a flaw raised by the Applicant against the office action is not consistent with the KSR ruling to the effect that known and successes achieved based on similar mechanisms ( such as implementing workflow description into text scripting language) can be used as teachings into formulation of grounds of obviousness. The allegation is deemed largely inconclusive.
In all, the claims as amended, stand rejected by the latest office action set forth above.
Conclusion
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
Septembre 19, 2026
