DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following NON-FINAL Office Action is in response to Applicant’s communication filed 04/28/2026 regarding Application 18/832,492.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/28/2026 has been entered.
Status of Claim(s)
Claim(s) 1-14 is/are currently pending and are rejected as follows
Response to Arguments – 103 Rejection
Applicant’s arguments in regards to the previously applied 103 rejection are rendered moot in view of the amended prior art rejection below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Geipel (EP 4083722 A1) in view of Luvaas (US 11,435,871 B1)
Claim(s) 1, 10, and 14 –
Geipel discloses the following:
At least one memory storing computer-readable code (Geipel: Paragraph 34, "According to a third aspect, a computer program product directly loadable into the internal memory of a digital computer is proposed, comprising software code portions for performing the steps according to one of the preceding claims when said product is run on said digital computer.")
At least one processor to call the computer-readable code (Geipel: Paragraph 34, "According to a third aspect, a computer program product directly loadable into the internal memory of a digital computer is proposed, comprising software code portions for performing the steps according to one of the preceding claims when said product is run on said digital computer.")
receiving a behavior tree construction operation performed by a user on a graphical user interface (GUI), the construction operation comprising an addition operation for a behavior tree node, the behavior tree node comprising a first decorator node, and the first decorator node comprising a first worklink and a first decorative layer adapted to decorating the first worklink… (Geipel: Paragraph 8, "According to a first aspect, a computer-implemented method for automatically generating a behavior tree program for controlling a machine is proposed, the method comprising the steps of transmitting a sequence of machine commands input by a user from a user interface to a controller, receiving supervision data in the user interface from the controller while the machine commands are executed in the controller controlling the machine, observing and copying the machine commands and supervision data transmitted between the controller and the user interface, storing the machine commands and the supervision data in a logging unit, generating a behavior tree program derived from the stored machine commands and the supervision data by statistical inference, and sending the generated behavior tree program to the controller unit to control the machine."; Paragraph 28, "The generated behavior tree program can be provided directly from the inferring unit to the controller or the generated behavior tree program can be transferred from the inferring unit to the user interface which forwards it from the user interface to the controller when an acknowledgement of the user is received. The direct provision allows a fast implementation of the behavior tree. The indirect provision via user interface allows the user to approve, correct or prohibit the implementation, i.e., the execution of the automatically generated behavior tree in the controller."; Paragraph 50, “The identification of decorators can also be supported by analysis of the log files. Decorators are attached to either a composite or a task and define whether a branch in the behavior tree, or even a single node, can be executed. The Decorator can also modify the success or failure status of the decorated task or composite.”; Paragraph 53, “Candidates for a "Wait" decorator can be identified by observation if the value of a specific variable changes at the same time as a new task starts. The example in Figure 5C shows a value change of a variable A correlating with a transition between tasks T54 and T55.”; Paragraph 55, “Figure 6 shows a behavior tree program 50 generated automatically by the assistance system 20. The behavior tree 50 controlling the system to move to a light barrier, see 51. The behavior tree component 52 represents a "sequence" composite. Behavior tree component 53 represents "wait for light-barrier = false", behavior tree component 54 represents "< > stop", component 55 represents "wait for sensor_2 = true and component 56 represents "< > go right. The generated program learnt that: sensor_2 triggers the start of the conveyor belt (wait for value change of sensor 2) light_barrier stops the conveyor belt (wait for value change of light_barrier).”)
generating, a behavior tree comprising the first decorator node in response to the behavior tree construction operation and (Geipel: Paragraph 50, “The identification of decorators can also be supported by analysis of the log files. Decorators are attached to either a composite or a task and define whether a branch in the behavior tree, or even a single node, can be executed. The Decorator can also modify the success or failure status of the decorated task or composite.”; Paragraph 53, “Candidates for a "Wait" decorator can be identified by observation if the value of a specific variable changes at the same time as a new task starts. The example in Figure 5C shows a value change of a variable A correlating with a transition between tasks T54 and T55.”; Paragraph 55, “Figure 6 shows a behavior tree program 50 generated automatically by the assistance system 20. The behavior tree 50 controlling the system to move to a light barrier, see 51. The behavior tree component 52 represents a "sequence" composite. Behavior tree component 53 represents "wait for light-barrier = false", behavior tree component 54 represents "< > stop", component 55 represents "wait for sensor_2 = true and component 56 represents "< > go right. The generated program learnt that: sensor_2 triggers the start of the conveyor belt (wait for value change of sensor 2) light_barrier stops the conveyor belt (wait for value change of light_barrier).”; Paragraph 57, "In a first step S 1 a sequence of machine commands input by the user 22 at the user interface 21 are transmitted to the controller unit 23. While the machine commands are executed in the controller unit 23 supervision data are received, see step S2, in the user interface 21 from the controller unit 23. The machine commands and supervision data are transferred on a communication connection between the user interface 21 and the controller unit 23, e.g., via a protocol messages according to OPV UA, Profinet and the like. A Machine command activates a machine behavior, a functionality, or an operational state in the machine 24. Supervision data comprises status information and/or sensor data of the machine when controlled by the controller executing the machine commands. The machine commands and supervision data are observed and copied at the communication connection between the controller 23 and the user interface 21, see step S3. Subsequently in step S4, the machine commands and the supervision data are stored in the logging unit 26."; Paragraph 58, "In step S5, a behavior tree program is derived from the stored machine commands and the supervision data by machine learning, especially by statistical interference. A least one task of the behavior tree is derived from at least one machine command at the inference unit 27. The structure and the components, i.e., composites and decorators of the behavior tree are inferred by analysing, which of the derived tasks are executed in which temporal relation to each other, the return value of the supervision data, the parameter settings for the task with respect to the execution of the task, the co-occurrence of supervision data values and changes of supervision data value with task execution, task cancellations and task parametrizations. the inference unit 27 provides suggestions for further machine commands to the user interface 21 to be entered by the user."; Paragraph 59, "The inference unit 27 provides suggestions for further machine commands to the user interface 21, which can in return be accepted and entered by the user. The suggestions can also be ignored and/or different machine commands or behavior task structure elements, i.e., tasks, composites or decorators can be entered. The inference unit 27 provides a recommendation for a behavior tree structure element to the user interface 21 based on an assumption with respect to a further intended machine operation for verification or modification of the recommendation. Finally, the generated behavior tree program is sent to the controller unit 23 to control the machine 24, see step S6.")
Geipel does not explicitly disclose the parsing of a tree for a workflow, however, in analogous art of workflow generation Luvaas discloses the following:
… the first decorator node selected based on a selection operation performed by the user on the GUI including a node library, the first decorative layer comprising a first decorator expression, and the first decorator node comprising a first display area and a second display area, the first display area adapted to displaying a type of the first decorator node and the second display area adapted to displaying the first decorator expression (Luvaas: Column 7 line 53 – Column 8 line 13, “The workflow platform 221 can store multiple workflow models 222, some of which may be received from the user device 210, and others may be received from other user devices and available to the user device 210. The workflow platform 221 can also maintain assembly rules 224, a subset or the entirety of which can be sent to the workflow assembly application 212 to support the workflow creating. Further, the workflow platform 221 can maintain a library 226 of executable codes, of which can correspond to a node type. Executable code can be application program code or code of an API for an application that may reside on a remote system. The executable codes can be predefined by a service provider of the workflow platform 221 or collected over time from one or more users. The workflow platform 221 can also include an execution engine 228 for runtime executions of the workflow models 222. For instance, the workflow models 222 include a copy of the workflow model 218. The execution engine 228 parses this copy, determines the executable codes and their execution sequence and parameters, and uses the library 226 to then execute each executable code according to the execution sequence and the parameters of that executable code. Data generated by the execution of the executable code can be stored in the data store 240 and, depending on the execution sequence, can be input to the next executable code. The final data output can be stored in the data destination 250.”; Column 11 lines 6-54, “Visual guidance is shown to the user while a node's icon is added from the menu area to the workspace assembly area (e.g., via a drag-and-drop interaction) in the form of drop zones that identify the possible placement locations where the icon can be dropped. These drop zones are displayed based on the node type of the node being added to the workflow, the node types of nodes already in the workflow, and the position of such nodes relative to each other or the terminus indicators. Such drop zones determination can rely on assembly rules, whereby the node type and the process identifier are used in a look up of the assembly rules. Drop zones appear overlaid on top of applicable flow control indicators and to either side of existing node icons where a branch in the workflow would be allowed. These drop zones give a clear visual indicator of where the node's icon can be placed based on otherwise obscure or complex assembly rules. Flow control indicators where the node cannot be placed do not display drop zones and do not allow icon-dropping into that location or show node previews at that location. As a node's icon gets close to a drop zone, the workflow can be re-arranged in order to present a preview of how this icon will appear once it is in the drop zone. This preview can include a partially transparent node indicator. In order to make room for this node indicator, the icons and other visual elements downstream of the node indicator on the current flow branch can be shifted downwards. Increasingly complex workflows may necessitate the shifting of more visual elements along with entire branches in order to make room for the preview. This mechanism can also give the user a preview of how the entire workflow will need to be re-arranged in order to accommodate a new node at the target location. The user can use this visual data to help inform their node placement decisions. As illustrated in FIG. 6, the user selects an icon 610 representing a node and performs a drag-and-drop interaction 620 thereon to move the icon 610 from the menu area to the workflow assembly area. Given the node type and the existing workflow model, the assembly rules identify possible placement locations. These placement locations are shown as drop zones using visual indicators 630 (illustrated as a plus sign in a circle). Upon approaching one of the visual indicators (e.g., the distance between the visual indicator and the icon 610 is less than a threshold number of pixels), the visual indicator is replaced with a preview 640 of the icon 610. Upon placement at the drop zone, the workflow is re-arranged as needed and the placed icon 650 is shown as being connected in the workflow.”; Column 17 lines 32-60, “The view model 1242 may include multiple logical layers, such as a UI layer and an operation layer. In the UI layer, a number of workflow node view types are implemented, each of which wraps a workflow node object and exposes APIs and attributes used for UI rendering and operations. The view model 1242 can include a list of node view objects that correspond to different backend steps processing data streams. Except for the node attributes inherited from the node objects of the workflow model 1244, each node view object maintains a parents list and children list that contains the pointers of their parent node objects and child node objects, thereby establishing the relationships between nodes and their execution order. This doubly-connected graph structure can help the workflow assembly application 1210 to quickly locate related nodes without traversing the entire graph (or iterate all node IDs) and thus speed up the workflow operations. The operation layer is built on top of the UI layer, where a number of basic operations are implemented for manipulating a workflow view model instance, such as traverse, find, insert, remove, update, etc. This layer wraps the logics to handle the UI operations and only exposes APIs to the higher layer, which helps to reduce complexity. The UI layer is stored in the state store in the workflow assembly application 1210 and is considered as the single source of truth for rendering the workflow UI. For example, if the user adds a new node to the workflow, the workflow assembly application 1210 updates the UI layer through the operation layer in order to show the new node in the workflow assembly window.”)
parsing the behavior tree to generate a workflow, wherein the workflow instructs the first worklink to work under the decoration of the first decorative layer (Luvaas: Column 5 line 51 – Column 6 line 4, “The options 140 can trigger the execution of the workflow (or, more specifically, the parsing of the workflow model and execution of the referenced executable codes according to the execution sequence and the configuration information of each node). FIG. 1 illustrates two options: a run and a trial run. The run represents manual trigger for executing the workflow at runtime by using the data set(s) to which the workflow applies. In comparison, the trial run represents another manual trigger, but for executing the workflow by using a portion of the data set(s) (e.g., instead of all the data entries, the trial run uses the first two-hundred data entries (or some other configured number) or a data byte amount (e.g., one gigabyte of the data)). This way, the trial run allows the validation of the workflow by using the real, applicable data, but without the need to process the entire data set(s). Other triggers for the execution are possible. For example, a schedule with recurrent runtime execution. In another example, a data event can be subscribed to and, upon receiving, an indication of its occurrence, a runtime execution can be automatically performed.”; Column 7 line 54 – Column 8 line 13, “The workflow platform 221 can store multiple workflow models 222, some of which may be received from the user device 210, and others may be received from other user devices and available to the user device 210. The workflow platform 221 can also maintain assembly rules 224, a subset or the entirety of which can be sent to the workflow assembly application 212 to support the workflow creating. Further, the workflow platform 221 can maintain a library 226 of executable codes, of which can correspond to a node type. Executable code can be application program code or code of an API for an application that may reside on a remote system. The executable codes can be predefined by a service provider of the workflow platform 221 or collected over time from one or more users. The workflow platform 221 can also include an execution engine 228 for runtime executions of the workflow models 222. For instance, the workflow models 222 include a copy of the workflow model 218. The execution engine 228 parses this copy, determines the executable codes and their execution sequence and parameters, and uses the library 226 to then execute each executable code according to the execution sequence and the parameters of that executable code. Data generated by the execution of the executable code can be stored in the data store 240 and, depending on the execution sequence, can be input to the next executable code. The final data output can be stored in the data destination 250.”; Column 16 lines 39-46, “At operation 1108, the device presents the report. For example, the result is presented in a result panel of the workflow assembly window. At operation 1110, the device receives a request to view a node log message. The node log message can correspond to the portion of the report specific to a node of the workflow and can include, for instance, an error report about the processing by the node and/or a link to the relevant node-processed data.”)
Geipel discloses a method for creating behavior trees for the controlling of a machine. Luvaas discloses an interface for building, connecting and running nodes for a workflow. By the effective filing date of Applicant’s claimed invention it would have been obvious to one of ordinary skill in the art to combine the methods of Geipel with the teachings of Luvaas in order to improve the ease of access, and reduce inaccuracies in workflow assembly as disclosed by Luvaas (Luvaas: Column 3 lines 47-63, “Because the manual input can be avoided, the accuracy of the workflow can be improved, whereby user-induced errors may be eliminated. Further, the workflow assembly application provides a user-intuitive and guided tool to develop a properly executable workflow. The user need not be a programmer and need not have to create new program applications. Various different types of workflows can be developed, stored, modified over time, and made available to or shared between multiple users, thereby providing a scalable workflow platform.”)
Claim(s) 2 and 11 –
Geipel in view of Luvaas disclose the limitations of claims 1 and 10
Geipel further discloses the following:
the first decorative layer comprises a first decorator expression (Geipel: Paragraph 17, "The inference unit derives by the described analyzing steps further structure of the behavior tree, especially composites and decorators defining rules with respect to condition and sequence the tasks are executed. Especially a decorator is inferred by analyzing the co-occurrence of supervision data values and changes of supervision data value with task execution, task cancellations and task parametrizations. Co-occurrence means analyzing which supervision data values or value chances occur at the same time as or timely related to the execution of one or several tasks or the cancellation of one or several tasks or the parameter settings of the task."; Paragraph 59, "The inference unit 27 provides suggestions for further machine commands to the user interface 21, which can in return be accepted and entered by the user. The suggestions can also be ignored and/or different machine commands or behavior task structure elements, i.e., tasks, composites or decorators can be entered. The inference unit 27 provides a recommendation for a behavior tree structure element to the user interface 21 based on an assumption with respect to a further intended machine operation for verification or modification of the recommendation. Finally, the generated behavior tree program is sent to the controller unit 23 to control the machine 24, see step S6.")
the process of the first worklink working under the decoration of the first decorative layer comprises at least one of: determining execution condition of the first worklink based on the first decorator expression; determining number of executions of the first worklink based on the first decorator expression; determining execution time of the first worklink based on the first decorator expression; and determining execution state of the first worklink based on the first decorator expression. (Geipel: Paragraph 17, "The inference unit derives by the described analyzing steps further structure of the behavior tree, especially composites and decorators defining rules with respect to condition and sequence the tasks are executed. Especially a decorator is inferred by analyzing the cooccurrence of supervision data values and changes of supervision data value with task execution, task cancellations and task parametrizations. Co-occurrence means analyzing which supervision data values or value chances occur at the same time as or timely related to the execution of one or several tasks or the cancellation of one or several tasks or the parameter settings of the task."; Paragraph 59, "The inference unit 27 provides suggestions for further machine commands to the user interface 21, which can in return be accepted and entered by the user. The suggestions can also be ignored and/or different machine commands or behavior task structure elements, i.e., tasks, composites or decorators can be entered. The inference unit 27 provides a recommendation for a behavior tree structure element to the user interface 21 based on an assumption with respect to a further intended machine operation for verification or modification of the recommendation. Finally, the generated behavior tree program is sent to the controller unit 23 to control the machine 24, see step S6. ")
Claim(s) 3 –
Geipel in view of Luvaas disclose the limitations of claim 1
Geipel further discloses the following:
wherein the first worklink comprises a function block node configured to implement a service operation in the workflow (Geipel: Paragraph 36, "It is noted that in the following detailed description of embodiments the accompanying drawings are only schematic and that the illustrated elements are not necessarily shown to scale. Rather, the drawings are intended to illustrate functions and cooperation of components. Here, it is to be understood that any connection or coupling of functional blocks, devices, components, or other physical or functional elements could also be implemented by an indirect connection or coupling, e.g., via one or more intermediate elements. A connection or coupling of elements or components can for example be implemented by a wire-based, a wireless connection, and/or a combination of a wire-based and a wireless connection. Functional blocks can be implemented by dedicated hardware, by firmware and/or software installed on programmable hardware, and/or by a combination of dedicated hardware and firmware or software."; Paragraph 57, "In a first step S 1 a sequence of machine commands input by the user 22 at the user interface 21 are transmitted to the controller unit 23. While the machine commands are executed in the controller unit 23 supervision data are received, see step S2, in the user interface 21 from the controller unit 23. The machine commands and supervision data are transferred on a communication connection between the user interface 21 and the controller unit 23, e.g., via a protocol messages according to OPV UA, Profinet and the like. A Machine command activates a machine behavior, a functionality, or an operational state in the machine 24. Supervision data comprises status information and/or sensor data of the machine when controlled by the controller executing the machine commands. The machine commands and supervision data are observed and copied at the communication connection between the controller 23 and the user interface 21, see step S3. Subsequently in step S4, the machine commands and the supervision data are stored in the logging unit 26.")
Claim(s) 4 –
Geipel in view of Luvaas disclose the limitations of claim 1
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Luvaas teaches the limitation below:
the first worklink comprises a compositor node comprising a start block adapted to starting the executing of the compositor node, an end block adapted to ending executing the compositor node, and a plurality of candidate worklinks arranged between the start block and the end block, (Luvaas: Column 7 line 53 – Column 8 line 13, “The workflow platform 221 can store multiple workflow models 222, some of which may be received from the user device 210, and others may be received from other user devices and available to the user device 210. The workflow platform 221 can also maintain assembly rules 224, a subset or the entirety of which can be sent to the workflow assembly application 212 to support the workflow creating. Further, the workflow platform 221 can maintain a library 226 of executable codes, of which can correspond to a node type. Executable code can be application program code or code of an API for an application that may reside on a remote system. The executable codes can be predefined by a service provider of the workflow platform 221 or collected over time from one or more users. The workflow platform 221 can also include an execution engine 228 for runtime executions of the workflow models 222. For instance, the workflow models 222 include a copy of the workflow model 218. The execution engine 228 parses this copy, determines the executable codes and their execution sequence and parameters, and uses the library 226 to then execute each executable code according to the execution sequence and the parameters of that executable code. Data generated by the execution of the executable code can be stored in the data store 240 and, depending on the execution sequence, can be input to the next executable code. The final data output can be stored in the data destination 250.”; Column 11 lines 6-54, “Visual guidance is shown to the user while a node's icon is added from the menu area to the workspace assembly area (e.g., via a drag-and-drop interaction) in the form of drop zones that identify the possible placement locations where the icon can be dropped. These drop zones are displayed based on the node type of the node being added to the workflow, the node types of nodes already in the workflow, and the position of such nodes relative to each other or the terminus indicators. Such drop zones determination can rely on assembly rules, whereby the node type and the process identifier are used in a look up of the assembly rules. Drop zones appear overlaid on top of applicable flow control indicators and to either side of existing node icons where a branch in the workflow would be allowed. These drop zones give a clear visual indicator of where the node's icon can be placed based on otherwise obscure or complex assembly rules. Flow control indicators where the node cannot be placed do not display drop zones and do not allow icon-dropping into that location or show node previews at that location. As a node's icon gets close to a drop zone, the workflow can be re-arranged in order to present a preview of how this icon will appear once it is in the drop zone. This preview can include a partially transparent node indicator. In order to make room for this node indicator, the icons and other visual elements downstream of the node indicator on the current flow branch can be shifted downwards. Increasingly complex workflows may necessitate the shifting of more visual elements along with entire branches in order to make room for the preview. This mechanism can also give the user a preview of how the entire workflow will need to be re-arranged in order to accommodate a new node at the target location. The user can use this visual data to help inform their node placement decisions. As illustrated in FIG. 6, the user selects an icon 610 representing a node and performs a drag-and-drop interaction 620 thereon to move the icon 610 from the menu area to the workflow assembly area. Given the node type and the existing workflow model, the assembly rules identify possible placement locations. These placement locations are shown as drop zones using visual indicators 630 (illustrated as a plus sign in a circle). Upon approaching one of the visual indicators (e.g., the distance between the visual indicator and the icon 610 is less than a threshold number of pixels), the visual indicator is replaced with a preview 640 of the icon 610. Upon placement at the drop zone, the workflow is re-arranged as needed and the placed icon 650 is shown as being connected in the workflow.”; Column 17 lines 32-60, “The view model 1242 may include multiple logical layers, such as a UI layer and an operation layer. In the UI layer, a number of workflow node view types are implemented, each of which wraps a workflow node object and exposes APIs and attributes used for UI rendering and operations. The view model 1242 can include a list of node view objects that correspond to different backend steps processing data streams. Except for the node attributes inherited from the node objects of the workflow model 1244, each node view object maintains a parents list and children list that contains the pointers of their parent node objects and child node objects, thereby establishing the relationships between nodes and their execution order. This doubly-connected graph structure can help the workflow assembly application 1210 to quickly locate related nodes without traversing the entire graph (or iterate all node IDs) and thus speed up the workflow operations. The operation layer is built on top of the UI layer, where a number of basic operations are implemented for manipulating a workflow view model instance, such as traverse, find, insert, remove, update, etc. This layer wraps the logics to handle the UI operations and only exposes APIs to the higher layer, which helps to reduce complexity. The UI layer is stored in the state store in the workflow assembly application 1210 and is considered as the single source of truth for rendering the workflow UI. For example, if the user adds a new node to the workflow, the workflow assembly application 1210 updates the UI layer through the operation layer in order to show the new node in the workflow assembly window.”)
the workflow also instructs to determine a destination worklink from the plurality of candidate worklinks based on a type of compositor node (Luvaas: Column 7 line 53 – Column 8 line 13, “The workflow platform 221 can store multiple workflow models 222, some of which may be received from the user device 210, and others may be received from other user devices and available to the user device 210. The workflow platform 221 can also maintain assembly rules 224, a subset or the entirety of which can be sent to the workflow assembly application 212 to support the workflow creating. Further, the workflow platform 221 can maintain a library 226 of executable codes, of which can correspond to a node type. Executable code can be application program code or code of an API for an application that may reside on a remote system. The executable codes can be predefined by a service provider of the workflow platform 221 or collected over time from one or more users. The workflow platform 221 can also include an execution engine 228 for runtime executions of the workflow models 222. For instance, the workflow models 222 include a copy of the workflow model 218. The execution engine 228 parses this copy, determines the executable codes and their execution sequence and parameters, and uses the library 226 to then execute each executable code according to the execution sequence and the parameters of that executable code. Data generated by the execution of the executable code can be stored in the data store 240 and, depending on the execution sequence, can be input to the next executable code. The final data output can be stored in the data destination 250.”; Column 11 lines 6-54, “Visual guidance is shown to the user while a node's icon is added from the menu area to the workspace assembly area (e.g., via a drag-and-drop interaction) in the form of drop zones that identify the possible placement locations where the icon can be dropped. These drop zones are displayed based on the node type of the node being added to the workflow, the node types of nodes already in the workflow, and the position of such nodes relative to each other or the terminus indicators. Such drop zones determination can rely on assembly rules, whereby the node type and the process identifier are used in a look up of the assembly rules. Drop zones appear overlaid on top of applicable flow control indicators and to either side of existing node icons where a branch in the workflow would be allowed. These drop zones give a clear visual indicator of where the node's icon can be placed based on otherwise obscure or complex assembly rules. Flow control indicators where the node cannot be placed do not display drop zones and do not allow icon-dropping into that location or show node previews at that location. As a node's icon gets close to a drop zone, the workflow can be re-arranged in order to present a preview of how this icon will appear once it is in the drop zone. This preview can include a partially transparent node indicator. In order to make room for this node indicator, the icons and other visual elements downstream of the node indicator on the current flow branch can be shifted downwards. Increasingly complex workflows may necessitate the shifting of more visual elements along with entire branches in order to make room for the preview. This mechanism can also give the user a preview of how the entire workflow will need to be re-arranged in order to accommodate a new node at the target location. The user can use this visual data to help inform their node placement decisions. As illustrated in FIG. 6, the user selects an icon 610 representing a node and performs a drag-and-drop interaction 620 thereon to move the icon 610 from the menu area to the workflow assembly area. Given the node type and the existing workflow model, the assembly rules identify possible placement locations. These placement locations are shown as drop zones using visual indicators 630 (illustrated as a plus sign in a circle). Upon approaching one of the visual indicators (e.g., the distance between the visual indicator and the icon 610 is less than a threshold number of pixels), the visual indicator is replaced with a preview 640 of the icon 610. Upon placement at the drop zone, the workflow is re-arranged as needed and the placed icon 650 is shown as being connected in the workflow.”; Column 17 lines 32-60, “The view model 1242 may include multiple logical layers, such as a UI layer and an operation layer. In the UI layer, a number of workflow node view types are implemented, each of which wraps a workflow node object and exposes APIs and attributes used for UI rendering and operations. The view model 1242 can include a list of node view objects that correspond to different backend steps processing data streams. Except for the node attributes inherited from the node objects of the workflow model 1244, each node view object maintains a parents list and children list that contains the pointers of their parent node objects and child node objects, thereby establishing the relationships between nodes and their execution order. This doubly-connected graph structure can help the workflow assembly application 1210 to quickly locate related nodes without traversing the entire graph (or iterate all node IDs) and thus speed up the workflow operations. The operation layer is built on top of the UI layer, where a number of basic operations are implemented for manipulating a workflow view model instance, such as traverse, find, insert, remove, update, etc. This layer wraps the logics to handle the UI operations and only exposes APIs to the higher layer, which helps to reduce complexity. The UI layer is stored in the state store in the workflow assembly application 1210 and is considered as the single source of truth for rendering the workflow UI. For example, if the user adds a new node to the workflow, the workflow assembly application 1210 updates the UI layer through the operation layer in order to show the new node in the workflow assembly window.”)
Geipel discloses a method for creating behavior trees for the controlling of a machine. Luvaas discloses an interface for building, connecting and running nodes for a workflow. By the effective filing date of Applicant’s claimed invention it would have been obvious to one of ordinary skill in the art to combine the methods of Geipel with the teachings of Luvaas in order to improve the ease of access, and reduce inaccuracies in workflow assembly as disclosed by Luvaas (Luvaas: Column 3 lines 47-63, “Because the manual input can be avoided, the accuracy of the workflow can be improved, whereby user-induced errors may be eliminated. Further, the workflow assembly application provides a user-intuitive and guided tool to develop a properly executable workflow. The user need not be a programmer and need not have to create new program applications. Various different types of workflows can be developed, stored, modified over time, and made available to or shared between multiple users, thereby providing a scalable workflow platform.”)
Claim(s) 5 –
Geipel in view of Luvaas disclose the limitations of claim 1
Geipel further discloses the following:
the first worklink comprises a second decorator node comprising a second worklink and a second decorative layer adapted to decorating the second worklink , (Geipel: Paragraph 8, "According to a first aspect, a computer-implemented method for automatically generating a behavior tree program for controlling a machine is proposed, the method comprising the steps of transmitting a sequence of machine commands input by a user from a user interface to a controller, receiving supervision data in the user interface from the controller while the machine commands are executed in the controller controlling the machine, observing and copying the machine commands and supervision data transmitted between the controller and the user interface, storing the machine commands and the supervision data in a logging unit, generating a behavior tree program derived from the stored machine commands and the supervision data by statistical inference, and sending the generated behavior tree program to the controller unit to control the machine."; Paragraph 28, "The generated behavior tree program can be provided directly from the inferring unit to the controller or the generated behavior tree program can be transferred from the inferring unit to the user interface which forwards it from the user interface to the controller when an acknowledgement of the user is received. The direct provision allows a fast implementation of the behavior tree. The indirect provision via user interface allows the user to approve, correct or prohibit the implementation, i.e., the execution of the automatically generated behavior tree in the controller.")
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Luvaas teaches the limitation below:
the workflow instructs the second worklink to work under the decoration of the second decorative layer. (Luvaas: Column 7 lines 32-55, “The workflow model 218 includes definitions of the workflow. The workflow model 218 itself need not be new executable code that the workflow assembly application 212 generates or that a user codes by using the user device 210. Instead, the workflow model 218 can indicate the executable codes of the workflow's nodes and related configurations, where the executable codes are predefined and available from the workflow platform 221, and where the configurations are set by a user via the workflow assembly application 212. For instance, the workflow model 218 includes an identifier of the workflow, identifiers of the nodes, identifiers of the node types of the nodes, configuration parameters of the nodes (e.g., identifiers of data sources and data destinations, specific parameters of a data transformation, specific schema or file identifier for data validation, or the like), references to the executable codes of the nodes (e.g., links to where these executable codes are stored), and an execution sequence of the executable codes. In an example, the workflow model 218 can be defined as an object model, such as a JavaScript Object Notation (JSON) model, that contains multiple objects, each representing a node and including properties of the node.”; Column 16 line 54 – Column 17 line 15, “FIG. 12 illustrates an example of modules of a workflow assembly application 1210, according to certain embodiments of the present disclosure. The modules can be implemented as program codes and include a workflow UI 1220, a user interaction layer 1222, a UI rendering layer 1230, and a redux store 1240 having a view model 1242 and a workflow model 1244. The workflow UI 1220 is configured to present a workflow assembly window. The user interaction layer 1222 is configured to detect user interactions (e.g., drag-and-drop interactions) and provide related information to the UI rendering layer 1230 such that previews and visual guidance can be provided and to the view model 1242 such that the icons representing the node and the overall visualized workflow is updated (in which case the view model 1242 can update the workflow model 1244). The UI rendering layer 1230 is configured to render the workflow including, for instance, the icons representing its nodes, the connector lines, the flow control indicators, the flow control labels, the visual guidance, and the previews. The view model 1142 stores node view objects that can be used to view (e.g., visualize) the nodes of the process. The workflow model 1244 can be a JSON model that stores JSON objects, each corresponding to a node and its related properties (e.g., connection to other nodes, reference to executable code, etc.). Updates from the user interaction layer 1222 can drive updates to the view model 1242 and, in turn, to the workflow model 1244. Updates to the workflow model 1244 can be sent to a computer system that provides backend functionalities, such as the computer system 220 of FIG. 2.”; Column 18 lines 21-50, “In the user interaction layer 1222, a library is used to build a drag-and-drop (and other user interaction) experience that allows the user to insert a predefined workflow node into the existing workflow by dragging a node icon and dropping it to a workflow assembly area. The predefined node types are first loaded and then rendered as node type icons in a menu area. Each of the node types is marked as user interaction source with a unique node type ID. When the user starts to drag one of these icons from the menu area into the workflow assembly area, user interaction source APIs can tell whether and which type is being dragged by looking at the type ID associated with that icon. Each of the existing workflow nodes can be defined as a drop target with a unique node ID (or multiple targets depending on the drop location). When the user moves a node type icon over an illuminated drop zone or drops an icon into a target drop zone, the drop zone APIs can tell the position that the user wants to insert the new node by providing the target node ID. A drop preview experience is added to the UI and is activated when the workflow assembly application 1210 detects the dragged node type icon hovering above the target node or predefined drop zone. When the user drops the node type icon at a target, the view model operations implemented in the view model 1242 are used to insert a new node into the workflow graph structure at the desired position. And since the workflow assembly application 1210 knows the new node's type, the new node's attributes can be initiated accordingly. The insertion of the new node then triggers a workflow repaint in the rendering layer that updates the workflow UI 1220 to show the new node.”; Column 17 line 61 – Column 18 line 20, “In the UI rendering layer 1230, the view model 1242 is virtualized by implementing a UI rendering layer that draws a flow diagram with a node template panel using HTML, and CSS. This layer 1230 intakes the view model 1242 and converts it into a user-friendly graphic interface. The entire diagram layout information, including node position and connections, etc. are created in the view model 1242 and saved to the backend. A matrix representing a grid structure is used to map the position and connections of a node and track the updates. When a node's position is altered, it is moved it from one grid cell to another grid cell and its connections are updated accordingly. A new workflow is created with a fixed number of pre-existing nodes such as Input and Output, whose positions are pre-defined in the layout of the new workflow. A workflow layout is propagated following a set of rules, whereby, for instance, the position of a new node inserted in to the workflow is derived from the existing workflow layout using the position of the target drop zone. For example, if a new node is dropped before an existing node, the new node will take the existing node's position, and the existing node and all its downstream nodes will be shifted down by one grid cell. It is the view model instance that rules how the workflow UI is rendered, instead of the other way around. Any update in the workflow view model instance is reflected in the UI. Also, the view model instance is updated first in order to reflect accurate node positioning for the rendering.”)
Geipel discloses a method for creating behavior trees for the controlling of a machine. Luvaas discloses an interface for building, connecting and running nodes for a workflow. By the effective filing date of Applicant’s claimed invention it would have been obvious to one of ordinary skill in the art to combine the methods of Geipel with the teachings of Luvaas in order to improve the ease of access, and reduce inaccuracies in workflow assembly as disclosed by Luvaas (Luvaas: Column 3 lines 47-63, “Because the manual input can be avoided, the accuracy of the workflow can be improved, whereby user-induced errors may be eliminated. Further, the workflow assembly application provides a user-intuitive and guided tool to develop a properly executable workflow. The user need not be a programmer and need not have to create new program applications. Various different types of workflows can be developed, stored, modified over time, and made available to or shared between multiple users, thereby providing a scalable workflow platform.”)
Claim(s) 6 –
Geipel in view of Luvaas disclose the limitations of claim 1
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Luvaas teaches the limitation below:
the first worklink comprises an iterator node comprising an input end adapted to receiving an iterative item list, and an iterative worklink, and the iterative item list comprising a plurality of iterative items and an execution sequence of each iterative item; and (Luvaas: Column 7 lines 32-55, “The workflow model 218 includes definitions of the workflow. The workflow model 218 itself need not be new executable code that the workflow assembly application 212 generates or that a user codes by using the user device 210. Instead, the workflow model 218 can indicate the executable codes of the workflow's nodes and related configurations, where the executable codes are predefined and available from the workflow platform 221, and where the configurations are set by a user via the workflow assembly application 212. For instance, the workflow model 218 includes an identifier of the workflow, identifiers of the nodes, identifiers of the node types of the nodes, configuration parameters of the nodes (e.g., identifiers of data sources and data destinations, specific parameters of a data transformation, specific schema or file identifier for data validation, or the like), references to the executable codes of the nodes (e.g., links to where these executable codes are stored), and an execution sequence of the executable codes. In an example, the workflow model 218 can be defined as an object model, such as a JavaScript Object Notation (JSON) model, that contains multiple objects, each representing a node and including properties of the node.”; Column 16 line 54 – Column 17 line 15, “FIG. 12 illustrates an example of modules of a workflow assembly application 1210, according to certain embodiments of the present disclosure. The modules can be implemented as program codes and include a workflow UI 1220, a user interaction layer 1222, a UI rendering layer 1230, and a redux store 1240 having a view model 1242 and a workflow model 1244. The workflow UI 1220 is configured to present a workflow assembly window. The user interaction layer 1222 is configured to detect user interactions (e.g., drag-and-drop interactions) and provide related information to the UI rendering layer 1230 such that previews and visual guidance can be provided and to the view model 1242 such that the icons representing the node and the overall visualized workflow is updated (in which case the view model 1242 can update the workflow model 1244). The UI rendering layer 1230 is configured to render the workflow including, for instance, the icons representing its nodes, the connector lines, the flow control indicators, the flow control labels, the visual guidance, and the previews. The view model 1142 stores node view objects that can be used to view (e.g., visualize) the nodes of the process. The workflow model 1244 can be a JSON model that stores JSON objects, each corresponding to a node and its related properties (e.g., connection to other nodes, reference to executable code, etc.). Updates from the user interaction layer 1222 can drive updates to the view model 1242 and, in turn, to the workflow model 1244. Updates to the workflow model 1244 can be sent to a computer system that provides backend functionalities, such as the computer system 220 of FIG. 2.”; Column 18 lines 21-50, “In the user interaction layer 1222, a library is used to build a drag-and-drop (and other user interaction) experience that allows the user to insert a predefined workflow node into the existing workflow by dragging a node icon and dropping it to a workflow assembly area. The predefined node types are first loaded and then rendered as node type icons in a menu area. Each of the node types is marked as user interaction source with a unique node type ID. When the user starts to drag one of these icons from the menu area into the workflow assembly area, user interaction source APIs can tell whether and which type is being dragged by looking at the type ID associated with that icon. Each of the existing workflow nodes can be defined as a drop target with a unique node ID (or multiple targets depending on the drop location). When the user moves a node type icon over an illuminated drop zone or drops an icon into a target drop zone, the drop zone APIs can tell the position that the user wants to insert the new node by providing the target node ID. A drop preview experience is added to the UI and is activated when the workflow assembly application 1210 detects the dragged node type icon hovering above the target node or predefined drop zone. When the user drops the node type icon at a target, the view model operations implemented in the view model 1242 are used to insert a new node into the workflow graph structure at the desired position. And since the workflow assembly application 1210 knows the new node's type, the new node's attributes can be initiated accordingly. The insertion of the new node then triggers a workflow repaint in the rendering layer that updates the workflow UI 1220 to show the new node.”; Column 17 line 61 – Column 18 line 20, “In the UI rendering layer 1230, the view model 1242 is virtualized by implementing a UI rendering layer that draws a flow diagram with a node template panel using HTML, and CSS. This layer 1230 intakes the view model 1242 and converts it into a user-friendly graphic interface. The entire diagram layout information, including node position and connections, etc. are created in the view model 1242 and saved to the backend. A matrix representing a grid structure is used to map the position and connections of a node and track the updates. When a node's position is altered, it is moved it from one grid cell to another grid cell and its connections are updated accordingly. A new workflow is created with a fixed number of pre-existing nodes such as Input and Output, whose positions are pre-defined in the layout of the new workflow. A workflow layout is propagated following a set of rules, whereby, for instance, the position of a new node inserted in to the workflow is derived from the existing workflow layout using the position of the target drop zone. For example, if a new node is dropped before an existing node, the new node will take the existing node's position, and the existing node and all its downstream nodes will be shifted down by one grid cell. It is the view model instance that rules how the workflow UI is rendered, instead of the other way around. Any update in the workflow view model instance is reflected in the UI. Also, the view model instance is updated first in order to reflect accurate node positioning for the rendering.”)
where the workflow also instructs each iterative item to execute the iterative worklink based on the respective execution sequence in the iterative item list during an execution process of the first worklink (Luvaas: Column 7 lines 32-55, “The workflow model 218 includes definitions of the workflow. The workflow model 218 itself need not be new executable code that the workflow assembly application 212 generates or that a user codes by using the user device 210. Instead, the workflow model 218 can indicate the executable codes of the workflow's nodes and related configurations, where the executable codes are predefined and available from the workflow platform 221, and where the configurations are set by a user via the workflow assembly application 212. For instance, the workflow model 218 includes an identifier of the workflow, identifiers of the nodes, identifiers of the node types of the nodes, configuration parameters of the nodes (e.g., identifiers of data sources and data destinations, specific parameters of a data transformation, specific schema or file identifier for data validation, or the like), references to the executable codes of the nodes (e.g., links to where these executable codes are stored), and an execution sequence of the executable codes. In an example, the workflow model 218 can be defined as an object model, such as a JavaScript Object Notation (JSON) model, that contains multiple objects, each representing a node and including properties of the node.”; Column 16 line 54 – Column 17 line 15, “FIG. 12 illustrates an example of modules of a workflow assembly application 1210, according to certain embodiments of the present disclosure. The modules can be implemented as program codes and include a workflow UI 1220, a user interaction layer 1222, a UI rendering layer 1230, and a redux store 1240 having a view model 1242 and a workflow model 1244. The workflow UI 1220 is configured to present a workflow assembly window. The user interaction layer 1222 is configured to detect user interactions (e.g., drag-and-drop interactions) and provide related information to the UI rendering layer 1230 such that previews and visual guidance can be provided and to the view model 1242 such that the icons representing the node and the overall visualized workflow is updated (in which case the view model 1242 can update the workflow model 1244). The UI rendering layer 1230 is configured to render the workflow including, for instance, the icons representing its nodes, the connector lines, the flow control indicators, the flow control labels, the visual guidance, and the previews. The view model 1142 stores node view objects that can be used to view (e.g., visualize) the nodes of the process. The workflow model 1244 can be a JSON model that stores JSON objects, each corresponding to a node and its related properties (e.g., connection to other nodes, reference to executable code, etc.). Updates from the user interaction layer 1222 can drive updates to the view model 1242 and, in turn, to the workflow model 1244. Updates to the workflow model 1244 can be sent to a computer system that provides backend functionalities, such as the computer system 220 of FIG. 2.”; Column 18 lines 21-50, “In the user interaction layer 1222, a library is used to build a drag-and-drop (and other user interaction) experience that allows the user to insert a predefined workflow node into the existing workflow by dragging a node icon and dropping it to a workflow assembly area. The predefined node types are first loaded and then rendered as node type icons in a menu area. Each of the node types is marked as user interaction source with a unique node type ID. When the user starts to drag one of these icons from the menu area into the workflow assembly area, user interaction source APIs can tell whether and which type is being dragged by looking at the type ID associated with that icon. Each of the existing workflow nodes can be defined as a drop target with a unique node ID (or multiple targets depending on the drop location). When the user moves a node type icon over an illuminated drop zone or drops an icon into a target drop zone, the drop zone APIs can tell the position that the user wants to insert the new node by providing the target node ID. A drop preview experience is added to the UI and is activated when the workflow assembly application 1210 detects the dragged node type icon hovering above the target node or predefined drop zone. When the user drops the node type icon at a target, the view model operations implemented in the view model 1242 are used to insert a new node into the workflow graph structure at the desired position. And since the workflow assembly application 1210 knows the new node's type, the new node's attributes can be initiated accordingly. The insertion of the new node then triggers a workflow repaint in the rendering layer that updates the workflow UI 1220 to show the new node.”; Column 17 line 61 – Column 18 line 20, “In the UI rendering layer 1230, the view model 1242 is virtualized by implementing a UI rendering layer that draws a flow diagram with a node template panel using HTML, and CSS. This layer 1230 intakes the view model 1242 and converts it into a user-friendly graphic interface. The entire diagram layout information, including node position and connections, etc. are created in the view model 1242 and saved to the backend. A matrix representing a grid structure is used to map the position and connections of a node and track the updates. When a node's position is altered, it is moved it from one grid cell to another grid cell and its connections are updated accordingly. A new workflow is created with a fixed number of pre-existing nodes such as Input and Output, whose positions are pre-defined in the layout of the new workflow. A workflow layout is propagated following a set of rules, whereby, for instance, the position of a new node inserted in to the workflow is derived from the existing workflow layout using the position of the target drop zone. For example, if a new node is dropped before an existing node, the new node will take the existing node's position, and the existing node and all its downstream nodes will be shifted down by one grid cell. It is the view model instance that rules how the workflow UI is rendered, instead of the other way around. Any update in the workflow view model instance is reflected in the UI. Also, the view model instance is updated first in order to reflect accurate node positioning for the rendering.”)
Geipel discloses a method for creating behavior trees for the controlling of a machine. Luvaas discloses an interface for building, connecting and running nodes for a workflow. By the effective filing date of Applicant’s claimed invention it would have been obvious to one of ordinary skill in the art to combine the methods of Geipel with the teachings of Luvaas in order to improve the ease of access, and reduce inaccuracies in workflow assembly as disclosed by Luvaas (Luvaas: Column 3 lines 47-63, “Because the manual input can be avoided, the accuracy of the workflow can be improved, whereby user-induced errors may be eliminated. Further, the workflow assembly application provides a user-intuitive and guided tool to develop a properly executable workflow. The user need not be a programmer and need not have to create new program applications. Various different types of workflows can be developed, stored, modified over time, and made available to or shared between multiple users, thereby providing a scalable workflow platform.”)
Claim(s) 7 and 13 –
Geipel in view of Luvaas disclose the limitations of claims 1 and 10
Geipel further discloses the following:
further comprising deploying the workflow onto a runtime containing workcell, such that the workcell performs operations according to the workflow (Geipel: Paragraph 53, "Candidates for a "Wait" decorator can be identified by observation if the value of a specific variable changes at the same time as a new task starts. The example in Figure SC shows a value change of a variable A correlating with a transition between tasks T54 and T55."; Paragraph 54, "Figure 6 shows a behavior tree program 50 generated automatically by the assistance system 20. The behavior tree 50 controlling the system to move to a light barrier, see 51. The behavior tree component 52 represents a "sequence" composite. Behavior tree component 53 represents "wait for light-barrier = false", behavior tree component 54 represents "<> stop", component 55 represents "wait for sensor_2 = true and component 56 represents "<>go right. The generated program learnt that: sensor_ 2 triggers the start of the conveyor belt (wait for value change of sensor 2) light_barrier stops the conveyor belt (wait for value change of light_barrier)."; Paragraph 55, "The inference unit 27 can comprise a semantic model, which provides domain knowledge. As an example, it provides the information "task can only be executed with a certain security level, picking of a robot arm is only successful in 90% of the cases and consequently "fall back" is necessary. The semantic model can provide information about tasks that can fail, and which fallback solutions are possible. The inference unit 27 can make recommendations to the user 22 based on assumptions. The user 22 can verify or correct the assumptions. Whenever the inference unit 27 is unsure about something when creating the behavior tree program, user input can be requested, e.g., parallel tasks, fallbacks, preconditions, wait conditions, loops, if-else-statements, stop conditions. An example question to user is "We noticed that task A is typically executed after the light barrier is interrupted. Do you want to save this as a precondition?"")
wherein the workflow comprises an OT domain workflow, and the workcell comprises an OT device. (Geipel: Paragraph 53, "Candidates for a "Wait" decorator can be identified by observation if the value of a specific variable changes at the same time as a new task starts. The example in Figure SC shows a value change of a variable A correlating with a transition between tasks T54 and T55."; Paragraph 54, "Figure 6 shows a behavior tree program 50 generated automatically by the assistance system 20. The behavior tree 50 controlling the system to move to a light barrier, see 51. The behavior tree component 52 represents a "sequence" composite. Behavior tree component 53 represents "wait for light-barrier = false", behavior tree component 54 represents "<> stop", component 55 represents "wait for sensor_ 2 = true and component 56 represents "<>go right. The generated program learnt that: sensor_2 triggers the start of the conveyor belt (wait for value change of sensor 2) light_ barrier stops the conveyor belt (wait for value change of light_barrier)."; Paragraph 55, "The inference unit 27 can comprise a semantic model, which provides domain knowledge. As an example, it provides the information "task can only be executed with a certain security level, picking of a robot arm is only successful in 90% of the cases and consequently "fallback" is necessary. The semantic model can provide information about tasks that can fail, and which fallback solutions are possible. The inference unit 27 can make recommendations to the user 22 based on assumptions. The user 22 can verify or correct the assumptions. Whenever the inference unit 27 is unsure about something when creating the behavior tree program, user input can be requested, e.g., parallel tasks, fallbacks, preconditions, wait conditions, loops, if-else-statements, stop conditions. An example question to user is "We noticed that task A is typically executed after the light barrier is interrupted. Do you want to save this as a precondition?"")
Claim(s) 8 –
Geipel in view of Luvaas disclose the limitations of claims 1-2
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Luvaas teaches the limitation below:
each behavior tree node is listed on the GUI in the form of icons, and the selection operation comprises selecting and dragging the icons to be added to a canvas (Luvaas: Column 5 lines 35-50, “The workflow assembly area 130 can be a canvas or a workspace area where icons 122 selected from the menu area 120 can be placed. This placement can be via different types of input means. For example, drag-and-drop operations can be supported. As further illustrated in the next figures, when an icon is selected, and depending on the corresponding node type and the current workflow model (e.g., the nodes already added to the workflow mode, their node types, and the dependencies between them), visual indicators can be presented in the workflow assembly area 130 to indicate to the user possible placement locations of the icon. Upon placing the icon at a particular placement location, the workflow model is updated to identify the added node and its node type, reference the corresponding executable code, and the dependency to the already added nodes (e.g., an update to the execution sequence).”; Column 11 lines 7-26, “Visual guidance is shown to the user while a node's icon is added from the menu area to the workspace assembly area (e.g., via a drag-and-drop interaction) in the form of drop zones that identify the possible placement locations where the icon can be dropped. These drop zones are displayed based on the node type of the node being added to the workflow, the node types of nodes already in the workflow, and the position of such nodes relative to each other or the terminus indicators. Such drop zones determination can rely on assembly rules, whereby the node type and the process identifier are used in a look up of the assembly rules. Drop zones appear overlaid on top of applicable flow control indicators and to either side of existing node icons where a branch in the workflow would be allowed. These drop zones give a clear visual indicator of where the node's icon can be placed based on otherwise obscure or complex assembly rules. Flow control indicators where the node cannot be placed do not display drop zones and do not allow icon-dropping into that location or show node previews at that location.”)
Geipel discloses a method for creating behavior trees for the controlling of a machine. Luvaas discloses an interface for building, connecting and running nodes for a workflow. By the effective filing date of Applicant’s claimed invention it would have been obvious to one of ordinary skill in the art to combine the methods of Geipel with the teachings of Luvaas in order to improve the ease of access, and reduce inaccuracies in workflow assembly as disclosed by Luvaas (Luvaas: Column 3 lines 47-63, “Because the manual input can be avoided, the accuracy of the workflow can be improved, whereby user-induced errors may be eliminated. Further, the workflow assembly application provides a user-intuitive and guided tool to develop a properly executable workflow. The user need not be a programmer and need not have to create new program applications. Various different types of workflows can be developed, stored, modified over time, and made available to or shared between multiple users, thereby providing a scalable workflow platform.”)
Claim(s) 9 –
Geipel in view of Luvaas disclose the limitations of claims 1-2, and 8
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Luvaas teaches the limitation below:
the first decorator node comprises a first display area and a second display area, the first display area adapted to display a type of the first decorator node and the second display area adapted to display the first decorator expression, and the first decorator node comprises a tag arranged on the first decorator node, the tag being an identifier of the first decorator node. (Luvaas: Column 11 line 62 – Column 12 line 16, “In an example, the visualization of the workflow is oriented from top to bottom such that nodes (as visualized with corresponding icons) are aligned with each other in a columnar grid layout 730. This vertical stacking and alignment of nodes reduces visual noise by disallowing unaligned elements. This arrangement further reduces visual noise by allowing node connector lines between sequential nodes on the Y axis to display as straight up-and-down lines with no curves, angles, or overlapping/crossing lines. This arrangement also allows branches and merges in the workflow to be represented with no more than one ninety degree angle in any connector line between nodes. The workflow assembly application can automatically re-arrange terminus indicators, icons, connector lines, flow control indicators, and flow control labels to accommodate the layout constraints 710. A preview of a desired re-arrangement can be shown during the preview phase of the drag-and-drop process. The workflow assembly application can further attempt to optimize layout such that to avoid the crossing of connector lines between unrelated flow branches wherever possible. Doing so allows the user to easily follow the connector lines between icons regardless of the physical distance between them.”; Column 16 line 54 – Column 17 line 16, “FIG. 12 illustrates an example of modules of a workflow assembly application 1210, according to certain embodiments of the present disclosure. The modules can be implemented as program codes and include a workflow UI 1220, a user interaction layer 1222, a UI rendering layer 1230, and a redux store 1240 having a view model 1242 and a workflow model 1244. The workflow UI 1220 is configured to present a workflow assembly window. The user interaction layer 1222 is configured to detect user interactions (e.g., drag-and-drop interactions) and provide related information to the UI rendering layer 1230 such that previews and visual guidance can be provided and to the view model 1242 such that the icons representing the node and the overall visualized workflow is updated (in which case the view model 1242 can update the workflow model 1244). The UI rendering layer 1230 is configured to render the workflow including, for instance, the icons representing its nodes, the connector lines, the flow control indicators, the flow control labels, the visual guidance, and the previews. The view model 1142 stores node view objects that can be used to view (e.g., visualize) the nodes of the process. The workflow model 1244 can be a JSON model that stores JSON objects, each corresponding to a node and its related properties (e.g., connection to other nodes, reference to executable code, etc.). Updates from the user interaction layer 1222 can drive updates to the view model 1242 and, in turn, to the workflow model 1244. Updates to the workflow model 1244 can be sent to a computer system that provides backend functionalities, such as the computer system 220 of FIG. 2.”)
Geipel discloses a method for creating behavior trees for the controlling of a machine. Luvaas discloses an interface for building, connecting and running nodes for a workflow. By the effective filing date of Applicant’s claimed invention it would have been obvious to one of ordinary skill in the art to combine the methods of Geipel with the teachings of Luvaas in order to improve the ease of access, and reduce inaccuracies in workflow assembly as disclosed by Luvaas (Luvaas: Column 3 lines 47-63, “Because the manual input can be avoided, the accuracy of the workflow can be improved, whereby user-induced errors may be eliminated. Further, the workflow assembly application provides a user-intuitive and guided tool to develop a properly executable workflow. The user need not be a programmer and need not have to create new program applications. Various different types of workflows can be developed, stored, modified over time, and made available to or shared between multiple users, thereby providing a scalable workflow platform.”)
Claim(s) 12 –
Geipel in view of Luvaas disclose the limitations of claim 10
Geipel further discloses the following:
wherein the first worklink comprises a function block node configured to implement a service operation in the workflow or the first worklink comprises a compositor node comprising a start block adapted to starting the executing of the compositor node, an end block adapted to ending executing the compositor node, and a plurality of candidate worklinks arranged between the start block and the end block, wherein the workflow also instructs to determine a destination worklink from the plurality of candidate worklinks based on the type of compositor node, or the first worklink comprises a second decorator node comprising a second worklink and a second decorative layer adapted to decorating the second worklink wherein the workflow instructs the second worklink to work under the decoration of the second decorative layer or the first worklink comprises an iterator node comprising an input end adapted to receiving an iterative item list, and an iterative worklink, and the iterative item list comprising a plurality of iterative items and an execution sequence of each iterative item (Geipel: Paragraph 36, "It is noted that in the following detailed description of embodiments the accompanying drawings are only schematic and that the illustrated elements are not necessarily shown to scale. Rather, the drawings are intended to illustrate functions and cooperation of components. Here, it is to be understood that any connection or coupling of functional blocks, devices, components, or other physical or functional elements could also be implemented by an indirect connection or coupling, e.g., via one or more intermediate elements. A connection or coupling of elements or components can for example be implemented by a wire-based, a wireless connection, and/or a combination of a wire-based and a wireless connection. Functional blocks can be implemented by dedicated hardware, by firmware and/or software installed on programmable hardware, and/or by a combination of dedicated hardware and firmware or software."; Paragraph 57, "In a first step S 1 a sequence of machine commands input by the user 22 at the user interface 21 are transmitted to the controller unit 23. While the machine commands are executed in the controller unit 23 supervision data are received, see step S2, in the user interface 21 from the controller unit 23. The machine commands and supervision data are transferred on a communication connection between the user interface 21 and the controller unit 23, e.g., via a protocol messages according to OPV UA, Profinet and the like. A Machine command activates a machine behavior, a functionality, or an operational state in the machine 24. Supervision data comprises status information and/or sensor data of the machine when controlled by the controller executing the machine commands. The machine commands and supervision data are observed and copied at the communication connection between the controller 23 and the user interface 21, see step S3. Subsequently in step S4, the machine commands and the supervision data are stored in the logging unit 26.")
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ocke (US 7,249,735 B2) discloses a method for automatically identifying an existing workflow to manufacture a given product
Harm (US 2012/0131645 A1) discloses a method for a user scriptable server initiated user interface
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Philip N Warner whose telephone number is (571)270-7407. The examiner can normally be reached Monday-Friday 7am-4:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jerry O’Connor can be reached at 571-272-6787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Philip N Warner/Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624
Prosecution Insights