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 FINAL Office Action is in response to Applicant’s communication filed 02/06/2026 regarding Application 18/832,492.
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 have been fully considered but are not deemed persuasive.
Applicant argues that the previously applied art of Geipel fails to disclose a decorator node as recited in Applicant’s claim and elaborated on in Applicant’s specification.
Examiner does not find this argument persuasive as the applied art of Geipel in Paragraph 59 discloses “…suggestions can also be ignored and/or different machine commands or behavior task elements…composites or decorators can be entered…”. Additionally, Geipel as a reference elaborates in the use of decorator nodes in 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.”) and in subsequent paragraphs includes descriptors of decorator actions such as “wait” and “guard” which are specified as options in Applicant’s specification and therefore understood to be encompassed by the claims as currently written. Further citations and elaboration is given in 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 Al) in view of Rao (US 2012/0331150 Al)
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 generating, (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 Rao discloses the following:
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 (Rao: Paragraph 5, "Provided are techniques for defining a set of normalized resources corresponding to a plurality of infrastructure resources; defining a set of normalized resource states corresponding to the plurality of infrastructure resources; defining a set of normalized, operations corresponding to the plurality of infrastructure resources, wherein inputs and outputs corresponding to each normalized operation of the set of normalized operations has a defined type of a plurality of types; generating a plurality of operational sequences, each operation sequence generated by composing a plurality of normalized operations of the set of normalized operations with corresponding normalized, resources of the set of normalized resources such that the output of each or the set of normalized operations becomes the input of another of the set of normalized operations, wherein a defined type corresponding to each particular input matches a defined type corresponding to the corresponding output; generating a workflow plan by composing the plurality of operational sequences in conformity with well-defined operational semantics; and storing, in a computer-readable storage medium, the workflow plan for execution on a processor."; Paragraph 124, "FIG. 14 is a flow chart of a Prepare Operational Workflow process 400 that may employ aspects the claimed subject matter. Process 400 illustrates the generation of an operation workflow (see 250; FIGS. 10 and 12) using a workflow templates (see 350, FIG. 13). In this example, process 400 is implemented by an administrator on management server 102 (FIG. 1) employing a user interface (not shown) of RIOS 116 (FIGS. 1 and 2)."; Paragraph 126, "During a "Build Operation (Op.) Node List" block 412, any operations specified in a workflow section (see 362, FIG. 13) is processed to generate a corresponding operation node or "leaf" These leaves are organized, into as an operation tree. During processing associated with a "More Templates" 414, a determination is made as to whether or not more workflow templates (see 266 and 268, FIG. 12) need to be processed, if so, control returns to Get Next Template block 404, the next referenced template is retrieved from CRSM 112 and processing continues as described above. Briefly, the iterations through blocks 404, 406, 408, 410 412 and 414 may be characterized as "walking" through the root template to process all the templates referenced in the root template and subsequent templates.")
Geipel discloses a method for creating behavior trees for the controlling of a machine. Rao discloses a method for creating workflows and workflow templates from operational data. At the time of Applicant's filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Geipel with the teachings of Rao in order to normalize operations between operations in order to better define workflows in relation to each other as disclosed by Rao (Rao: Paragraph 5, "Provided are techniques for defining a set of normalized resources corresponding to a plurality of infrastructure resources; defining a set of normalized resource states corresponding to the plurality of infrastructure resources; defining a set of normalized, operations corresponding to the plurality of infrastructure resources, wherein inputs and outputs corresponding to each normalized operation of the set of normalized operations has a defined type of a plurality of types; generating a plurality of operational sequences, each operation sequence generated by composing a plurality of normalized operations of the set of normalized operations with corresponding normalized, resources of the set of normalized resources such that the output of each or the set of normalized operations becomes the input of another of the set of normalized operations, wherein a defined type corresponding to each particular input matches a defined type corresponding to the corresponding output; generating a workflow plan by composing the plurality of operational sequences in conformity with welldefined operational semantics; and storing, in a computer-readable storage medium, the workflow plan for execution on a processor.")
Claim(s) 2 and 11 –
Geipel in view of Rao 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 Rao 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 Rao disclose the limitations of claim 1
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Rao 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, (Rao: Paragraph 119, "Scheduling semantics 378 takes the form "Scheduling=<format string>" and may be employed to suggest a time to wait before a corresponding workflow starts to be executed as a schedulable job, a time to wait between any two partial orders before declaring a problem and so on."; Paragraph 127, "One a determination has been made during processing associated with block 414 that all templates have been processed, control proceeds to a "Create Workflow Tree" block 416, during which the work flows and corresponding operation trees are organized into an ordered workflow tree, which is then stored in CRSM 112 for execution. Finally, control proceeds to an "End Build Workflow" block 419 during which process 400 is complete."; Paragraph 128, "FIG. 15 is a flow chart of an Execute Operation Workflow process 450 that may employ aspects the claimed subject matter. In this example, process 450 is stored as logic in CRSM 112 (FIG. 1) as part of RIOS 116 (FIGS. 1 and 2). (see 142-149, FIG, 2). Process 450 starts in a "Begin Execute Workflow" block 452 and proceeds immediately to a "Retrieve Workflow free" block 454. During processing associated with block 454, a workflow tree, which in the following example will be operational workflow 250 (FIGS. 10 and 12), is retrieved form management DB 145. As explained above in conjunction with process 400 (FIG. 14), a workflow tree is typically prepared in advance by an administrator and saved in a CRSM for execution one or more times."; Paragraph 130, "During processing associated with a "More Ops.?" block 468, a determination is made as to whether there are more operations corresponding to the leaf that should be executed. If so, control returns to block 460, the template for the next operation is retrieved and processing continues as described above. If not, control proceeds to a "More Leaves? block 470. During processing associated with block 470, a determination is made as to whether there are more leaves corresponding to workflow tree retrieved during processing associated with block 454. If so, control returns to block 456, the template for the next leaf is retrieved and processing continues as described above.")
the workflow also instructs to determine a destination worklink from the plurality of candidate worklinks base don a type of compositor node (Rao: Paragraph 119, "Scheduling semantics 378 takes the form "Scheduling=<format string>" and may be employed to suggest a time to wait before a corresponding workflow starts to be executed as a schedulable job, a time to wait between any two partial orders before declaring a problem and so on."; Paragraph 127, "One a determination has been made during processing associated with block 414 that all templates have been processed, control proceeds to a "Create Workflow Tree" block 416, during which the work flows and corresponding operation trees are organized into an ordered workflow tree, which is then stored in CRSM 112 for execution. Finally, control proceeds to an "End Build Workflow" block 419 during which process 400 is complete."; Paragraph 128, "FIG. 15 is a flow chart of an Execute Operation Workflow process 450 that may employ aspects the claimed subject matter. In this example, process 450 is stored as logic in CRSM 112 (FIG. 1) as part of RIOS 116 (FIGS. 1 and 2). (see 142-149, FIG, 2). Process 450 starts in a "Begin Execute Workflow" block 452 and proceeds immediately to a "Retrieve Workflow free" block 454. During processing associated with block 454, a workflow tree, which in the following example will be operational workflow 250 (FIGS. 10 and 12), is retrieved form management DB 145. As explained above in conjunction with process 400 (FIG. 14), a workflow tree is typically prepared in advance by an administrator and saved in a CRSM for execution one or more times."; Paragraph 130, "During processing associated with a "More Ops.?" block 468, a determination is made as to whether there are more operations corresponding to the leaf that should be executed. If so, control returns to block 460, the template for the next operation is retrieved and processing continues as described above. If not, control proceeds to a "More Leaves? block 470. During processing associated with block 470, a determination is made as to whether there are more leaves corresponding to workflow tree retrieved during processing associated with block 454. If so, control returns to block 456, the template for the next leaf is retrieved and processing continues as described above.")
Geipel discloses a method for creating behavior trees for the controlling of a machine. Rao discloses a method for creating workflows and workflow templates from operational data. At the time of Applicant's filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Geipel with the teachings of Rao in order to normalize operations between operations in order to better define workflows in relation to each other as disclosed by Rao (Rao: Paragraph 5, "Provided are techniques for defining a set of normalized resources corresponding to a plurality of infrastructure resources; defining a set of normalized resource states corresponding to the plurality of infrastructure resources; defining a set of normalized, operations corresponding to the plurality of infrastructure resources, wherein inputs and outputs corresponding to each normalized operation of the set of normalized operations has a defined type of a plurality of types; generating a plurality of operational sequences, each operation sequence generated by composing a plurality of normalized operations of the set of normalized operations with corresponding normalized, resources of the set of normalized resources such that the output of each or the set of normalized operations becomes the input of another of the set of normalized operations, wherein a defined type corresponding to each particular input matches a defined type corresponding to the corresponding output; generating a workflow plan by composing the plurality of operational sequences in conformity with welldefined operational semantics; and storing, in a computer-readable storage medium, the workflow plan for execution on a processor.")
Claim(s) 5 –
Geipel in view of Rao 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 Rao teaches the limitation below:
the workflow instructs the second worklink to work under the decoration of the second decorative layer. (Rao: Paragraph 119, "Scheduling semantics 378 takes the form "Scheduling=<format string>" and may be employed to suggest a time to wait before a corresponding workflow starts to be executed as a schedulable job, a time to wait between any two partial orders before declaring a problem and so on."; Paragraph 127, "One a determination has been made during processing associated with block 414 that all templates have been processed, control proceeds to a "Create Workflow Tree" block 416, during which the work flows and corresponding operation trees are organized into an ordered workflow tree, which is then stored in CRSM 112 for execution. Finally, control proceeds to an "End Build Workflow" block 419 during which process 400 is complete."; Paragraph 128, "FIG. 15 is a flow chart of an Execute Operation Workflow process 450 that may employ aspects the claimed subject matter. In this example, process 450 is stored as logic in CRSM 112 (FIG. 1) as part of RIOS 116 (FIGS. 1 and 2). (see 142-149, FIG, 2). Process 450 starts in a "Begin Execute Workflow" block 452 and proceeds immediately to a "Retrieve Workflow free" block 454. During processing associated with block 454, a workflow tree, which in the following example will be operational workflow 250 (FIGS. 10 and 12), is retrieved form management DB 145. As explained above in conjunction with process 400 (FIG. 14), a workflow tree is typically prepared in advance by an administrator and saved in a CRSM for execution one or more times."; Paragraph 130, "During processing associated with a "More Ops.?" block 468, a determination is made as to whether there are more operations corresponding to the leaf that should be executed. If so, control returns to block 460, the template for the next operation is retrieved and processing continues as described above. If not, control proceeds to a "More Leaves? block 470. During processing associated with block 470, a determination is made as to whether there are more leaves corresponding to workflow tree retrieved during processing associated with block 454. If so, control returns to block 456, the template for the next leaf is retrieved and processing continues as described above.")
Geipel discloses a method for creating behavior trees for the controlling of a machine. Rao discloses a method for creating workflows and workflow templates from operational data. At the time of Applicant's filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Geipel with the teachings of Rao in order to normalize operations between operations in order to better define workflows in relation to each other as disclosed by Rao (Rao: Paragraph 5, "Provided are techniques for defining a set of normalized resources corresponding to a plurality of infrastructure resources; defining a set of normalized resource states corresponding to the plurality of infrastructure resources; defining a set of normalized, operations corresponding to the plurality of infrastructure resources, wherein inputs and outputs corresponding to each normalized operation of the set of normalized operations has a defined type of a plurality of types; generating a plurality of operational sequences, each operation sequence generated by composing a plurality of normalized operations of the set of normalized operations with corresponding normalized, resources of the set of normalized resources such that the output of each or the set of normalized operations becomes the input of another of the set of normalized operations, wherein a defined type corresponding to each particular input matches a defined type corresponding to the corresponding output; generating a workflow plan by composing the plurality of operational sequences in conformity with welldefined operational semantics; and storing, in a computer-readable storage medium, the workflow plan for execution on a processor.")
Claim(s) 6 –
Geipel in view of Rao disclose the limitations of claim 1
Geipel does not explicitly disclose the following, however, in analogous art of workflow creation Rao 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 (Rao: Paragraph 99, "Workflow template 350 includes a format section 352, a parameter section 354, an import section 356, a constant section 358, a variable section 360 and a workflow section 362. Workflow template 350 provides a number of options to support a full software development cycle as well as customer development, test and deployment cycle. Arbitrary types of constants are not allowed and constants are based upon filters and descriptors with implementer-designated formats, which are string-based. Actual operational workflows are based upon previously defined resource types and operations. In addition, each workflow represented by a workflow template such as workflow template 3 50 goes through a PREP ARE and EXECUTE cycle. The PREP ARE cycle (see 400, FIG. 14) is used for preparing a workflow runtime plan. The EXECUTE cycle (see 450, FIG. 15) may be performed iteratively with different control options such as handing control to an end-user or as a single-shot transaction. Each of sections 354, 356, 358, 360 and 362 illustrates examples of an appropriate syntax for entries in the corresponding sections 354, 356, 358, 360 and 362,"; Paragraph 118, "WORK.FLOW _PREPARE_ONL Y, which is typically employed during development and testing, ensures that the corresponding workflow is prepared but not executed. TRANSACTION_PREP ARE_ ONLY ensures that the corresponding workflow is executed without commits with transactional prepare semantics (see 370). This scenario is equivalent to running a whole workflow as a fully-ordered tree of operations with hierarchical/recursive execution from the top covering the PREPARE phase only. Please note that the implementation need not follow recursion and could use tree data structure assisted depth-first iterative execution. FULL_ITERATVE_FLOW implies that workflow execution returns to an end-user for the end-user to inspect the execution thus far and to resume the workflow transaction. FULL ONE -SHOT- implies that the workflow is to be executed as a one-shot, transaction."; Paragraph 126, "During a "Build Operation (Op.) Node List" block 412, any operations specified in a workflow section (see 362, FIG. 13) is processed to generate a corresponding operation node or "leaf" These leaves are organized, into as an operation tree. During processing associated with a "More Templates" 414, a determination is made as to whether or not more workflow templates (see 266 and 268, FIG. 12) need to be processed, if so, control returns to Get Next Template block 404, the next referenced template is retrieved from CRSM 112 and processing continues as described above. Briefly, the iterations through blocks 404, 406, 408, 410 412 and 414 may be characterized as "walking" through the root template to process all the templates referenced in the root template and subsequent templates."; Paragraph 130, "During processing associated with a "More Ops.?" block 468, a determination is made as to whether there are more operations corresponding to the leaf that should be executed. If so, control returns to block 460, the template for the next operation is retrieved and processing continues as described above. If not, control proceeds to a "More Leaves? block 470. During processing associated with block 470, a determination is made as to whether there are more leaves corresponding to workflow tree retrieved during processing associated with block 454. If so, control returns to block 456, the template for the next leaf is retrieved and processing continues as described above.")
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 (Rao: Paragraph 99, "Workflow template 350 includes a format section 352, a parameter section 354, an import section 356, a constant section 358, a variable section 360 and a workflow section 362. Workflow template 350 provides a number of options to support a full software development cycle as well as customer development, test and deployment cycle. Arbitrary types of constants are not allowed and constants are based upon filters and descriptors with implementer-designated formats, which are string-based. Actual operational workflows are based upon previously defined resource types and operations. In addition, each workflow represented by a workflow template such as workflow template 3 50 goes through a PREP ARE and EXECUTE cycle. The PREPARE cycle (see 400, FIG. 14) is used for preparing a workflow runtime plan. The EXECUTE cycle (see 450, FIG. 15) may be performed iteratively with different control options such as handing control to an end-user or as a single-shot transaction. Each of sections 354, 356, 358, 360 and 362 illustrates examples of an appropriate syntax for entries in the corresponding sections 354, 356, 358, 360 and 362,"; Paragraph 118, "WORK.FLOW _PREP ARE_ ONLY, which is typically employed during development and testing, ensures that the corresponding workflow is prepared but not executed. TRANSACTION PREPARE -ONLY ensures that the corresponding workflow is executed without commits with transactional prepare semantics (see 370). This scenario is equivalent to running a whole workflow as a fully-ordered tree of operations with hierarchical/recursive execution from the top covering the PREPARE phase only. Please note that the implementation need not follow recursion and could use tree data structure assisted depth-first iterative execution. FULL_ITERATVE_FLOW implies that workflow execution returns to an end-user for the end-user to inspect the execution thus far and to resume the workflow transaction. FULL_ ONE_ SHOT implies that the workflow is to be executed as a one-shot, transaction."; Paragraph 126, "During a "Build Operation (Op.) Node List" block 412, any operations specified in a workflow section (see 362, FIG. 13) is processed to generate a corresponding operation node or "leaf" These leaves are organized, into as an operation tree. During processing associated with a "More Templates" 414, a determination is made as to whether or not more workflow templates (see 266 and 268, FIG. 12) need to be processed, if so, control returns to Get Next Template block 404, the next referenced template is retrieved from CRSM 112 and processing continues as described above. Briefly, the iterations through blocks 404, 406, 408, 410 412 and 414 may be characterized as "walking" through the root template to process all the templates referenced in the root template and subsequent templates."; Paragraph 130, "During processing associated with a "More Ops.?" block 468, a determination is made as to whether there are more operations corresponding to the leaf that should be executed. If so, control returns to block 460, the template for the next operation is retrieved and processing continues as described above. If not, control proceeds to a "More Leaves? block 470. During processing associated with block 470, a determination is made as to whether there are more leaves corresponding to workflow tree retrieved during processing associated with block 454. If so, control returns to block 456, the template for the next leaf is retrieved and processing continues as described above.")
Geipel discloses a method for creating behavior trees for the controlling of a machine. Rao discloses a method for creating workflows and workflow templates from operational data. At the time of Applicant's filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Geipel with the teachings of Rao in order to normalize operations between operations in order to better define workflows in relation to each other as disclosed by Rao (Rao: Paragraph 5, "Provided are techniques for defining a set of normalized resources corresponding to a plurality of infrastructure resources; defining a set of normalized resource states corresponding to the plurality of infrastructure resources; defining a set of normalized, operations corresponding to the plurality of infrastructure resources, wherein inputs and outputs corresponding to each normalized operation of the set of normalized operations has a defined type of a plurality of types; generating a plurality of operational sequences, each operation sequence generated by composing a plurality of normalized operations of the set of normalized operations with corresponding normalized, resources of the set of normalized resources such that the output of each or the set of normalized operations becomes the input of another of the set of normalized operations, wherein a defined type corresponding to each particular input matches a defined type corresponding to the corresponding output; generating a workflow plan by composing the plurality of operational sequences in conformity with well- defined operational semantics; and storing, in a computer-readable storage medium, the workflow plan for execution on a processor.")
Claim(s) 7 and 13 –
Geipel in view of Rao 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 Rao disclose the limitations of claims 1-2
Geipel further discloses the following:
the first decorator node is selected based on a selection performed by the user on the GUI comprising a node library (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 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?"")
Claim(s) 9 –
Geipel in view of Rao disclose the limitations of claims 1-2, and 8
Geipel further discloses the following:
the first decorator node comprises a first display area and a second display area, the first display are adapted to displaying a type of the first decorator node and the second display area adapted to displaying the first decorator expression (Geipel: Paragraph 30, "According to an embodiment of the invention, the user interface comprises a graphical user interface configured to display the supervision data, a suggestion or a recommendation to the user and/or input the sequence of machine commands or feedback to the suggestion and/or recommendations by the user."; Paragraph 41, "The user interface 21 is the interface between a user 22, e.g., a machine operator or an automation engineer and the controller unit 23. The user interface 21 is configured as a Graphical User interface, a display, a keyboard, a mouse, control units, and the like. The user interface 21 is configured to receive input from a user in a role as machine operator, i.e., entering machine commands during operation of the machine. During a training phase of the assistance system 20, especially of the inference unit 27, the user 22 controls the machine 24 by entering machine commands into the user interface 21. Machine commands, especially high-level machine commands, define a production step, a transportation step, a material flow, material handling, material processing, assembly steps, and so on."; 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 46, "In doing so, preconditions, fall back scenarios, as well as typical sequences of tasks can be learned and tasks, composites providing a logical interconnection of several tasks, like a sequence composite or a fallback composite. The inference unit 27 sends suggestions to the user interface 21 to assist the user 22 to automate operations.")
Claim(s) 12 –
Geipel in view of Rao 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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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