DETAILED ACTION
This final Office action is responsive to Applicant’s amendment filed May 21, 2026. Claims 1 and 20 have been amended. Claims 12-18 are cancelled. Claims 1-11 and 19-20 are presented for examination.
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 .
Response to Amendment
The previously-pending rejection under 35 U.S.C. § 112(b) is withdrawn in response to Applicant’s amendments to claim 20.
Response to Arguments
Applicant's arguments filed May 21, 2026 have been fully considered but they are not persuasive.
Applicant submits that Lodhia does not address the amended claim limitations (pages 7-9 of Applicant’s response). The Huang reference has been introduced into the rejection in order to help address the claim amendments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lodhia et al. (US 2020/0097262) in view of Huang et al. (US 2023/0115334).
[Claim 1] Lodhia discloses a method of compiling instructions (¶ 20 – “In some embodiments, described is a mechanism that provides the ability to reuse a portion of visual programming logic within an automation building tool. As described, the mechanism may be used within an automation building tool (or automation builder) that provides a visual interface to create a program using visual components. For example, the programming logic may be represented as a directed acyclic graph (DAG) such that the nodes of the graph correspond to various operations and the edges of the graph correspond to the logic flow of the program. Accordingly, the user (or developer) may visually connect various operations and create a workflow as part of an automated program. For example, the workflow may be part of a marketing campaign such as an automated email marketing procedure. In some embodiments, the mechanism may provide a new capability to reuse portions of the visual programming logic while adhering to the requirements of a DAG structure. For example, a user may copy a valid substructure of visual programming logic for reuse upon a validation the programming logic may be inserted into another portion of the DAG. “; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.” Compiling may refer to building a set of programming logic to execute a workflow with a decision tree.; ¶ 21 – “Such a feature may aid the user by providing an assurance that a copied portion of logic may be reused within the program without causing errors at the time of insertion. This in turn reduces user errors that may occur using a mere copy and paste functionality that is not concerned with validation until the time of insertion or testing.”; ¶ 77 – “Program code 1270 may include both machine code, such as produced by a compiler, and files containing higher-level or intermediate code that may be executed by a computing system or other data processing apparatus (or machine) using an interpreter.” Compiling may also refer to translating the human-defined instructions into executable machine code.) for execution of an interactive media program on an electronic device for an interactive game or movie (Lodhia describes an automated email marketing campaign as a program to be automated, as seen in ¶ 27. While the operations of emailing are interactive, Lodhia’s email marketing campaign is not an interactive game or movie per se. When reading the preamble in the context of the entire claim, the recitation “for an interactive game or movie” is not limiting because the body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02.), the method comprising:
retrieving data derived from a set of nodes representable graphically on a user-interface, said set of nodes connected via pathways, wherein the pathways define routes through the set of nodes (¶ 20 – “For example, the programming logic may be represented as a directed acyclic graph (DAG) such that the nodes of the graph correspond to various operations and the edges of the graph correspond to the logic flow of the program. Accordingly, the user (or developer) may visually connect various operations and create a workflow as part of an automated program. For example, the workflow may be part of a marketing campaign such as an automated email marketing procedure.“), and said data includes:
machine-executable content and/or script (¶ 26 – “For example, a user (or developer) may create visual programming logic represented as a directed acyclic graph (DAG) where nodes of the DAG represent various operations performed by a system. Accordingly, the building tool 191 may provide an interface for creating a program.”; ¶ 40 – “In 801, the system may provide, within the automation building tool, visual programming logic for a program. As described, the visual programming logic may be represented as a directed acyclic graph (DAG) including one or more nodes each representing an operation to be performed by the system. In one embodiment, the one or more operations of the program may perform an automated email marketing procedure. For example, the one or more operations may include one or more of a start operation, action operation, trigger operation, rule operation, and an end operation.”); and
variables that determine selectable pathways between the set of nodes (¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”); and
compiling said data into machine-readable instructions for executing in a machine configured to execute the machine-executable content and/or script (¶ 20 – “In some embodiments, described is a mechanism that provides the ability to reuse a portion of visual programming logic within an automation building tool. As described, the mechanism may be used within an automation building tool (or automation builder) that provides a visual interface to create a program using visual components. For example, the programming logic may be represented as a directed acyclic graph (DAG) such that the nodes of the graph correspond to various operations and the edges of the graph correspond to the logic flow of the program. Accordingly, the user (or developer) may visually connect various operations and create a workflow as part of an automated program. For example, the workflow may be part of a marketing campaign such as an automated email marketing procedure. In some embodiments, the mechanism may provide a new capability to reuse portions of the visual programming logic while adhering to the requirements of a DAG structure. For example, a user may copy a valid substructure of visual programming logic for reuse upon a validation the programming logic may be inserted into another portion of the DAG. “; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.” Compiling may refer to building a set of programming logic to execute a workflow with a decision tree.; ¶ 21 – “Such a feature may aid the user by providing an assurance that a copied portion of logic may be reused within the program without causing errors at the time of insertion. This in turn reduces user errors that may occur using a mere copy and paste functionality that is not concerned with validation until the time of insertion or testing.”; ¶ 77 – “Program code 1270 may include both machine code, such as produced by a compiler, and files containing higher-level or intermediate code that may be executed by a computing system or other data processing apparatus (or machine) using an interpreter.” Compiling may also refer to translating the human-defined instructions into executable machine code.).
Lodhia does not explicitly disclose:
prior to compiling, evaluating execution of the machine-executable content and/or script across a plurality of said pathways to determine whether one or more compilation criteria are satisfied, wherein the evaluating comprises simulating execution of the machine-executable content and/or script; and
compiling said data into machine-readable instructions for executing in a machine configured to execute the machine-executable content and/or script only if the one or more compilation criteria are satisfied.
Huang discloses:
prior to compiling, evaluating execution of the machine-executable content and/or script across a plurality of said pathways to determine whether one or more compilation criteria are satisfied, wherein the evaluating comprises simulating execution of the machine-executable content and/or script (Huang: ¶ 44 – “FIG. 3 depicts an example expansion scenario of a macro during debugging according to one or more embodiments of the present invention. In the depicted scenario, the macros TARG 104A, PRO 104B, MYDEF 104C are used. Consider that the computer instructions in the file 302 ‘a.c’ lines 9-11 should be compiled because the compile time condition 202A of macro MYDEF 104C is defined in the runtime command 320 to initiate the compiler 110 to compile the files 302, 306, 308 into a preprocessed file 312. In the example in FIG. 3, the command 320 only runs the preprocessor of the compiler 110 and then exports the expanded macros and included files (e.g., a.h 306) information to the preprocessed file a.e 312. The preprocessed file 312 is used subsequently to generate the object code. However, the result of the compilation is not as expected as seen in the section 314, lines 1825-1830 of the preprocessed file 312. The reason is that the macro MYDEF 104C got undefined in the file 308 ‘b.h’ line 2. The compile time conditions 202B and 202C cause the subsequent expansion of computer instructions in the object code 314 (rather than the desired compile time condition 202A). It can be appreciated that the example scenario here shows a scenario with very few lines of code; however, in large projects with thousands of lines of code, it is a technical challenge to determine such root causes of failures when porting a computer program.”; ¶ 46 – “Further, in one or more embodiments of the present invention, a preprocessor collects and identifies and generates records of the computer instructions that are enclosed (and not enclosed) in macros 104. Further, the compiler 110 supports macro definition conflict by comparing compile time conditions 202 MacroEnclosed and CurrentMacroValue, to identify the impact on the corresponding macros 104. The compiler (and/or linker) 110 supports a macro redefinition path across source code files 102, 103 by locating the macro enclosed records with MacroEnclosed ‘ON’ and runtime options, such as Preprocesstype ‘D’, to compare AssignedMacroValue and EarlierAssignedMacroValue across the different files. Accordingly, one or more embodiments of the present invention facilitates to analyze and identify the root cause of a macro conflict which can cause computer instructions to be compiled (or not) into the object 120 file, and also provide macro redefinition warning across several source code files.”; ¶ 51 – “FIG. 5 depicts a flowchart of a method for detecting macros in a computer program and identifying paths of compile time conditions that can cause compilation errors and/or execution errors according to one or more embodiments of the present invention. The method 500 can be executed by the development tool 112. The method 500 includes receiving a command to compile detect the macros and compile time conditions at time of compiling the computer program 106, at block 502. For example, an option ‘-p’ in the compiling command “gcc-DTARG-c a.c-p” triggers the compiler 110 to initiate the detection and generate the macro information 412 for the computer program 106. Alternatively, or in addition, the trigger could be based on an environment variable associated with the development tool 112, or the operating system of the computing platform 130.”; ¶ 64 – “Continuing with the flowchart of the method 500, at block 508, macro conflicts are checked in the source code that is expanded by the compiler 110. FIG. 9 depicts a flowchart of a method 900 for operations performed for checking the macro conflicts according to one or more embodiments of the present invention. For explanation, the description herein includes a walkthrough of the example macro MYDEF 104 from FIG. 6 (lines 8-18 in file “a.c” 302). In this example, the definition of macro ‘MYDEF’ is passed as part of the compiling command. Consider that, all computer instruction that meet the condition including ‘MYDEF’ being defined are to be expanded in the object 112, however, the computer instructions in the file ‘a.c’ 302 lines 9-10 are not expanded, and hence not compiled.”; fig. 5 --
PNG
media_image1.png
536
452
media_image1.png
Greyscale
; A walkthrough is performed on a macro to check for conflicts. As seen in ¶¶ 71-72, a path-change detection for a macro can be performed. Explained in ¶ 47 is that the debugging includes identification of macros in the computer program. The walkthroughs, debugging, identification of possible macro conflicts, etc. (Huang: ¶¶ 64-65), in effect, present examples of simulations regarding the potential macro operations individually and in combination with other macros.); and
compiling said data into machine-readable instructions for executing in a machine configured to execute the machine-executable content and/or script only if the one or more compilation criteria are satisfied (Huang: ¶ 43 – “One or more of the macros 104 are conditional. A dynamic compile time condition 202 is associated with such conditional macros, such that the computer instructions in the conditional macros 104 are compiled (i.e., converted to object 120 code) only if the associated compile time condition 202 is satisfied. If the compile time condition 202 is not satisfied the computer instructions in the conditional macro 104 are not included in the object 120. The compile time conditions 202 can indicate a combination type of hardware and software of the target computing platform 130. For example, a compile time condition 202 can indicate that the macro 104 is to be expanded only if the platform uses a particular operating system such as, LINUX®, AIX®, INTERIX®, Z/OS®, etc. Alternatively, or in addition, the compile time condition 202 can indicate that the macro 104 is to be expanded only if one or more other source code files (e.g., a header file) is included. In some examples, the expanded macro 104 can itself be an inclusion of additional source code files, such as a library, an application programming interface, etc. Alternatively, or in addition, the expanded macro 104 can cause a particular type of hardware component or software component to be “mounted.” Here, “mounting” includes acquiring access to the component, e.g., recognizing, reading, and processing a file system structure, a storage medium, etc., before registering the component for use. Several additional or alternative operations can be performed by the computer instructions enclosed in the macros 104 in one or more embodiments of the present invention.”; ¶ 50 – “In addition, the development tool 112 includes the compiler 110 and the linker 406, which convert the computer program 106 into object code 120 and machine executable instructions for the target computing platform 130.”).
Lodhia facilitates the reuse of programming logic (Lodhia: abstract). Similarly, Huang facilitates the reuse of computer program instructions, like macros (Huang: ¶ 27). The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Lodhia to perform the following steps:
prior to compiling, evaluating execution of the machine-executable content and/or script across a plurality of said pathways to determine whether one or more compilation criteria are satisfied, wherein the evaluating comprises simulating execution of the machine-executable content and/or script; and
compiling said data into machine-readable instructions for executing in a machine configured to execute the machine-executable content and/or script only if the one or more compilation criteria are satisfied
in order to “improve debugging of computer programs (i.e., source code) that include macros. Embodiments of the present invention provide a practical application to identify macros and debug computer programs that include macros. Without using the embodiments of the present invention, such an analysis, particularly for large enterprise projects, can be impractical, or cause significant delays in development, debugging, testing, and release.” (Huang: ¶ 35) Lodhia would be amenable to such modifications given that, like Huang, Lodhia facilitates the reuse of programming logic. Additionally, as explained in ¶ 27 of Huang, the benefits of reusing programming logic can be applied to macros (Huang: ¶ 27 – “Using a macro can make the source code of the computer program compact and avoid duplication efforts.”). The substitution of Huang’s macros for Lodhia’s reusable programming logic would have been well within the technical capability of those skilled in the art prior to Applicant’s invention and such a substitution would have yielded predictable and expected results. Huang describes the additional benefit of the proposed modifications to Lodhia in that “the compiler 110 improves the efficiency of execution of the computer program 106 when executing on the target computing platform 130.” (Huang: ¶ 38)
[Claim 2] Lodhia discloses wherein execution of the machine-readable content and/or script enables at least one of:
determination of the selectable pathways at a specific node within the set of nodes based on the variables, wherein the variables include initial variables and/or latest variables updated by actions performed on the preceding pathway (fig. 2-7; ¶ 29 – “An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system.”); and
updating the initial variables and/or latest variables based updated by actions performed at a specific node within the set of nodes (figs. 3, 5; ¶ 30 – “In some embodiments, the interface may also include various modes of operations. Accordingly, a user may interact with the building tool (or interface) by switching between various modes. For example, the building tool may include a build-mode (e.g. as shown in diagram 200) that allows a user to add, delete, and modify operations, as well as perform other operations that may be part of a program creation process. In addition, the building tool may include a select-mode (e.g. as shown in diagram 300 and as further described herein) that limits the functionality to allowing the user to only select one or more operations (e.g. disables the ability to add, delete, or modify operations). Accordingly, with such embodiments, the interface may include an indicator that specifies the current mode (e.g. tab, highlighted button, etc.). It should be noted that a “build” and a “select” mode are provided merely as examples and other nomenclature for substantially equivalent modes are contemplated. In this example, the user may select modes via one or more selection options. For instance, as shown, the options may include a select option 230 and a copy option 232. Once a user provides an input to select one or more operations (e.g. via the selection option 230), the user may be provided with the ability to select (or specify) particular operations (e.g. a portion of visual programming logic) as shown in FIG. 3.”).
[Claim 3] Lodhia discloses wherein execution of the machine-readable content and/or script determines multi-directional interactive routes through the pathways, said routes determined by nodes based on initial values of the variables and/or updated values of the variables that determine the latest variables as a consequence of previously executed actions performed on the preceding pathway (fig. 5; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”).
[Claim 4] Lodhia discloses wherein each pathway defines a sequential order in which the machine-executable content and/or script is executed (fig. 5; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”).
[Claim 5] Lodhia discloses wherein the data is retrieved from a common data set (¶ 36 – “Accordingly, the system may determine whether a selected set of one or more operations is valid as a reusable portion of programming logic based on a combination of such rules. For example, the system may determine the selected set of operations are valid if the first to third rules are satisfied, or if all four rules are satisfied, etc.”) including at least one of:
the machine-executable content and/or script (¶ 26 – “For example, a user (or developer) may create visual programming logic represented as a directed acyclic graph (DAG) where nodes of the DAG represent various operations performed by a system. Accordingly, the building tool 191 may provide an interface for creating a program.”);
the variables that determine selectable pathways between the set of nodes (¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”);
actions that are the outcome of the execution of the machine-executable content and/or script (fig. 5; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”); and
a plurality of formats (¶ 29 – “As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”),
wherein the common data set is compiled simultaneously (¶ 20 – “In some embodiments, described is a mechanism that provides the ability to reuse a portion of visual programming logic within an automation building tool. As described, the mechanism may be used within an automation building tool (or automation builder) that provides a visual interface to create a program using visual components. For example, the programming logic may be represented as a directed acyclic graph (DAG) such that the nodes of the graph correspond to various operations and the edges of the graph correspond to the logic flow of the program. Accordingly, the user (or developer) may visually connect various operations and create a workflow as part of an automated program. For example, the workflow may be part of a marketing campaign such as an automated email marketing procedure. In some embodiments, the mechanism may provide a new capability to reuse portions of the visual programming logic while adhering to the requirements of a DAG structure. For example, a user may copy a valid substructure of visual programming logic for reuse upon a validation the programming logic may be inserted into another portion of the DAG. “; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.” Compiling may refer to building a set of programming logic to execute a workflow with a decision tree.; ¶ 21 – “Such a feature may aid the user by providing an assurance that a copied portion of logic may be reused within the program without causing errors at the time of insertion. This in turn reduces user errors that may occur using a mere copy and paste functionality that is not concerned with validation until the time of insertion or testing.”; ¶ 77 – “Program code 1270 may include both machine code, such as produced by a compiler, and files containing higher-level or intermediate code that may be executed by a computing system or other data processing apparatus (or machine) using an interpreter.” Compiling may also refer to translating the human-defined instructions into executable machine code.; ¶ 36 -- “Accordingly, the system may determine whether a selected set of one or more operations is valid as a reusable portion of programming logic based on a combination of such rules. For example, the system may determine the selected set of operations are valid if the first to third rules are satisfied, or if all four rules are satisfied, etc.”).
[Claim 6] Lodhia discloses wherein the set of nodes comprises:
a start node that only has an output connection (figs. 2-7; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”);
an intermediate node having an input connection and an output connection, and connected to the start node via a pathway (figs. 2-7; ¶ 29); and
an end node only having an input connection, and connected to the intermediate node (figs. 2-7; ¶ 29).
[Claim 7] Lodhia discloses wherein the set of nodes includes at least one of:
a plurality of end nodes, and a plurality of pathways connecting the start node, at least one intermediate node and each of the plurality of end nodes (fig. 7; ¶ 29);
a plurality of intermediate nodes (fig. 7; ¶ 29);
at least one of the start node and an intermediate node have a plurality of output connections (fig. 7; ¶ 29).
[Claim 8] Lodhia discloses wherein the selectable connections to a subsequent node on the pathway is determined from data defining conditions and/or weightings at a specific node (figs. 2-7; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”) and include at least one of:
a default connection, when no action is taken or input is available (fig. 7; ¶ 29);
a first connection based on a condition, wherein said condition is determined from the status of the variables (fig. 7; ¶ 29);
a second connection based on an alternative conditions determined from the status of the variables (fig. 7; ¶ 29).
[Claim 9] Lodhia discloses wherein each node in the set of nodes contains data including at least one of:
properties of the node, including at least one of a title of the node, a description of the node, a summary of the node, a text description of the node, script, descriptions of the asset that the node represents and a media file (figs. 2-7);
actions that modify the variables (figs. 2-7; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”);
selectable connections to a subsequent node on the pathway (figs. 2-7);
content including information associated with the function of the node (figs. 2-7; ¶ 29 – “In one embodiment, the operations may be selected from a specific set of available types of operations. For example, the building automation tool may provide a predefined set of types of operations. For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree). For example, the trigger operation may listen for an event such as opening an email, clicking an email link 216, submitting a form within a specified number of days, or any other events. A rule may check for specified criteria or values within the system. For example, a rule operation may check or verify a particular field related to a customer (e.g. prospect). As shown, in some embodiments, each type of operation may correspond to a particular node shape (e.g. circle, square, hexagon, triangle, etc.). It should be noted that other indicators (e.g. colors) may also be used to distinguish between operations and types of operations.”);
executable files;
links to external files;
parameters (¶ 29);
events (¶ 29 );
machine-executable script (¶ 26 – “For example, a user (or developer) may create visual programming logic represented as a directed acyclic graph (DAG) where nodes of the DAG represent various operations performed by a system. Accordingly, the building tool 191 may provide an interface for creating a program.”; ¶ 40 – “In 801, the system may provide, within the automation building tool, visual programming logic for a program. As described, the visual programming logic may be represented as a directed acyclic graph (DAG) including one or more nodes each representing an operation to be performed by the system. In one embodiment, the one or more operations of the program may perform an automated email marketing procedure. For example, the one or more operations may include one or more of a start operation, action operation, trigger operation, rule operation, and an end operation.”); and
data associated with resource requirements for executing the program underlying the node and/or operating a machine according to the node actions (¶¶ 26, 29, 40).
[Claim 10] Lodhia discloses wherein each node in the set of nodes is one of:
an action node, including at least one of
an instruction to update the variables,
connections to selectable pathways determinable based on conditions that evaluate the variables (figs. 2-7; ¶ 29),
data for controlling an external device, and
a multimedia data configured to play a multimedia file;
an evaluation node, including at least one of
an instruction to update the variables, and
connections to selectable pathways determinable based on conditions that evaluate the variables (figs. 2-7; ¶ 29); and
a weighted node, configured to automatically evaluate the state of the variables at said weighted node and automatically select the next node (fig. 4; ¶ 29 – “For example, as provided in this example related to an email marketing program, the predefined set of operations may include a start (or begin) operation, an action operation, a trigger operation, a rule operation, and a stop (or end) operation. A start operation may designate the start of a program path, and an end operation designate the end of a program path. An action operation may perform various actions at a given point in time. For example, in the context of an email marketing program, an action operation may include operations such as send an email, add a user/customer to a list, adjust a score associated with a user/customer, and any other actions. A trigger operation may wait (or listen, monitor, etc.) for a particular event (or characteristic, action, etc.). In addition, the trigger operation may act as a decision tree where the program path (or logic flow) may split based on the occurrence of a particular event (e.g. yes/no decision tree).” A node in a decision tree may include a “yes” or “no” option, which is an example of a weighted response. For example, detection of an event that triggers a “yes” response may be weighted more heavily than no detection of a specified event, thereby triggering a “no” response, i.e., a response that does not require further action at the moment.).
[Claim 11] Lodhia discloses providing a graphical user-interface, creating the set of nodes and the pathways on the graphical user-interface and entering data associated with said set of nodes on said graphical user-interface; and/or providing a graphical user-interface for displaying problems and/or performance criteria of the script as represented in the workspace (figs. 2-7; ¶ 21 – “In addition, the mechanism may provide an efficient validation process that further aids a user to select, copy, and insert (or paste) a portion of visual programming logic within a program. Accordingly, the mechanism may provide advantages over existing tools that merely provide a copy and paste functionality. For example, in some embodiments, the mechanism performs a validation (or partial validation) at the time the user selects operations to be copied. Accordingly, such a validation provides a degree of certainty that operations that are copied may be validly inserted (e.g. without error) into other portions of the process flow of the DAG. Such a feature may aid the user by providing an assurance that a copied portion of logic may be reused within the program without causing errors at the time of insertion. This in turn reduces user errors that may occur using a mere copy and paste functionality that is not concerned with validation until the time of insertion or testing.”; ¶ 22 – “In addition, in some embodiments, the mechanism may provide various interface elements (or visual cues) in conjunction with the unique validation process. In one aspect, the mechanism provides the ability to easily select elements of the DAG such as operations and also enables or disables the ability perform a copy option (e.g. button) based on the current validity of the selected operations. For example, the mechanism may enable the copy function only when a suitable combination of operations for copying are selected. In another aspect, the mechanism provides a convenient mechanism that allows the user to insert copied operations within a particular insertion point of the DAG. In some embodiments, the mechanism may also sanitize copied operations to further provide the ability to insert portions of logic within the DAG.”).
[Claim 19] Lodhia discloses a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the method of claim 1 (Lodhia: ¶ 77).
[Claim 20] Claim 20 recites limitations already addressed by the rejection of claim 1 above; therefore, the same rejection applies. Lodhia discloses a computer system comprising a processor; and a memory including executable instructions stored thereon that, as a result of execution by the processor, cause the processor to perform the recited operations (Lodhia: ¶ 77).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 SUSANNA M DIAZ whose telephone number is (571)272-6733. The examiner can normally be reached M-F, 8 am-4: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 Epstein can be reached at (571) 270-5389. 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.
/SUSANNA M. DIAZ/
Primary Examiner
Art Unit 3625A
Prosecution Insights