DETAILED ACTION
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 20 recites a computer system comprising a plurality of machine elements, wherein each machine element in the computer system comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, configures the system to perform the method of claim 1. It is not clear if claim 20 is meant to be an apparatus or article of manufacture claim, thereby raising questions regarding the intended scope of claim 20. If meant to be an apparatus claim, it is unclear how the functions are meant to limit the scope of the apparatus since each function is not explicitly tied to a corresponding limiting apparatus since it is currently recited that the system is configured to perform the method of claim 1; however, the specific steps from claim 1 are not clearly correlated to the specific elements of the system of claim 20.
Appropriate correction and clarification are required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-11 and 19-20 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Lodhia et al. (US 2020/0097262).
[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.).
[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 (¶ 77).
[Claim 20] Lodhia discloses a computer system comprising a plurality of machine elements, wherein each machine element in the computer system comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, configures the system to perform the method of any of claim 1 (¶ 77).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Huang et al. (US 2021/0247968) – Describes the use of visual programming to write a game (¶ 47).
Gudmundson et al. (US 5,907,704) – Discloses a multimedia authoring system.
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