CTNF 18/834,021 CTNF 87166 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim 1 and 10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Independent claim 1 recites a workflow construction method including receiving function block node addition and connection operations performed on a graphical user interface (GUI) by a user on the basis of function block type graphs and constructing a behavior tree corresponding to one workflow in response to the function block node addition and connection operations. The claim is directed to constructing a workflow by receiving user selections/connections of graphical function blocks and generating a behavior-tree representation of the workflow. Under Step 2A, Prong One, claim 1 recites an abstract idea because the claimed method is directed to organizing and managing workflow information, including receiving user input, arranging graphical representations of operations, connecting the representations, and generating a workflow structure. This is similar to creating a flowchart, process map, or visual programming/workflow diagram, which is a method of organizing information and managing a process. Under Step 2A, Prong Two, the additional limitations do not integrate the abstract idea into a practical application. The recited GUI, function block type graphs, function block name, function block header, link input port, link output port, input data chunk, output data chunk, data input port, data output port, and function block body merely define the graphical format and information structure used to represent and connect workflow nodes. The specification describes the invention as improving the convenience and efficiency of workflow construction using reusable nodes and behavior trees, but the claim does not recite an improvement to computer functionality, GUI technology, processor operation, memory operation, network operation, or industrial control technology itself. Rather, the claim uses generic computer functionality to receive user inputs, display graphical objects, connect graphical objects, and generate a workflow representation. Under Step 2B, claim 1 does not include an inventive concept. The additional elements, considered individually and as an ordered combination, amount to no more than generic computer implementation of the abstract idea. The claim does not recite a particular technical solution that improves computer operation or another technology. Instead, the claim recites using conventional GUI and processing functionality to construct a behavior-tree workflow from user-selected graphical function blocks. Therefore, claim 1 is not directed to patent-eligible subject matter. Independent claim 10 is similarly directed to the same abstract idea in system form. Claim 10 recites a node library, a GUI, and an editing and processing module configured to receive function block node addition/connection operations and construct a behavior tree corresponding to one workflow. These elements are generic computer components performing the same abstract workflow-construction functions discussed above. Recasting the abstract method as a system does not add significantly more. Claim 12 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. Claim 12 recites a computer program product directly loadable into the internal memory of a digital computer, comprising software code portions for performing the steps according to claim 1 when the product is run on the digital computer. Claim 12 does not positively recite a non-transitory computer-readable storage medium or other statutory manufacture. Rather, the claim is directed to software code portions / a computer program product per se, which is not within one of the four statutory categories of invention under 35 U.S.C. § 101, namely a process, machine, manufacture, or composition of matter. Further, because the claim does not limit the computer program product to a non-transitory computer-readable storage medium, the claim encompasses transitory forms of signal transmission or software per se. Accordingly, claim 12 is directed to non-statutory subject matter and is rejected under 35 U.S.C. § 101. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim s 1-4, 6 and 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Crabtree et al. (US 2021/0136121) in view of Reitinger et al. (US 2022/0350308) . Regarding claim 1, Crabtree teaches a workflow construction method. In particular, Crabtree teaches providing a graphical user interface for creating a distributed computational graph representing a data processing workflow, where the graphical user interface includes icons representing data processing modules and connections between the modules, and where the graph includes data processing modules represented as nodes and connections represented as edges (paras. 0006, 0007). Crabtree further teaches that the frontend includes a workflow builder and a workflow mapper, where modules can be arranged and connected to form a data processing workflow (para. 0048). Crabtree teaches receiving function block node addition and connection operations performed on a graphical user interface (GUI) by a user on the basis of function block type graphs, because Crabtree teaches that creation of a workflow begins by selecting source, transformation, or sink modules, dragging and dropping the desired module into the workflow mapper, and arranging and connecting modules in the workflow mapper to form a directed graph representing the workflow (paras. 0050, 0072). Crabtree further teaches that the workflow builder includes selectable source modules, transformation modules, sink modules, and a workflow mapper space for designing workflow topology, and that the modules are placed and arranged within the workflow mapper using “drag-and-drop” manipulations (para. 0072). Crabtree teaches the recited function block type graph components. In particular, Crabtree teaches that each module represents a stage in a workflow and corresponds to one or more data processing steps or a cloud-based service responsible for executing the data processing steps (para. 0049), which teaches the claimed function block name and function block body. Crabtree also teaches that, when a module is dropped into the workflow mapper, a stage configuration window is displayed to prompt for stage connection details that define and format the stage (para. 0050), and that stage configuration attributes define the properties of each stage and how stages are interconnected, including parent-child relationships, stage type, and routing rules (para. 0057), which teaches the claimed function block header. Crabtree further teaches that modules have ports for connecting each module to another module, including input ports and output ports, and that connection lines are made by clicking on an output port of one module and connecting the connection line to an input port of another module (paras. 0073, 0074), which teaches the claimed link input port, link output port, data input port, and data output port. Crabtree also teaches that transformation modules receive data or messages and forward data or messages related to processing of the data (para. 0073), and that data contexts define how data leaves one stage and is understood by the next stage (paras. 0055, 0057), which teaches the claimed input data chunk and output data chunk. Crabtree teaches constructing a workflow in response to the node addition and connection operations because Crabtree teaches that, by arranging modules and routing interconnections between modules, a data processing workflow is created and implemented by the backend of the system (para. 0074). Crabtree also teaches constructing the data processing workflow from the distributed computational graph using an API that generates workflow code, validating the workflow, serializing the workflow, and executing the workflow using a data processing engine (paras. 0006, 0051-0053). Crabtree does not expressly teach constructing a behavior tree corresponding to one workflow in response to the function block node addition and connection operations. Reitinger teaches automatically generating a behavior tree program for controlling a machine (Abstract; para. 0008). Reitinger teaches that behavior trees are a programming paradigm for controlling machines and overcoming limitations of classical PLC programming approaches, where a behavior tree describes switching between tasks in a modular fashion and combines tasks into compositions defining the order and conditions under which tasks are executed (paras. 0005-0007). Reitinger further teaches generating a behavior tree program derived from machine commands and supervision data, where tasks of the behavior tree are derived from machine commands and the structure of the behavior tree is inferred by analyzing temporal relationships, return values, parameter settings, and co-occurrence of supervision data with task execution (paras. 0013, 0020-0028). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree’s GUI-based workflow construction system to construct the workflow as a behavior tree, as taught by Reitinger, because Reitinger teaches that behavior trees provide a modular and less error-prone paradigm for controlling machines, allowing complex tasks to be composed from simple tasks while defining the order and conditions for execution (para. 0005). One of ordinary skill in the art would have been motivated to represent Crabtree’s user-constructed workflow as a behavior tree in order to provide a known modular workflow/control structure suitable for machine or industrial automation workflows, thereby improving readability, modularity, and execution control of the constructed workflow. Regarding claim 2, Crabtree teaches or suggests wherein the function block type graph further comprises a first sensitive area located in a set range of the link input port, and a second sensitive area located in a set range of the link output port. In particular, Crabtree teaches that modules have ports for connecting each module to another module, including input ports and output ports (para. 0073). Crabtree further teaches that connections are made by “clicking on the output port” of a module, which spawns a connection line, and the connection line can be connected to a module having an input port (para. 0074). Crabtree teaches wherein when selection and line connection operations performed by the user are received in the first sensitive area, line connection end points are located on the link input port, and wherein when selection and line connection operations performed by the user are received in the second sensitive area, line connection end points are located on the link output port, because Crabtree teaches selecting/clicking an output port to generate a connection line and connecting the line to an input port of another module (para. 0074). To the extent Crabtree does not expressly use the term “sensitive area,” it would have been obvious to one of ordinary skill in the art to implement the clickable/selectable region around each input/output port as a predefined sensitive area or hit-detection region, so that user selection and connection operations near the port are recognized and the connection-line endpoint is snapped/located on the corresponding port. Such an implementation would have been a predictable GUI design technique for enabling reliable selection and connection of graphical ports in Crabtree’s drag-and-drop workflow mapper. Regarding claim 3, Crabtree teaches wherein the function block type graph further comprises a third sensitive area located in a set range of the data input port, and a fourth sensitive area located in a set range of the data output port. In particular, Crabtree teaches that modules have ports for connecting each module to another module, including input ports and output ports (para. 0073). Crabtree further teaches that transformation modules generally have an input port to receive data or messages and an output port to forward data or messages related to processing of the data (para. 0073). Crabtree teaches wherein when selection and line connection operations performed by the user are received in the third sensitive area, line connection end points are located on the data input port, and wherein when selection and line connection operations performed by the user are received in the fourth sensitive area, line connection end points are located on the data output port. In particular, Crabtree teaches that connections are made by “clicking on the output port” of a module, which spawns a connection line, and that the connection line can be connected to an input port of another module (para. 0074). To the extent Crabtree does not expressly use the term “sensitive area,” it would have been obvious to one of ordinary skill in the art to implement the clickable/selectable region around each data input/output port as a predefined sensitive area or hit-detection region, so that user selection and connection operations near the data port are recognized and the line connection endpoint is snapped/located on the corresponding data port. Such an implementation would have been a predictable GUI design technique for reliably connecting graphical data ports in Crabtree’s workflow mapper. Regarding claim 4, Crabtree teaches wherein the number of the data input ports of the function block nodes is identified on the input data chunk and the number of the data output ports of the function block nodes is further identified on the output data chunk. In particular, Crabtree teaches that modules have ports for connecting each module to another module, including input ports and output ports (para. 0073). Crabtree further teaches that transformation modules generally have an input port to receive data or messages and an output port to forward data or messages related to processing of the data (para. 0073). Crabtree also teaches that a workflow builder contains selectable source modules, transformation modules, sink modules, and a workflow mapper space for designing workflow topology (para. 0072), and that stage configuration attributes are properties of each stage and are used to define how stages are interconnected, including parent-child relationships, stage type, and routing rules (para. 0057). Accordingly, Crabtree teaches or suggests displaying and identifying the available input/output connection structure of each module so that the user can understand how each module may be connected in the workflow mapper. To the extent Crabtree does not expressly disclose identifying the number of data input ports on an input data chunk and identifying the number of data output ports on an output data chunk, it would have been obvious to one of ordinary skill in the art to display the number of available input and output ports on the corresponding input/output portions of a graphical module. Such a modification would have been a predictable GUI design technique to inform the user how many data inputs and data outputs are available for a module, thereby facilitating reliable connection of modules in Crabtree’s drag-and-drop workflow builder. Regarding claim 6, Crabtree teaches wherein the function block type graph further comprises a function block vector icon for visually representing service operations of the function block nodes. In particular, Crabtree teaches that the GUI contains data processing modules displayed as “graphic icons” that can be chained together to form a workflow in the form of a directed graph of computations (para. 0023). Crabtree further teaches that the graphical user interface includes icons representing data processing modules and connections between the modules, where the modules are represented as nodes and the connections are represented as edges of the distributed computational graph (paras. 0006, 0007). Crabtree also teaches that each module represents a stage in the workflow and corresponds to one or more data processing steps or a cloud-based service responsible for executing the data processing steps (para. 0049). Thus, Crabtree’s graphical icons visually represent the service operations/data processing operations of the corresponding workflow modules. To the extent Crabtree does not expressly state that the graphical icon is a “vector” icon, it would have been obvious to one of ordinary skill in the art to implement Crabtree’s graphical module icons as vector icons. Vector icons were a known and predictable graphical user interface implementation choice for representing operations in a scalable GUI, because vector icons can be resized and displayed at different resolutions without loss of visual clarity. Applying vector-icon formatting to Crabtree’s graphical module icons would have amounted to using a known GUI icon format for its ordinary purpose, with predictable results. Regarding claim 10, Crabtree teaches a workflow construction system comprising a node library storing function block nodes. In particular, Crabtree teaches a workflow builder containing selectable source modules, transformation modules, and sink modules that may be dragged and dropped into a workflow mapper space to create a workflow topology (paras. 0050, 0072). Crabtree further teaches that each module represents a stage in the workflow and corresponds to one or more data processing steps or a cloud-based service (para. 0049). Crabtree teaches wherein the function block nodes are presented in the form of a function block type graph on a GUI. In particular, Crabtree teaches that the graphical user interface includes icons representing data processing modules and connections between modules, where the modules are represented as nodes and the connections are represented as edges of the distributed computational graph (paras. 0006, 0007). Crabtree further teaches that modules are visually arranged and connected in a workflow mapper space (paras. 0048, 0050, 0072). Crabtree teaches a function block name for indicating the type of a service operation and a function block header for indicating a resource for executing a service operation. In particular, Crabtree teaches that each module represents a stage in the workflow, including source stages, transformation stages, and sink stages, and that each stage corresponds to one or more data processing steps or cloud-based services (para. 0049). Crabtree further teaches that when a module is dropped into the workflow mapper, a stage configuration window is displayed, and the stage configuration includes stage configuration information and API field information associated with a cloud-based service module (para. 0050). Thus, Crabtree teaches module/stage information identifying the type of operation and service/resource information for executing the operation. Crabtree teaches a link input port and a link output port for triggering link connection. In particular, Crabtree teaches that modules have ports for connecting each module to another module, including input ports and output ports (para. 0073). Crabtree further teaches that connections are made by “clicking on the output port” of a module to spawn a connection line and connecting the connection line to an input port of another module (para. 0074). Crabtree teaches an input data chunk for representing a set of all data input ports and an output data chunk for representing a set of all data output ports, and a data input port and a data output port for triggering data transmission. In particular, Crabtree teaches that transformation modules generally have an input port to receive data or messages and an output port to forward data or messages related to processing of the data (para. 0073). Crabtree also teaches that data context attributes define how data leaves one stage and is understood by a next stage, and that stage configuration attributes define how stages are interconnected, including parent-child relationships, stage type, and routing rules (para. 0057). Thus, Crabtree teaches data input/output connection structures and data context information corresponding to the claimed input/output data chunks and data ports. Crabtree teaches a function block body for bearing each component. In particular, Crabtree teaches graphical modules/icons representing workflow stages, where the modules are arranged and connected in the workflow mapper (paras. 0048, 0050, 0072). The graphical module body bears the module’s stage information, ports, and connection structure used to construct the workflow. Crabtree teaches a graphical user interface (GUI) for a user to perform function block node addition and connection operations. In particular, Crabtree teaches that a user selects source modules, transformation modules, and sink modules and places them into a workflow mapper space using drag-and-drop manipulations (paras. 0050, 0072). Crabtree further teaches that connections are made by clicking an output port to spawn a connection line and connecting the connection line to an input port of another module (para. 0074). Crabtree teaches wherein the function block node addition operation comprises a dragging operation for the function block body. In particular, Crabtree teaches that modules are dragged and dropped into the workflow mapper space to design the workflow topology (para. 0072). Crabtree teaches the function block node connection operation comprises a line connection operation between the link output port and the link input port between two function block nodes, and a line connection operation between the data output port and the data input port between corresponding data of two function block nodes. In particular, Crabtree teaches that modules include input and output ports and that connections are made by clicking an output port of one module to spawn a connection line and connecting the line to an input port of another module (paras. 0073-0074). Crabtree further teaches that transformation modules receive data or messages through input ports and forward data or messages through output ports, and that data contexts define how data leaves one stage and is understood by the next stage (paras. 0055, 0057, 0073). Crabtree teaches an editing and processing module that constructs a workflow in response to the function block node addition and connection operations. In particular, Crabtree teaches that arranging modules and routing interconnections among the modules creates a data processing workflow (para. 0074). Crabtree further teaches that the backend receives the workflow and constructs the workflow from JSON configurations using REST commands, validates the workflow, and generates workflow code for execution (paras. 0051-0053, 0057-0058). Crabtree does not expressly teach a node library storing function block nodes for constructing a behavior tree and an editing and processing module to construct a behavior tree corresponding to one workflow in response to the function block node addition and connection operations. Reitinger teaches constructing a behavior tree for controlling a machine. In particular, Reitinger teaches that behavior trees describe switching between tasks modularly and that tasks may be combined into compositions defining order and conditions for executing the tasks (paras. 0005-0007). Reitinger further teaches generating a behavior tree program derived from machine commands and supervision data and sending the generated behavior tree program to a controller to control the machine (paras. 0008-0013). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree’s graphical workflow construction system to construct the workflow as a behavior tree, as taught by Reitinger. A person of ordinary skill in the art would have been motivated to make this modification because Reitinger teaches behavior trees as a modular and readable way to represent execution order, conditions, and control flow for machine operations. The modification would have allowed Crabtree’s user-created graphical workflow to be represented in a behavior-tree structure for logical control and execution of the workflow. Regarding claim 11, Crabtree teaches an analyzing and deploying module to analyze the behavior tree by teaching a backend/manager API that analyzes and validates the constructed workflow. In particular, Crabtree teaches that the backend receives the workflow and constructs the workflow from JSON configurations using REST commands (para. 0051). Crabtree further teaches that the manager API validates that the workflow is configured properly, including validating stage properties and data context (para. 0052). Crabtree also teaches that workflow code is generated and sent to the data processing engine for execution (paras. 0057-0058). Crabtree does not expressly teach deploy the workflow corresponding to the behavior tree to a runtime of the corresponding workcell so that the resources in the workcell execute the operations according to the workflow. Reitinger teaches deploying a behavior tree program to a runtime/controller so that machine/workcell resources execute operations according to the behavior-tree workflow. In particular, Reitinger teaches generating a behavior tree program for controlling a machine and sending the generated behavior tree program to a controller of the machine to control the machine (paras. 0008-0013). Reitinger further teaches that the machine may be an automation cell, factory cell, production line, process line, assembly line, automated guided vehicle, or robot (para. 0038). Reitinger also teaches that the controller executes the behavior tree program to control the machine (para. 0039). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the workflow construction system of Crabtree, as combined with Reitinger’s behavior-tree construction, to include an analyzing and deploying module that analyzes the behavior tree and deploys the workflow corresponding to the behavior tree to a runtime/controller of a corresponding workcell as taught by Reitinger. A person of ordinary skill in the art would have been motivated to make this modification so that the constructed and validated graphical workflow/behavior tree could be executed by industrial machine resources in an automation cell, factory cell, production line, assembly line, or robot environment. The modification would have amounted to applying Reitinger’s known behavior-tree deployment/control technique to the workflow constructed using Crabtree’s graphical workflow system with predictable results. Regarding claim 12, Crabtree teaches a workflow construction system comprising at least one memory storing computer-readable codes and at least one processor to call the computer-readable codes. In particular, Crabtree teaches a system including a frontend user interface, a workflow builder, a workflow mapper, a backend, manager API, data stream processor, and data processing engine for constructing and executing workflows (paras. 0048-0058). Crabtree further teaches that the backend receives workflow information, constructs the workflow from JSON configurations, validates the workflow, and generates workflow code for execution (paras. 0051-0053, 0057-0058). Thus, Crabtree teaches a computer-implemented workflow construction system having memory storing instructions/code and processor-executed modules for performing the workflow construction operations . 07-21-aia AIA Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Crabtree et al. in view of Reitinger et al., and further in view of Sullivan et al. (US 2016/0110055) . Regarding claim 5, Crabtree teaches graphical workflow modules having data input ports and data output ports. In particular, Crabtree teaches that modules have ports for connecting each module to another module, including input ports and output ports (para. 0073). Crabtree further teaches that transformation modules generally have an input port to receive data or messages and an output port to forward data or messages related to processing of the data (para. 0073). Crabtree further teaches that modules are placed and arranged in a workflow mapper using drag-and-drop manipulations and that the modules are connected to form a workflow topology (para. 0072). Crabtree also teaches that connections are made by clicking on an output port of a module to spawn a connection line and connecting the connection line to an input port of another module (para. 0074). Crabtree does not expressly teach wherein the data input ports of the function block node may be expanded or hidden by clicking the input data chunk and wherein the data output ports of the function block node may be expanded or hidden by clicking the output data chunk. Sullivan teaches expand/collapse operations in a user interface. In particular, Sullivan teaches an affordance associated with a node, wherein selection of the affordance causes additional data associated with the node to be shown or hidden (paras. 0047-0050). Sullivan further teaches that selecting the affordance generates an expand/collapse selection event, and that a datasource module determines how to proceed based on whether the event is an expand event or a collapse event (paras. 0051-0059). Sullivan further teaches that for an expand operation, additional data is retrieved and displayed, and for a collapse operation, data is removed from the view (paras. 0043-0044). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree’s graphical workflow modules to include the expand/collapse functionality taught by Sullivan, such that input and output data-port information of a workflow module may be selectively expanded or hidden by clicking the corresponding input or output data portion of the module. A person of ordinary skill in the art would have been motivated to make this modification in order to reduce visual clutter in Crabtree’s workflow mapper while allowing the user to selectively display the ports/data details needed for connecting and configuring workflow modules. The modification would have amounted to applying Sullivan’s known GUI expand/collapse technique to Crabtree’s graphical workflow-node interface with predictable results . 07-21-aia AIA Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Crabtree et al. in view of Reitinger et al., and further in view of Cachat et al. (US 2003/0100958) . Regarding claim 7, Crabtree teaches interconnected function block nodes in response to line connection operations. In particular, Crabtree teaches that modules have ports for connecting each module to another module, including input ports and output ports (para. 0073). Crabtree further teaches that connections are made by “clicking on the output port” of a module to spawn a connection line and connecting the connection line to an input port of another module (para. 0074). Crabtree also teaches that arranging modules and routing interconnections among the modules creates a data processing workflow (para. 0074). Crabtree does not expressly teach generating an instruction label for indicating an execution sequence of the function block nodes for the interconnected function block nodes and identifying the instruction label on the function block type graphs of the function block nodes in response to the line connection operation. Cachat teaches generating execution-order information for function blocks in a function block diagram. In particular, Cachat teaches that conventional configuration tools provide graphical representations of control functions known as function blocks, where a user models a control strategy by placing function blocks in a user interface work surface and associating the function blocks using graphical connections known as wires (para. 0009). Cachat further teaches that existing tools allowed a user to manually assign an order number to each function block using a control configuration system user interface (para. 0010). Cachat further teaches automatically generating an execution order for a function block diagram according to input data availability (paras. 0013, 0027-0031). Cachat also teaches that generating the execution order may be accomplished by assigning an execution number to each of the function blocks in the function block diagram (para. 0015). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree’s interconnected graphical workflow modules to include Cachat’s execution-order numbering, such that an instruction label indicating execution sequence is generated for the interconnected function block nodes and identified on the corresponding graphical function block nodes. A person of ordinary skill in the art would have been motivated to make this modification to visually indicate the execution sequence of interconnected workflow nodes and to ensure that the workflow/control routine is generated according to the intended data-flow/execution order. The modification would have amounted to applying Cachat’s known execution-order numbering technique to Crabtree’s graphical workflow/function-block interface with predictable results . 07-21-aia AIA Claim s 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Crabtree et al. in view of Reitinger et al., and further in view of Sutanto et al. (US 2010/0058297) . Regarding claim 8, Crabtree teaches function block node addition and connection operations in a graphical workflow editor. In particular, Crabtree teaches that a user selects source modules, transformation modules, and sink modules and places them in a workflow mapper space where the workflow topology is designed (paras. 0050, 0072). Crabtree further teaches that connections are made by “clicking on the output port” of a module to spawn a connection line and connecting the connection line to an input port of another module (para. 0074). Crabtree also teaches that arranging modules and routing interconnections among the modules creates a data processing workflow (para. 0074). Crabtree does not expressly teach synchronously constructing a behavior tree comprising flow control nodes and function block nodes based on a function block label graph in response to the function block node addition and connection operations, wherein the flow control nodes are used for achieving logical control in the workflow. Reitinger teaches constructing a behavior tree for controlling a machine. In particular, Reitinger teaches that behavior trees describe switching between tasks modularly and that tasks may be combined into compositions defining order and conditions for executing the tasks (paras. 0005-0007). Reitinger further teaches generating a behavior tree program derived from machine commands and supervision data and sending the generated behavior tree program to a controller to control the machine (paras. 0008-0013). Thus, Reitinger teaches constructing a behavior tree having task/function nodes and logical/composition nodes for controlling execution order and conditions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree’s graphical workflow construction system to synchronously construct a behavior tree, as taught by Reitinger, in response to the user’s function block node addition and connection operations. A person of ordinary skill in the art would have been motivated to make this modification because Reitinger teaches behavior trees as a modular and readable way to represent execution order, conditions, and control flow for machine operations. The modification would have allowed Crabtree’s user-created graphical workflow to be represented in a behavior-tree structure for logical control and execution of the workflow. Regarding switching and displaying the behavior tree based on the function block type graph or the behavior tree based on the function block label graph according to a selection operation performed on the behavior tree based on the function block type graph or the behavior tree based on the function block label graph by the user, Sutanto teaches switching between different application views. In particular, Sutanto teaches mapping code elements displayable in a code view to workflow elements displayable in a workflow view such that a one-to-one correspondence is established between the code elements and the workflow elements (paras. 0007, 0043). Sutanto further teaches that the system switches views from a currently displayed view to at least one of a code view and a workflow view without restarting the debugging process (paras. 0008, 0049). Sutanto also teaches that a user may switch between any number of views and between various types of views, and that corresponding elements are displayed in the switched-to view (para. 0040). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Sutanto’s view-switching technique to the behavior-tree views generated from Crabtree and Reitinger, such that the user may switch and display either a behavior tree based on a function block type graph or a behavior tree based on a function block label graph according to the user’s selection. A person of ordinary skill in the art would have been motivated to make this modification to allow the same underlying workflow/behavior-tree information to be reviewed in different mapped graphical representations, thereby improving usability and allowing the user to inspect the workflow according to either node type or node label information. The modification would have amounted to applying Sutanto’s known mapped-view switching technique to the graphical workflow/behavior-tree interface of Crabtree and Reitinger with predictable results. Regarding claim 9, Crabtree teaches analyzing the behavior tree by teaching analysis/validation of the constructed workflow. In particular, Crabtree teaches that the backend receives the workflow and constructs the workflow from JSON configurations using REST commands (para. 0051). Crabtree further teaches that the manager API validates that the workflow is configured properly, including validating stage properties and data context (para. 0052). Crabtree also teaches that workflow code is generated and then sent to the data processing engine for execution (paras. 0057-0058). Crabtree does not expressly teach deploying the workflow corresponding to the behavior tree to a runtime of a corresponding workcell so that resources in the workcell execute operations according to the workflow. Reitinger teaches deploying a behavior tree program to control machine resources. In particular, Reitinger teaches generating a behavior tree program for controlling a machine and sending the generated behavior tree program to a controller of the machine to control the machine (paras. 0008-0013). Reitinger further teaches that the machine may be an automation cell, factory cell, production line, process line, assembly line, automated guided vehicle, or robot (para. 0038). Reitinger also teaches that the controller executes the behavior tree program to control the machine (para. 0039). Thus, Reitinger teaches deploying the workflow corresponding to the behavior tree to a runtime/controller of a corresponding workcell so that machine/workcell resources execute operations according to the behavior-tree workflow. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree’s workflow analysis/validation and execution system, as combined with Reitinger’s behavior-tree generation, to deploy the workflow corresponding to the behavior tree to a runtime/controller of a corresponding workcell as taught by Reitinger. A person of ordinary skill in the art would have been motivated to make this modification so that the constructed and validated graphical workflow/behavior tree could be executed by industrial machine resources in an automation cell, factory cell, production line, assembly line, or robot environment. The modification would have amounted to applying Reitinger’s known behavior-tree deployment/control technique to the workflow constructed using Crabtree’s graphical workflow system with predictable results . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Anicic et al (US 2020/0301675) abstract and Fig. 1 Any inquiry concerning this communication or earlier communications from the examiner should be directed to OMEED ALIZADA whose telephone number is (571)270-5907. The examiner can normally be reached Monday-Friday, 9:30 am until 5:30 pm. 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, Brian Zimmerman can be reached at 571-272-3059. 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. /OMEED ALIZADA/Primary Examiner, Art Unit 2686 Application/Control Number: 18/834,021 Page 2 Art Unit: 2686
Prosecution Insights