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 INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Such claim limitations are: “interaction-module display module, attribute value configuration module, interaction-unit processing module, interaction event response module” in claim 11.
The specification discloses corresponding structure and algorithms, including a processing apparatus (e.g., processor 501) programmed to execute the following: For the interaction-module display module, the corresponding algorithm includes acquiring the event interaction module in response to an interaction triggering operation, and displaying the acquired event interaction module on a target function interface (paragraphs [0041], [0042], [0117]). For the attribute value configuration module, the corresponding algorithm includes receiving a selection operation acting on the event configuration command, displaying an attribute value configuration interface, and receiving a command attribute value inputted based on the interface or selected from at least one candidate attribute item (paragraphs [0048]-[0051], [0118]). For the interaction-unit processing module, the corresponding algorithm includes traversing each event configuration command, parsing the command attribute value to obtain a command data structure diagram, and connecting a plurality of command data structure diagrams based on a logical relationship (e.g., parallel or progressive); or querying a preset storage space based on the command attribute value and acquiring an existing unit data structure diagram (paragraphs [0054]-[0065], [0119], [0123]-[0128], [0131]-[0133]). For the interaction event response module, the corresponding algorithm includes determining that a command function node includes a key node of a target connection port (command output port and/or input port), connecting unit data structure diagrams based on the key node and target connection port to obtain a module data structure diagram, converting the module data structure diagram into an interaction response script, and executing the script (paragraphs [0072], [0073], [0096]-[0100], [0120], [0135], [0136]).
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 20 discloses “A storage medium comprising…” without explicitly including the word “non-transitory.”
The specification explicitly distinguishes between storage media and signal media, and provides support for non-transitory media: “some embodiments of the present disclosure include a computer program product, which includes a computer program carried by a non-transitory computer-readable medium” (paragraph [0145]), “It should be noted that the above-mentioned computer-readable medium in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination thereof” (Paragraph [0149], and “The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium” (Paragraph [0160].
Thus, the broadest reasonable interpretation in light of specification encompasses that the storage medium forms transitory propagating signal per se that is non-statutory subject matter under 35 U.S.C. 101, signal per se.
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 pre-AIA 35 U.S.C. 112, 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.
Claims 2, 3, 6, 13, 14, and 15 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, 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 pre-AIA the applicant regards as the invention.
Claims 2, 3, and 6 depend on Claim 1. Claim 1 explicitly discloses an “event interaction unit” and an “event configuration command.” However, Claims 2 and 3 disclose “in response to the event configuration unit” and Claim 6 recites “storing the command attribute value corresponding to the event configuration unit”. There is no antecedent basis for an “event configuration unit” in Claim 1, creating ambiguity as to what element is being referenced. For the purpose of this examination, “the event configuration unit” in Claims 2, 3, and 6 has been interpreted as “the event interaction unit.”
Claims 13, 14, and 15 depend on Claim 12. Claim 12 explicitly discloses an “event interaction unit.” However, Claims 13 and 14 disclose “in response to the event configuration unit” and Claim 15 recites “storing the command attribute value corresponding to the event configuration unit”. There is no antecedent basis for an “event configuration unit” in Claim 12, resulting in a lack of antecedent basis. For the purpose of this examination, “the event configuration unit” in Claims 13, 14, and 15 has been interpreted as “the event interaction unit.”
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 1-6, 8-15, and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Luenstroth et al. (US 2018/0039566, hereinafter Luenstroth).
Regarding claim 1, Luenstroth discloses
An interaction event response method (paragraph [0009], [0062]: a method for testing a control program by feeding it a stimulus STIM and recording a response RESP), comprising:
displaying an event interaction module, wherein the event interaction module comprises at least one event interaction unit, and the event interaction unit comprises at least one event configuration command (paragraph [0048]: providing a graphical user interface for creating and modifying block diagrams (i.e., event interaction module) … The block diagram may comprise multiple blocks (i.e., event interaction units) … A block may describe an atomic operation, such as an arithmetic calculation or a logic expression [event configuration command);
acquiring a command attribute value corresponding to the event configuration command in response to an attribute value configuration triggering operation for the event configuration command in the event interaction unit (paragraph [0013], [0048]: indicating values of parameters of the technical environment via a user interface (i.e., attribute value configuration triggering operation) … an initial block may receive a signal of type single as input signal, may modify the signal e.g. by adding a constant (i.e., command attribute values));
acquiring a unit data structure diagram corresponding to the event interaction unit based on the command attribute value corresponding to each event configuration command in each event interaction unit in response to an event execution triggering operation for the event interaction module (paragraph [0054], [0059]: Upon activation of the simulation engine (i.e., event execution triggering operation) … the selected one or more blocks and related input data are transformed to an intermediate representation such as one or more hierarchical graphs, comprising a data flow graph, a control flow graph and/or a tree structure (i.e., unit data structure diagram)); and
generating a module data structure diagram corresponding to the event interaction module based on the unit data structure diagram, converting the module data structure diagram into an interaction response script, and executing the interaction response script (paragraphs [0055]-[0056], [0061]: the hierarchical graphs are optimized (i.e., generating a module data structure diagram) … the optimized intermediate representations such as optimized hierarchical graphs are translated to code in a high-level or low-level programming language, preferably C code (i.e., converting into an interaction response script) … The generated production code is then compiled to object code or an executable… a stimulus STIM is fed to the object code or executable OBJ, and the output signals are recorded (i.e., executing the interaction response script); Note: Under the Broadest Reasonable Interpretation, the claimed “script” is construed broadly as any sequence of instructions or code written in a programming language to be executed by a computer. Therefore, Luenstroth’s disclosure of translating the graphs into high-level or low-level programming code (e.g., C code) reads directly on converting the diagram into a script).
Regarding claim 11 referring to claim 1, Luenstroth discloses an interaction-module display module (paragraph [0042]: The host computer PC comprises … a display; paragraph [0048]: The modelling environment MOD may provide a graphical user interface for creating and modifying block diagrams; Note: The host computer PC hardware (display) executing the modelling environment MOD software, specifically the Graphical User Interface (GUI).), an attribute value configuration module (paragraph [0042]: The host computer PC comprises… human interface devices such as a keyboard and a mouse … ; paragraph [0048]: graphical user interface for creating and modifying block diagrams; paragraph [0054:] Related input data may e.g. be extracted from a database associated with the block diagram; Note: The host computer PC hardware (keyboard/mouse) and the modelling environment MOD receiving user inputs to modify blocks and extract related input data/parameters), an interaction-unit processing module (paragraph [0042]: The host computer PC comprises at least one processor CPU; paragraph [0051]: The production code generator PCG allows for creating production code from one or more blocks in a block diagram; paragraph [0054]: In a first step S1, the selected one or more blocks … and related input data are transformed to an intermediate representation such as one or more hierarchical graphs; Note: The processor (CPU) executing the Code Generator (PCG) to transform the blocks and input data into intermediate hierarchical graphs), an interaction event response module (paragraph [0056]: In a third step S3, the optimized intermediate representations are translated to code in a high-level programming language, such as C code; paragraph [0061]: the blocks corresponding to the control program are converted to program code via the production code generator PCG. The generated production code is then compiled to object code or an executable using the production code compiler PCO; paragraph [0075]: compiling, in step 706, by the host computer the production code to an executable… running, in step 707, the executable on the host computer in an operating system of the host computer; Note: The processor (CPU) executing the Production Code Generator (PCG) and Production Code Compiler (PCO) to translate the graphs into code, compile it, and execute it on the host computer).
Regarding claim 12 referring to claim 1, Luenstroth discloses An electronic device, comprising: one or more processors; a storage apparatus, configured to store one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement: … (Fig. 1).
Regarding claims 2 and 13, Luenstroth discloses
wherein acquiring the unit data structure diagram corresponding to the event interaction unit based on the command attribute value corresponding to each event configuration command in each event interaction unit in response to the event execution triggering operation for the event interaction module (paragraph [0054], [0059]: Upon activation of the simulation engine (i.e., event execution triggering operation) … the selected one or more blocks and related input data are transformed to an intermediate representation such as one or more hierarchical graphs, comprising a data flow graph, a control flow graph and/or a tree structure (i.e., unit data structure diagram)), comprises:
in response to the event configuration unit comprising one event configuration command, parsing the command attribute value corresponding to the event configuration command to obtain a command data structure diagram corresponding to the event configuration command, and taking the command data structure diagram as the unit data structure diagram corresponding to the event interaction unit (paragraph [0048]: A block may describe an atomic operation, such as an arithmetic calculation or a logic expression …; paragraph [0054]: In a first step S1, the selected one or more blocks (or, if selected, the entire block diagram) and related input data are transformed to an intermediate representation such as one or more hierarchical graphs. These hierarchical graphs may in particular comprise a data flow graph …; Note: Under the Broadest Reasonable Interpretation, when Luenstroth parses a block that consists of only a single “atomic operation” (one event configuration command) and its related input data/parameters (command attribute values) to generate a hierarchical graph (data structure diagram), the graph representing that single operation inherently serves as the graph for that entire block (taking the command data structure diagram as the unit data structure diagram).
Regarding claims 3 and 14, Luenstroth discloses
wherein acquiring the unit data structure diagram corresponding to the event interaction unit based on the command attribute value corresponding to each event configuration command in each event interaction unit in response to the event execution triggering operation for the event interaction module (paragraph [0054], [0059]: Upon activation of the simulation engine (i.e., event execution triggering operation) … the selected one or more blocks and related input data are transformed to an intermediate representation such as one or more hierarchical graphs, comprising a data flow graph, a control flow graph and/or a tree structure (i.e., unit data structure diagram)), comprises:
in response to the event configuration unit comprising a plurality of event configuration commands, parsing, for each of the plurality of event configuration commands, the command attribute value corresponding to the event configuration command to obtain a command data structure diagram corresponding to the event configuration command (paragraph [0048]: A block may describe an atomic operation, such as an arithmetic calculation or a logic expression …; paragraph [0054]: In a first step S1, the selected one or more blocks (or, if selected, the entire block diagram) and related input data are transformed to an intermediate representation such as one or more hierarchical graphs. These hierarchical graphs may in particular comprise a data flow graph …; Note: Under the Broadest Reasonable Interpretation, when Luenstroth parses a block that consists of only a single “atomic operation” (one event configuration command) and its related input data/parameters (command attribute values) to generate a hierarchical graph (data structure diagram), the graph representing that single operation inherently serves as the graph for that entire block (taking the command data structure diagram as the unit data structure diagram).; and
connecting a plurality of command data structure diagrams based on a logical relationship between the plurality of event configuration commands to obtain the unit data structure diagram corresponding to the event configuration unit. (paragraph [0048]: A block… may represent a subsystem or a submodel, which comprise a plurality of subordinate blocks that are shown in a lower hierarchical level… Multiple blocks may be connected by signals for the exchange of data… connected by a signal path so that data flows from the initial block to the further block; paragraph [0054]: In a first step S1, the selected one or more blocks… and related input data are transformed to an intermediate representation such as one or more hierarchical graphs. These hierarchical graphs may in particular comprise a data flow graph, a control flow graph and/or a tree structure; In other wores, a block (i.e., event interaction unit) can represent a subsystem containing multiple subordinate blocks or operations (i.e., plurality of event configuration commands). When transforming this subsystem, the system parses the individual subordinate blocks and their input data to generate intermediate graph representations, which are connected together based on signal paths and data flow (i.e., logical relationships) to form the overall hierarchical graph (unit data structure diagram) for that subsystem; Note: Under the Broadest Reasonable Interpretation, when Luenstroth parses a block that consists of only a single “atomic operation” (one event configuration command) and its related input data/parameters (command attribute values) to generate a hierarchical graph (data structure diagram), the graph representing that single operation inherently serves as the graph for that entire block (taking the command data structure diagram as the unit data structure diagram).
Regarding claims 4 and 5, Luenstroth discloses
wherein parsing the command attribute value corresponding to the event configuration command to obtain the command data structure diagram corresponding to the event configuration command (paragraph [0048]: A block may describe an atomic operation, such as an arithmetic calculation or a logic expression …; paragraph [0054]: In a first step S1, the selected one or more blocks (or, if selected, the entire block diagram) and related input data are transformed to an intermediate representation such as one or more hierarchical graphs. These hierarchical graphs may in particular comprise a data flow graph), comprises:
parsing the command attribute value corresponding to the event configuration command to obtain at least one command interaction event node corresponding to the event configuration command, and constructing the command data structure diagram corresponding to the event configuration command based on the command interaction event node (Paragraph [0054]: In a first step S1, the selected one or more blocks (or, if selected, the entire block diagram) and related input data are transformed to an intermediate representation such as one or more hierarchical graphs. These hierarchical graphs may in particular comprise a data flow graph, a control flow graph and/or a tree structure; In other words, the blocks (i.e., commands) and related input data (i.e., attributes) are transformed into hierarchical graphs, such as data flow graphs or tree structures. In computer science, graphs and tree structures are fundamentally constructed of nodes (i.e., vertices) and edges. Therefore, transforming an atomic operation into a graph representation inherently involves creating a node for that operation to construct the graph; Note: Under the Broadest Reasonable Interpretation, Luenstroth’s generation of a “data flow graph” or “tree structure” from a block and its input data inherently requires parsing that data to obtain a “node” (i.e., a standard element of any graph or tree) representing the operation, and constructing the graph (i.e., command data structure diagram) based on that node).
Regarding claims 6 and 15, Luenstroth discloses
wherein after acquiring the unit data structure diagram corresponding to the event interaction unit (paragraph [0054], [0059]: Upon activation of the simulation engine … the selected one or more blocks and related input data are transformed to an intermediate representation such as one or more hierarchical graphs, comprising a data flow graph, a control flow graph and/or a tree structure), the interaction event response method further comprises:
storing the command attribute value corresponding to the event configuration unit and the unit data structure diagram in a corresponding manner (paragraph [0054]: Related input data may e.g. be extracted from a database associated with the block diagram; paragraph [0055]: In a second step S2, the hierarchical graphs are optimized …; paragraph [0042]: The host computer PC comprises at least one processor CPU… a random access memory RAM… a non-volatile memory HDD…; In other words, the intermediate representations (i.e., hierarchical graphs) and their related input data/parameters are retained in memory so that they can be subsequently optimized and translated into code).
Regarding claims 8 and 17, Luenstroth discloses
wherein generating the module data structure diagram corresponding to the event interaction module based on the unit data structure diagram (paragraphs [0055]-[0056], [0061]: the hierarchical graphs are optimized (i.e., generating a module data structure diagram) … the optimized intermediate representations such as optimized hierarchical graphs are translated to code in a high-level or low-level programming language, preferably C code … The generated production code is then compiled to object code or an executable… a stimulus STIM is fed to the object code or executable OBJ, and the output signals are recorded), comprises:
determining that a command interaction event node of the unit data structure diagram comprises a key node of a target connection port, wherein the target connection port is a command output port and/or a command input port (paragraph [0013]: The block diagram may comprise multiple blocks with input and/or output signals that are connected to output and/or input signals of other blocks; paragraph [0016]: The one or more blocks … can have at least one input and at least one output, and the block diagram can comprise one or more second blocks, which are connected to the block diagram of the control program via corresponding outputs and inputs; paragraph [0060]: During each time step, the current value of the stimulus STIM is fed to the appropriate input ports of the block diagram; Note: Luenstroth teaches Identifying that a block (or its graph representation) contains specific interfaces for signal connections, specifically input ports and output ports); and
connecting the unit data structure diagram based on the key node and the target connection port of the key node to obtain a module data structure diagram corresponding to the event interaction module (paragraph [0013]: The block diagram may comprise multiple blocks with input and/or output signals that are connected to output and/or input signals of other blocks; paragraph [0016]: The one or more blocks … can have at least one input and at least one output, and the block diagram can comprise one or more second blocks, which are connected to the block diagram of the control program via corresponding outputs and inputs; paragraph [0060]: During each time step, the current value of the stimulus STIM is fed to the appropriate input ports of the block diagram; Note: the blocks (i.e., units) have specific input and output ports, and that the overall system graph (i.e., module data structure diagram) is formed by connecting these blocks via their corresponding input and output ports).
Regarding claims 9 and 18, Luenstroth discloses
wherein after displaying the event interaction module (paragraph [0048]: providing a graphical user interface for creating and modifying block diagrams (i.e., event interaction module) … The block diagram may comprise multiple blocks … A block may describe an atomic operation, such as an arithmetic calculation or a logic expression [event configuration command), the interaction event response method further comprises:
updating the event interaction module based on a unit editing triggering operation in response to the unit editing triggering operation for the event interaction unit, wherein the unit editing triggering operation comprises a unit adding triggering operation and/or a unit deleting triggering operation (paragraph [0048]: The modelling environment MOD may provide a graphical user interface for creating and modifying block diagrams… Multiple blocks may be connected by signals for the exchange of data; Note: Under the Broadest Reasonable Interpretation, providing a graphical user interface for “creating and modifying” a block diagram (i.e., event interaction module) that utilizes “multiple blocks” inherently reads on receiving user inputs to add new blocks (i.e., unit adding triggering operation) or remove existing blocks (i.e., unit deleting triggering operation) to update the overall diagram. “Modifying” a diagram made of multiple blocks fundamentally encompasses adding or deleting those constituent blocks).
Regarding claims 10 and 19, Luenstroth discloses
wherein the event interaction unit at least comprises an event triggering unit and an event execution unit (paragraph [0048]: Additionally, blocks adapted for describing finite states and conditions for transitions between states may be used to model the dynamic system; Notes: blocks (i.e., event interaction units) that model dynamic systems using finite states (i.e., event execution units) and conditions that trigger transitions between those states (i.e., event triggering units)), and the event execution unit comprises an event execution object command and an event execution behavior command (Paragraph [0048]: A block may describe an atomic operation, such as an arithmetic calculation or a logic expression … For example, an initial block may receive a signal of type single as input signal, may modify the signal (i.e., event execution object command) e.g. by adding a constant (i.e., event execution behavior command) … ).
Regarding claim 20, Luenstroth discloses A storage medium comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a computer processor (paragraph [0026]: One aspect of the invention also concerns a non-transitory computer readable medium containing instructions that, when executed by a microprocessor of a computer system, cause the computer system to carry out an inventive method as described above or in the appended claims), are configured to implement the interaction event response method according to claim 1 (See the rejection for claim 1).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Luenstroth in view of Leedekerken (US 2023/0289389, hereinafter Leedekerken).
Regarding claims 7 and 16, Luenstroth discloses
wherein acquiring the unit data structure diagram corresponding to the event interaction unit based on the command attribute value corresponding to each event configuration command in each event interaction unit in response to the event execution triggering operation for the event interaction module, comprises … (paragraph [0054], [0059]: Upon activation of the simulation engine (i.e., event execution triggering operation) … the selected one or more blocks and related input data are transformed to an intermediate representation such as one or more hierarchical graphs, comprising a data flow graph, a control flow graph and/or a tree structure (i.e., unit data structure diagram)),
… for each event interaction unit (paragraph [0048]: providing a graphical user interface for creating and modifying block diagrams … The block diagram may comprise multiple blocks (i.e., event interaction units) … A block may describe an atomic operation, such as an arithmetic calculation or a logic expression [event configuration command), in a preset storage space (paragraph [0042]: The host computer PC comprises at least one processor CPU… a random access memory RAM… a non-volatile memory HDD …) based on the command attribute value corresponding to each event configuration command in the event interaction unit (paragraph [0013], [0048]: indicating values of parameters of the technical environment via a user interface (i.e., attribute value configuration triggering operation) … an initial block may receive a signal of type single as input signal, may modify the signal e.g. by adding a constant (i.e., command attribute values)); and
acquiring the unit data structure diagram … (paragraph [0054], [0059]: Upon activation of the simulation engine (i.e., event execution triggering operation) … the selected one or more blocks and related input data are transformed to an intermediate representation such as one or more hierarchical graphs, comprising a data flow graph, a control flow graph and/or a tree structure (i.e., unit data structure diagram).
Luenstroth does not disclose querying the preset storage space based on the command attribute value and acquiring the unit data structure diagram from the preset storage space in response to a match with the command attribute value being queried. Leedekerken discloses querying the preset storage space based on the command attribute value and acquiring the unit data structure diagram from the preset storage space in response to a match with the command attribute value being queried (Paragraph [0089]: accepting, via a user interface, a selection of a query and one or more services … receiving, in response to the request, automation code for accessing the one or more services …; paragraph [0046]-[0047]: the script manager sends a request to retrieve the selected script from local automation code scripts 182 [preset storage space] or from an automation plugin manager 180; Note: a robotic process automation system that accepts a specific user query or selection (analogous to a command attribute value) and queries a storage space to retrieve corresponding automation code or scripts (analogous to the unit data structure diagram) that match the requested query/service). It would have been obvious to a person of ordinary skill in the art at the time of the invention to modify the code generation method of Luenstroth to include the query-and-retrieve mechanism taught by Leedekerken. The motivation would have been to automate the retrieval of appropriate code structures based on specific user queries, thereby reducing risk of human error and greatly accelerating speed (Leedekerken paragraph [0030]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Barday (US 2021/0264488) discloses “A computer-implemented data processing method is operable for generating a data flow diagram for a privacy campaign. The system is operable for displaying on a graphical user interface a prompt to create an electronic record for a privacy campaign, receiving a command to create an electronic record for the privacy campaign” (paragraph [0031]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
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, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 9/5/2026
Prosecution Insights