DETAILED ACTION
This action is responsive to the Applicant’s response filed 01/12/26.
As indicated in Applicant’s response, claims 1, 8 have been amended, and claims 15-19 cancelled. Claims 1-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 as detailed in the following 2 steps analysis.
Step I: the claim is statutorily directed to a method/process category
Step II, A:
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.
Step II, B:
Considered together with the mental process of “extracting”, the additional element of “receiving” is construed as mere generic computer function (e.g. input/output) that amounts to standard support for the step of mental extraction, as this does not upconvert this Abstract Idea of extracting into patent-eligible practical application. Likewise, the additional element observed as “generating script” and “executing it” can be considered well-known, standard computer activities provided as post-activity support to the abstracted step of extracting, and as such, this additional element cannot transform the mental process of “extracting” into an eligible subject matter.
The method claim is not tied to non-conventional improvement showing how engineering tool/functions have provided improvement to a technical field, since the rather use of cognitive process performed by a human like mental capability is deemed a method that cannot (i) be integrated into a Practical Application or (ii) render 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) 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 as detailed in the following 2 steps analysis
Step I: the claim is statutorily directed to an apparatus category
Step II, A:
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. Accordingly, this extracting step can be considered an abstract idea, See MPEP 2106.04(a)(2), under step2A. The apparatus of claim 8 is thus non-eligible a subject matter under the 101 statute as an Abstract Idea cannot be seen as susceptible to be integrated into a Practical Application
For step II, B:
The additional elements such as “communication interface” (to receive) can be viewed as standard computer I/O means that support interaction between computer user and the extracting step; hence cannot be seen as a particular non-conventional support that improve the technique of extracting a abstract model. The element recited as “parser” is not accompanied by details that explicitly signify use of non-conventional techniques to support or improve upon the abstracted step of “extracting” a model, hence can be subsumed as parser capability of a user or a computer that extracts data; since use of computer support to acquire data is a well-known, well-understood routine, practice. The elements recited as “control object”, “script generator” and “script engine” without further details, amount to known and conventional use of computer support to carry out activity based on result (model, workflow task) of the Abstract Idea or mental steps of parsing or extracting; hence are construed as insignificant elements that fail to indicate non-conventional and/or inventive technological means for improving upon the human process of extracting data. Further, the steps of receiving (workflow description) and generating (text-based script) have been identified as known techniques or conventional ways to support pre-activity to the Abstract Idea of “extracting” and/or post-activity subsequent to achieved result from the Abstract Idea; hence, cannot render the Abstract Idea of step 2A for it to amount to much more than a Judicial Exception.
In all, the apparatus of claim 8 fails to show how the additional elements therein can bring forth inventiveness and improvement to the field of technology that generate an abstract model via well-known steps of extracting and parsing. Claim 8 per step2B cannot be integrated into a Practical application. See MPEP § 2106.05 a, b, d and g.
Eligibility per step 2B analysis of 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 3 recites description of a workflow model being associated with control object and connection relationships among blocks. This “additional element” per step 2B, fails to bring forth any unconventional technique that inventively modify the extracting process of 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-14, are mere respective replica of claims 2-7, hence fails to render the abstract Idea of claim 8 significantly much more than a Judicial exception.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3, 5, 8, 10, 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 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 O103; collection of automation objects ... tanks, pumps, valves, motor drives, conveyers -
para 0115; para 0122), the method comprising:
receiving, from 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 (component 204 … receive user input data and render output data via the IDE client, input data than can be received via various user interface component 204 … include industrial design specifications or engineering drawings, DSL definitions image data, project testing scripts or other such input – para 0048; developers can submit design input 512 including … control logic, structured text, sequential function charts – para 0057), description data (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) 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, a workflow task model (e.g. model 602a ➔ generation component 206 [Wingdings font/0xDF][Wingdings font/0xE0]editor 224 ➔ project model 302 - Fig. 15; model 302 - Fig. 11) associated with the at least one control object (tanks, pumps, valves, motor drives, conveyors - para 0115);
generating, on the basis of the definition data, a text-based script (test scripts - Fig.
10-11; para 0050; para 0094-0096, 0098) for realizing the workflow task; and interpreting and executing the script (component 210 can execute one or more ... scripts 1002 - para 0095-0096) using a script engine (component 210 - para 0094; Fig. 10).
A) Stump does not explicitly disclose receiving definition data associated with a workflow task or automation objects (associated with a workflow task executed across at least one control
object) in terms of
receiving, from user input from a engineering station running a programming tool, 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).
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 into input and output of objects comprised 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 used to implement calls as part of script invocations that comprise execution of a workflow task model 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.
As per claim 3, (see visualization and drawing from below) multiple function blocks (dashed line can be interpreted as a gearing relationship, bold line ... indicate a camming relationship ...
existing drawing ... to generate code and visualizations ... user's CAD drawings ... generate suitable code (ladder logic, function blocks ... based on analysis of the drawing ... project generation component 206 can ... translate state machine drawings to ... programming sequence - para 0060) associated with the at least one control object (see para 0059), and a connection relationship ((para 0090; see dash line, bold line from above; see Fig. 6; hierarchical relationship - claim 8, pg. 21) between the multiple function blocks.
As per claim 5, Stump discloses method as claimed in claim 3, 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, 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), workflow description data (refer to rationale A of claim 1) associated with a workflow task (refer to claim 1) executed across at least one (refer to claim 1) control object;
a parser configured to extract (refer to 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;
a script generator configured to generate, on the basis of the workflow task model (refer to
rationale of claim 1), a text- based script (refer to claim 1) for realizing the workflow task; and
a script engine module configured to interpret and execute (refer to claim 1) the script.
As per claim 10, Stump discloses apparatus as claimed in claim 8, 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 rejection of claim 3)
As per claim 12, refer to rejection of claim 5.
Claim(s) 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)
Further, 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 (*).
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 (per(*) from above) in Stump so that
middleware is utilized as a protocol compliant message (bidirectional) communication technology as
in Miao or XyYan 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, Stump discloses apparatus as claimed in claim 8, wherein the apparatus communicates with the programming tool via middleware to realize monitoring and control of an execution process of the workflow task, and this comprises at least one of:
the script engine module being configured to map, to the middleware, state data and process data relating to the execution process, so that the programming tool acquires the state data and the
process data;
the script engine module being configured to receive control information relating to the execution process from the programming tool via the middleware.
(all of which having been addressed in claim 2)
Claim(s) 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 3, wherein
generating, on the basis of the workflow task model, a text-based script for realizing the workflow
task, comprises generating
(i) 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 (**) 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) and Xu, Yan-bin et al, CN 107995026 (translation), 5-04-2018, 11 pgs (herein XuYan) and 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 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 a 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, Stump discloses apparatus as claimed in claim 8, wherein the at least one control object comprises
a first control object and a second control object operated in cooperation;
the script engine module is a first script engine module on a first runtime executor and is
configured to execute a script associated with the first control object, and
a script associated with the second control object is executed by means of a second script engine module on a second runtime executor; and
control object scheduling between the first runtime executor and the second runtime executor is realized by means of middleware.
(all of which having been addressed in 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, Stump discloses apparatus as claimed in claim 8, wherein the workflow description data is generated in accordance with IEC 61499 standard.
(refer to rejection of claim 7)
Response to Arguments
Applicant's arguments filed 12/12/25 (After Final response) have been fully considered but they are moot in light of the current grounds of rejection which have been necessitated by the latest amendments.
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.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Tuan A Vu/
Primary Examiner, Art Unit 2193
February 07, 2026