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 .
Claims 1-3, 5-13, and 15-22 are presented for examination.
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.
Claims 1-3, 5-10, 11-13, and 15-18 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding Claims 1 and 11, each claim recites “generate, based on the industrial control programming input, an executable control program file” (claim 1) and “generating, by the system based on the industrial control programming input” (claim 11). There is insufficient antecedent basis for “the industrial control programming input” in the claims, as each claim previously introduces only “industrial control code input.” It is unclear whether “the industrial control programming input” refers to the previously recited “industrial control code input” or to some other input. For purposes of applying art below, the Examiner interprets “the industrial control programming input” to refer to the previously recited “industrial control code input.” Claims 2-3, 5-10 (depending from claim 1) and 12-13, 15-18 (depending from claim 11) are rejected for the same reason by virtue of their dependency. Appropriate correction or clarification is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-13, and 15-22 are rejected under 35 U.S.C. 103 as being unpatentable over Stump (US 2021/0294279 A1) in view of Chen (US 2024/0020096 A1), further in view of Dunn (US 11,681,502 B2), and further in view of Dey (US 2020/0167134 A1).
Regarding Claim 1, Stump (US 2021/0294279 A1) teaches
A system comprising: a memory that stores executable components and one or more custom models; and a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render an integrated development environment (IDE) interface and to receive, via interaction with the IDE interface, industrial control code input that defines an industrial control program ([Para. 0046] “IDE system 202 can include a user interface component 204 including an IDE editor 224,”; [Para. 0047] “User interface component 204 can be configured to receive user input and to render output to the user in any suitable format (e.g., visual, audio, tactile, etc.). In some embodiments, user interface component 204 can be configured to communicatively interface with an IDE client that executes on a client device (e.g., a laptop computer, tablet computer, smart phone, etc.) that is communicatively connected to the IDE system 202 (e.g., via a hardwired or wireless connection). The user interface component 204 can then receive user input data and render output data via the IDE client”) Examiner Comments: Stump’s user interface renders an IDE and accepts control code input for defining industrial programs.
a project generation component configured to generate, based on the industrial control programming input, an executable control program file that, in response to execution on an industrial controller, causes the industrial controller to monitor and control an industrial automation system in accordance with the industrial control program ([Para. 0077] “Project deployment component 208 can compile or otherwise translate a completed system project 302 into one or more executable files or configuration files that can be stored and executed on respective target industrial devices of the automation system (e.g., industrial controllers 118, HMI terminals 114 or other types of visualization systems, motor drives 710, telemetry devices, vision systems, safety relays, etc.).”) Examiner Comments: Stump’s project generation creates executable files for controllers to monitor and control automation systems.
and the project generation component is further configured to integrate the control code into the industrial control program ([Para. 0068] “project generation component 206 can invoke selected code modules 508 stored in a code module database (e.g., on memory 220). These code modules 508 comprise standardized coding segments for controlling common industrial tasks or applications (e.g., palletizing, flow control, web tension control, pick-and-place applications, conveyor control, etc.).”) Examiner Comments: Stump’s component integrates code modules into the control project.
Stump did not specifically teach
wherein the user interface component is further configured to receive a natural language request for control code to be included in the industrial control program, wherein the natural language request specifies one or more requirements of the control code; the executable components further comprise a generative artificial intelligence (AI) component configured to, in response to receipt of the natural language request, formulate a prompt, directed to a generative AI model, designed to obtain a response from the generative AI model comprising information used by the generative AI component to generate control code inferred to satisfy the one or more requirements, wherein the prompt is generated based on analysis of the natural language request and industry knowledge encoded in the one or more custom models
wherein the prompt is generated based on analysis of the natural language request and industry knowledge encoded in the one or more custom models
wherein the user interface component is configured to: in response to receipt of a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, render an in-line chat window as an overlay at the location on the workspace canvas area, and receive the natural language request via interaction with the in-line chat window.
However, Chen (US 2024/0020096 A1) teaches
wherein the user interface component is further configured to receive a natural language request for control code to be included in the industrial control program, wherein the natural language request specifies one or more requirements of the control code ([Para. 0002] “generating computer code based on natural language input.”; [Claim 1] “receiving a docstring representing natural language text specifying a digital programming result.”) Examiner Comments: Chen’s system receives natural language docstrings specifying code requirements for generation.
the executable components further comprise a generative artificial intelligence (AI) component configured to, in response to receipt of the natural language request, formulate a prompt, directed to a generative AI model, designed to obtain a response from the generative AI model comprising information used by the generative AI component to generate control code inferred to satisfy the one or more requirements ([Abstract] “generating, using a trained machine learning model, and based on the docstring, a computer code sample configured to produce respective candidate results.”) Examiner Comments: Chen’s trained machine learning model responds to a natural language docstring by formulating and generating code inferred to satisfy the specified result.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump’s teaching into Chen’s in order to include receiving natural language requests and using generative AI to generate control code, thereby improving programming efficiency by allowing developers to specify requirements in natural language and reducing manual coding effort in industrial IDEs (Chen [Summary]).
Stump and Chen did not specifically teach
wherein the prompt is generated based on analysis of the natural language request and industry knowledge encoded in the one or more custom models
wherein the user interface component is configured to: in response to receipt of a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, render an in-line chat window as an overlay at the location on the workspace canvas area, and receive the natural language request via interaction with the in-line chat window.
However, Dunn (US 11,681,502 B2) teaches
wherein the prompt is generated based on analysis of the natural language request and industry knowledge encoded in the one or more custom models ([Col. 23, Lines 35-59] “the DSL definition data can specify, for example, a syntax of the industrial DSL, definitions of automation objects that can be called within the industrial DSL (e.g., automation objects representing industrial assets such as machines, processes, controllers, drives, control programs, controller tags, etc.), parent-child relationships between the automation objects, namespaces, mapping of programming nomenclature, programming guardrails, code modules for frequently programmed control tasks or applications (e.g., pumping applications, conveyor control applications, web tension control applications, etc.), or other such aspects of the industrial DSL.”) Examiner Comments: Dunn encodes industry knowledge in custom models, such as code modules and standards, for generating control code.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump and Chen’s teaching into Dunn’s in order to encode industry knowledge in custom models for prompt generation, thereby ensuring generated code adheres to industry-specific standards and best practices and improving safety and efficiency in industrial control programming, where the industrial DSL can be a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Stump, Chen, and Dunn did not specifically teach
wherein the user interface component is configured to: in response to receipt of a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, render an in-line chat window as an overlay at the location on the workspace canvas area, and receive the natural language request via interaction with the in-line chat window.
However, Dey (US 2020/0167134 A1) teaches
wherein the user interface component is configured to: in response to receipt of a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, render an in-line chat window as an overlay at the location on the workspace canvas area, and receive the natural language request via interaction with the in-line chat window ([Para. 0005] “generating, in a graphical user interface of the automated dialog system, a natural language dialog conversation associated with the one or more actions taken in the programming environment, presenting, in the graphical user interface, a given user-activatable interface feature associated with a given portion of the natural language dialog conversation, the given portion of the natural language dialog conversation comprising a suggested additional action for modifying at least one aspect of the programming environment”) Examiner Comments: Dey’s natural language interface renders as an overlay window in the IDE for receiving queries and is associated with actions taken at a location in the displayed programming environment.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 2, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Dunn further teaches, wherein the generative AI component is further configured to perform contextual analysis on the industrial control program to determine at least one of a type of industrial application or an industrial vertical for which the industrial control program is being developed, and to generate the control code inferred to satisfy the one or more requirements based on a result of the contextual analysis ([Col. 23, Lines 1-16] “Example suggestions can include, for example, suggested automation objects to be added to the project based on an inference of the programmer's intentions (e.g., recommending addition of a pump automation object at an appropriate location in the program if the developer is scripting a flow control application), auto-completing sections of code by adding predefined vertical-specific or application-specific code modules for common control operations.”) Examiner Comments: Dunn performs contextual analysis to infer the application type or vertical and generates/adds code accordingly.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump and Chen’s teaching into Dunn’s in order to encode industry knowledge in custom models for prompt generation, thereby ensuring generated code adheres to industry-specific standards and best practices and improving safety and efficiency in industrial control programming, where the industrial DSL can be a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Regarding Claim 3, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Dunn further teaches wherein the industry knowledge encoded in the one or more custom models comprises at least one of libraries of control code instructions, libraries of add-on instructions, libraries of control code samples, libraries of user defined data types (UDTs), libraries of product manuals for industrial devices or software platforms, specification data for industrial devices, training data, information defining industrial standards, design standards for respective different types of industrial control applications, design standards for respective different industrial verticals, knowledge of industrial best practices, control design rules, or industrial domain-specific language (DSL) syntax data ([Col. 23, Lines 35-59] “the DSL definition data can specify, for example, a syntax of the industrial DSL, definitions of automation objects that can be called within the industrial DSL (e.g., automation objects representing industrial assets such as machines, processes, controllers, drives, control programs, controller tags, etc.), parent-child relationships between the automation objects, namespaces, mapping of programming nomenclature, programming guardrails, code modules for frequently programmed control tasks or applications (e.g., pumping applications, conveyor control applications, web tension control applications, etc.), or other such aspects of the industrial DSL.”) Examiner Comments: Dunn encodes libraries of code modules, standards, and design data for applications and verticals in the DSL custom models.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump and Chen’s teaching into Dunn’s in order to encode industry knowledge in custom models for prompt generation, thereby ensuring generated code adheres to industry-specific standards and best practices and improving safety and efficiency in industrial control programming, where the industrial DSL can be a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Regarding Claim 5, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Dey further teaches wherein the project generation component is configured to add the control code inferred to satisfy the one or more requirements at a location within the industrial control program determined based on the location on the workspace canvas at which the user interaction was received ([Para. 0048] “the dialog pane 280 may present an actionable suggestion, such as a code snippet for insertion into the selected code file in the code editing pane 206, which the programmer may accept or reject using the augmentation action selection features 284. As another example, the actionable suggestions may be presented directly in the code editing pane 206 (e.g., showing a highlighted code snippet in the code editing pane 206 in line with the existing code of the selected code file).”) Examiner Comments: Dey inserts the suggested code snippet at a location within the code in line with the existing code of the selected code file on which the user is operating.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 6, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Dey further teaches wherein the location on the workspace canvas area corresponds with an element of the industrial control program, and the generative AI component is configured to generate the control code inferred to satisfy the one or more requirements based on analysis of the natural language request using the control code element as a parameter of the natural language request ([Para. 0053] “analyzing a plurality of elements in the programming environment to determine the intent. Such elements may include various program constructs, including but not limited to comments in the code, code inputs, code outputs, code objectives, file names, project or workspace names, function names, function parameter names, variable names, etc.”; [Para. 0030] “the proactive chat generation module 108 monitors the programmer's actions in the IDE in order to provide responses and queries to the programmer that are useful based on the context of the programmer's actions”) Examiner Comments: Dey analyzes code elements (e.g., functions, parameters) as context/parameters for generating suggestions responsive to the natural language input.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 7, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Chen further teaches wherein the natural language request specifies at least one of a control function to be performed by the control code, a type of equipment to be controlled by the control code, a description of control conditions for controlling a state of an output device, or a format for the control code ([Claim 1] “receiving a docstring representing natural language text specifying a digital programming result.”; [Para. 0002] “generating computer code based on natural language input.”) Examiner Comments: Chen’s natural language docstrings specify the programming result, including functions and conditions for the code.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump’s teaching into Chen’s in order to include receiving natural language requests and using generative AI to generate control code, thereby improving programming efficiency by allowing developers to specify requirements in natural language and reducing manual coding effort in industrial IDEs (Chen [Summary]).
Regarding Claim 8, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Dey further teaches wherein the generative AI component is further configured to generate natural language documentation for the control code and to embed the natural language documentation into the control code, and the generative AI component generates the natural language documentation based on responses prompted from the generative AI model by the generative AI component ([Para. 0055] “The core response may include a snippet extracted from an external document, the snippet comprising at least one of a web quote, a library documentation snippet, a code snippet, a programming practice manual snippet, and an integrated development environment documentation snippet.”) Examiner Comments: Dey generates and includes documentation snippets in its responses, which are embeddable into the code context.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 9, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Stump further teaches wherein the generative AI component is configured to generate the control code as at least one of ladder logic, structured text, a function block diagram, or an industrial domain-specific language (DSL) ([Para. 0096] “IDE system 202 includes a conversion component 212 configured to receive legacy control project data 1102 submitted by a developer (e.g., a ladder logic program file, a structured text program file, a function block diagram program file, a sequential function chart file, etc.).”) Examiner Comments: Stump generates/handles control code in formats including ladder logic, structured text, and function block diagrams.
Regarding Claim 10, Stump, Chen, Dunn, and Dey teach
The system of Claim 1.
Dey further teaches wherein the generative AI component is further configured to generate natural language implementation details relating to the control code based on the analysis of the natural language request and responses prompted from the generative AI model, and the user interface component is configured to render the control code and the natural language implementation details on the IDE interface ([Para. 0004] “generating a natural language dialog in a graphical user interface of an automated dialog system associated with the programming environment, the natural language dialog comprising one or more suggested additional actions to be taken in the programming environment based at least in part on the determined intent, wherein the one or more suggested additional actions comprise one or more actions that affect code of one or more code files in the programming environment.”) Examiner Comments: Dey generates and renders natural language explanations/details together with code in the IDE.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 11, is a method claim corresponding to the system claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1, including the rendering of an in-line chat window as an overlay at the location on the workspace canvas area as taught by Dey.
Regarding Claim 12, is a method claim corresponding to the system claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Regarding Claim 13, is a method claim corresponding to the system claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Regarding Claim 15, is a method claim corresponding to the system claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 16, is a method claim corresponding to the system claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Regarding Claim 17, is a method claim corresponding to the system claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Regarding Claim 18, is a method claim corresponding to the system claim above (Claim 8) and, therefore, is rejected for the same reasons set forth in the rejection of claim 8.
Regarding Claim 19, Stump (US 2021/0294279 A1) teaches
A non-transitory computer-readable medium having stored thereon instructions that, in response to execution, cause an industrial integrated development environment (IDE) system comprising a processor to perform operations, the operations comprising:
receiving, via interaction with an integrated development environment (IDE) interface, industrial control code input that defines an industrial control program ([Para. 0047] “User interface component 204 can be configured to receive user input and to render output to the user in any suitable format (e.g., visual, audio, tactile, etc.). In some embodiments, user interface component 204 can be configured to communicatively interface with an IDE client that executes on a client device (e.g., a laptop computer, tablet computer, smart phone, etc.) that is communicatively connected to the IDE system 202”; [Para. 0113] “at 1302, an industrial control program file is received at the industrial IDE system. The program file may be, for example, a ladder logic program file, a sequential function chart program file, a function block diagram program file, a structured text program file, or a control program file of another format.”) Examiner Comments: Stump receives industrial control code input via the IDE interface to define the control program.
integrating the control code into the industrial control program ([Para. 0068] “In making coding suggestions as part of design feedback 518, project generation component 206 can invoke selected code modules 508 stored in a code module database (e.g., on memory 220). These code modules 508 comprise standardized coding segments for controlling common industrial tasks or applications (e.g., palletizing, flow control, web tension control, pick-and-place applications, conveyor control, etc.).”) Examiner Comments: Stump integrates control code into the industrial control program using the project generation component.
generating an executable control program file that, in response to execution on an industrial controller, causes the industrial controller to monitor and control an industrial automation system in accordance with the industrial control program ([Para. 0077] “Project deployment component 208 can compile or otherwise translate a completed system project 302 into one or more executable files or configuration files that can be stored and executed on respective target industrial devices of the automation system (e.g., industrial controllers 118, HMI terminals 114 or other types of visualization systems, motor drives 710, telemetry devices, vision systems, safety relays, etc.).”) Examiner Comments: Stump generates executable files that run on controllers to monitor and control automation systems.
Stump did not specifically teach
receiving, via interaction with the in-line chat window, a natural language request for control code to be included in the industrial control program, wherein the natural language request specifies one or more requirements of the control code; in response to the receiving of the natural language request, formulating a prompt designed to obtain a response from the generative AI model comprising information used by the industrial IDE system to generate control code inferred to satisfy the one or more requirements, wherein the formulating comprises generating the prompt based on analysis of the natural language request and industrial training data encoded in the one or more custom models; generating the control code inferred to satisfy the one or more requirements based on the response prompted from the generative AI model; and, in response to receiving a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, rendering an in-line chat window as an overlay at the location on the workspace canvas area.
However, Chen (US 2024/0020096 A1) teaches
receiving, via interaction with the in-line chat window, a natural language request for control code to be included in the industrial control program, wherein the natural language request specifies one or more requirements of the control code ([Para. 0002] “Disclosed herein are methods, systems, and computer-readable media for generating computer code based on natural language input.”; [Para. 0005] “receiving a docstring representing natural language text specifying a digital programming result;”) Examiner Comments: Chen receives natural language docstrings specifying the requirements for code to be generated and included in programs.
in response to the receiving of the natural language request, formulating a prompt designed to obtain a response from the generative AI model comprising information used by the industrial IDE system to generate control code inferred to satisfy the one or more requirements ([Abstract] “generating, using a trained machine learning model, and based on the docstring, a computer code sample configured to produce respective candidate results.”; [Para. 0019] “the docstring generation model may further be trained using the outputted at least one identified docstring in association with the at least a portion of the one or more computer code samples”) Examiner Comments: Chen’s trained machine learning model formulates responses to natural language prompts and analyzes them to generate code satisfying the specified requirements.
generating the control code inferred to satisfy the one or more requirements based on the response prompted from the generative AI model ([Para. 0002] “Disclosed herein are methods, systems, and computer-readable media for generating computer code based on natural language input.”; [Para. 0005] “receiving a docstring representing natural language text specifying a digital programming result.”) Examiner Comments: Chen generates the code inferred to satisfy the requirements based on the machine learning model’s response to the natural language input.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump’s teaching into Chen’s in order to include receiving natural language requests and using generative AI to generate control code, thereby improving programming efficiency by allowing developers to specify requirements in natural language and reducing manual coding effort in industrial IDEs (Chen [Summary]).
Stump and Chen did not specifically teach
wherein the formulating comprises generating the prompt based on analysis of the natural language request and industrial training data encoded in the one or more custom models.
However, Dunn (US 11,681,502 B2) teaches
wherein the formulating comprises generating the prompt based on analysis of the natural language request and industrial training data encoded in the one or more custom models ([Col. 23, Lines 35-59] “the DSL definition data can specify, for example, a syntax of the industrial DSL, definitions of automation objects that can be called within the industrial DSL (e.g., automation objects representing industrial assets such as machines, processes, controllers, drives, control programs, controller tags, etc.), parent-child relationships between the automation objects, namespaces, mapping of programming nomenclature, programming guardrails, code modules for frequently programmed control tasks or applications (e.g., pumping applications, conveyor control applications, web tension control applications, etc.), or other such aspects of the industrial DSL.”) Examiner Comments: Dunn’s DSL encodes industrial training data in custom models for generating control code based on analysis of the input.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump and Chen’s teaching into Dunn’s in order to encode industry knowledge in custom models for prompt generation, thereby ensuring generated code adheres to industry-specific standards and best practices and improving safety and efficiency in industrial control programming, where the industrial DSL can be a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Stump, Chen, and Dunn did not specifically teach
in response to receiving a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, rendering an in-line chat window as an overlay at the location on the workspace canvas area.
However, Dey (US 2020/0167134 A1) teaches
in response to receiving a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, rendering an in-line chat window as an overlay at the location on the workspace canvas area ([Para. 0005] “generating, in a graphical user interface of the automated dialog system, a natural language dialog conversation associated with the one or more actions taken in the programming environment, presenting, in the graphical user interface, a given user-activatable interface feature associated with a given portion of the natural language dialog conversation, the given portion of the natural language dialog conversation comprising a suggested additional action for modifying at least one aspect of the programming environment”) Examiner Comments: Dey’s natural language interface renders as an overlay window in the IDE for receiving queries and is associated with actions taken at a location in the displayed programming environment.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 20, Stump, Chen, Dunn, and Dey teach
The non-transitory computer-readable medium of Claim 19.
Dunn further teaches wherein the generating of the control code comprises: performing contextual analysis on the industrial control program to determine at least one of a type of industrial application or an industrial vertical for which the industrial control program is being developed, and generating the control code inferred to satisfy the one or more requirements based on a result of the contextual analysis ([Col. 23, Lines 1-16] “Example suggestions can include, for example, suggested automation objects to be added to the project based on an inference of the programmer's intentions (e.g., recommending addition of a pump automation object at an appropriate location in the program if the developer is scripting a flow control application), auto-completing sections of code by adding predefined vertical-specific or application-specific code modules for common control operations.”) Examiner Comments: Dunn performs contextual analysis to infer the application type or vertical and generates code accordingly.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the references for the same reasons set forth with respect to claims 1 and 2 (Dunn [Summary]).
Regarding Claim 21, Stump, Chen, Dunn, and Dey teach
The non-transitory computer-readable medium of Claim 19.
Dey further teaches wherein the integrating comprises adding the control code inferred to satisfy the one or more requirements at a location within the industrial control program determined based on the location on the workspace canvas area at which the user interaction was received ([Para. 0048] “the actionable suggestions may be presented directly in the code editing pane 206 (e.g., showing a highlighted code snippet in the code editing pane 206 in line with the existing code of the selected code file).”) Examiner Comments: Dey inserts the generated code snippet in line with the existing code of the selected code file on which the user is operating.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Regarding Claim 22, Stump, Chen, Dunn, and Dey teach
The non-transitory computer-readable medium of Claim 19.
Dunn further teaches wherein the industrial training data encoded in the one or more custom models comprises at least one of libraries of control code instructions, libraries of add-on instructions, libraries of control code samples, libraries of user-defined data types (UDTs), libraries of product manuals for industrial devices or software platforms, specification data for industrial devices, information defining industrial standards, design standards for respective different types of industrial control applications, design standards for respective different industrial verticals, knowledge of industrial best practices, control design rules, or industrial domain-specific language (DSL) syntax data ([Col. 23, Lines 35-59] “the DSL definition data can specify, for example, a syntax of the industrial DSL, definitions of automation objects that can be called within the industrial DSL (e.g., automation objects representing industrial assets such as machines, processes, controllers, drives, control programs, controller tags, etc.), parent-child relationships between the automation objects, namespaces, mapping of programming nomenclature, programming guardrails, code modules for frequently programmed control tasks or applications (e.g., pumping applications, conveyor control applications, web tension control applications, etc.), or other such aspects of the industrial DSL.”) Examiner Comments: Dunn encodes libraries of code modules, standards, and design data for applications and verticals in the custom models.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stump, Chen and Dunn’s teaching into Dey’s in order to provide in-line overlay chat for seamless natural language interaction in the IDE workspace by monitoring actions taken in the programming environment, determining intent of the actions taken, and generating a natural language dialog in a graphical user interface of the automated dialog system (Dey [Abstract]).
Response to Arguments
Applicant argues “Stump et al. does not indicate that, in response to receipt of a user interaction at a location on a workspace canvas area of the IDE interface in which the industrial control program is being displayed, an in-line chat window is rendered as an overlay at the location on the workspace canvas area at which the user interaction was received, as recited in independent claim 1 as amended”.
Examiner respectfully disagrees. The present rejection does not rely on Stump (or Chen or Dunn) for this limitation, and Applicant’s observation that Stump, Chen, and Dunn are individually silent regarding it is therefore not probative. The argued limitation corresponds to the subject matter of canceled claim 4, which stood rejected in the Non-Final Office action over Stump in view of Chen, further in view of Dunn, and further in view of Dey, with Dey supplying the rendering of an in-line chat window as an overlay in the IDE workspace. By the present amendment, Applicant has incorporated the subject matter of claim 4 into independent claims 1, 11, and 19; accordingly, the same Dey-based rejection of record applies to the independent claims as amended, as set forth above. Nonobviousness cannot be shown by attacking references individually where the rejection is based on a combination of references. See In re Keller, 642 F.2d 413 (CCPA 1981); In re Merck & Co., 800 F.2d 1091 (Fed. Cir. 1986).
Applicant argues “as illustrated in FIG. 2, Dey et al.’s dialog pane 280 and associated input field pane 282 (alleged to correspond to the in-line chat window of independent claim 1) are fixed to the right-hand side of the code editing pane 206, and there is no indication in Dey et al. that an in-line chat window is rendered as an overlay in the workspace canvas area (the area in which the program is being displayed, such as the code editing pane of Dey et al.’s system). More specifically, Dey et al. does not indicate that such an overlayed in-line chat window is rendered in response to receiving a user interaction at a location on the workspace canvas area in which the industrial control program is being displayed, or that the in-line chat window that is rendered in response to this user interaction is rendered at the location on the workspace canvas area at which the user interaction was received”.
Examiner respectfully disagrees. Applicant’s argument is directed to a single embodiment of Dey, the dialog pane 280 illustrated in FIG. 2, and does not address the full scope of Dey’s disclosure. Dey is not limited to a dialog pane fixed at the periphery of the code editing pane. Dey expressly teaches that its augmentation/dialog interface features may instead be presented within the code editing pane 206 itself (i.e., within the area in which the program is displayed (the workspace canvas area), stating that the actionable suggestions “may be presented directly in the code editing pane 206 (e.g., showing a highlighted code snippet in the code editing pane 206 in line with the existing code of the selected code file),” and that “the augmentation action selection features 284 may be presented in the code editing pane 206, such as via buttons or other user-activatable interface features that are overlayed over a potential actionable suggestion (e.g., a highlighted code snippet inserted into the code field of the code editing pane 206)” (Dey [0048]). Dey thus discloses rendering its interface as an overlay at a location within the workspace canvas area corresponding to the code being acted upon, rather than only at a fixed peripheral location. Dey further generates the natural language dialog in response to, and based on, the user’s actions and the program elements the user is operating upon in the programming environment (Dey [0005], [0030], [0053]) that is, in response to a user interaction at a location in the displayed program. Under the broadest reasonable interpretation, the claimed “in-line chat window … rendered as an overlay at the location on the workspace canvas area” reads on Dey’s overlaid, in-pane interface. A reference must be evaluated for all that it teaches, including non-preferred embodiments, and patentability is not established by attacking a single embodiment while ignoring the reference’s broader express disclosure. Moreover, the argued distinctions concerning the particular manner of invoking the chat window are not commensurate in scope with the claims, which do not recite any specific invocation mechanism (e.g., a right-click selection) and do not preclude Dey’s overlay presentation.
Applicant argues “Dey et al. does not indicate that the location of these actionable suggestions in the code editing pane is determined based on a location on the code editing pane at which a user interaction that caused an in-line chat window to be rendered was received, as recited in amended claim 5 (and amended independent claim 1, from which claim 5 depends)”.
Examiner respectfully disagrees. As discussed above, Dey presents the actionable suggestion/code snippet “in line with the existing code of the selected code file” and overlaid within the code editing pane (Dey [0048]). i.e., at a location determined by the selected code file/element on which the user is operating. Dey further determines the intent and content of its suggestions by “analyzing a plurality of elements in the programming environment,” including the code inputs, outputs, function names, and parameters the user is acting upon (Dey [0053]), and by monitoring the programmer’s actions in the IDE (Dey [0030]). Accordingly, the location at which Dey adds the suggested code is determined based on the location/selected element on the workspace canvas with which the user interacted, as claimed. Applicant’s assertion that the location is “decided solely by” Dey’s actionable suggestion generation module is speculative and is not commensurate with Dey’s express teaching that suggestions are inserted in line with the existing code of the selected code file. The rejection of claim 5 is therefore maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights