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-20 are presented for examination.
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, 7, 9, 11-13, 17 and 19-20 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).
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”;[Para. 0043] " the IDE system can apply analytics (e.g., artificial intelligence, machine learning, etc.) to project data submitted by developers across multiple industrial enterprises to identify commonly used control code, visualizations, device configurations.") 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.)."; [Para. 0096] " FIG. 11 is a diagram illustrating submission of a legacy control project 1102 to the IDE system 202 for conversion into an object-based system project 302. In this embodiment, 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.) and convert the legacy control project data 1102 to a system project 302 having one or more of the project features described above. This allows existing control projects to be migrated to the platform supported by IDE system 202.") Examiner Comments: Stump's project generation creates executable files for controllers to control automation systems.
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.
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,([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 ML model (generative AI) responds to natural language by generating code, involving prompt-based training.
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 ([Para. 0002] "generating computer code based on natural language input."; [Claim 1] "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 model analyzes natural language to generate code satisfying specified results.
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 by improve programming efficiency by allowing developers to specify requirements in natural language, reducing manual coding effort in industrial IDEs (Chen [Summary]).
Stump and Chen did not specifically teach
and industry knowledge encoded in the one or more custom models.
However, Dunn (US 11,681,502 B2) teaches
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, and) ([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 industry knowledge in custom models like 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 include industry knowledge in custom models for prompt generation by ensuring generated code adheres to industry-specific standards and best practices, improving safety and efficiency in industrial control programming where industrial DSL can be, for example, a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Regarding Claim 2, Stump, Chen and Dunn 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 application type or vertical and suggests or 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 include industry knowledge in custom models for prompt generation by ensuring generated code adheres to industry-specific standards and best practices, improving safety and efficiency in industrial control programming where industrial DSL can be, for example, 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 and Dunn 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 for applications and verticals in the DSL 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 include industry knowledge in custom models for prompt generation by ensuring generated code adheres to industry-specific standards and best practices, improving safety and efficiency in industrial control programming where industrial DSL can be, for example, a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Regarding Claim 7, Stump, Chen and Dunn 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 programming results, including functions and conditions for 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 by improve programming efficiency by allowing developers to specify requirements in natural language, reducing manual coding effort in industrial IDEs (Chen [Summary]).
Regarding Claim 9, Stump, Chen and Dunn 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 control code in formats like ladder logic and sequential function charts.
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.
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 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 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 (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. In other embodiments, user interface component 314 can be configured to generate and serve suitable interface screens to a client device (e.g., program development screens), and exchange data via these interface screens."; [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.). In some embodiments, code modules 508 can be categorized according to one or more of an industrial vertical (e.g., automotive, food and drug, oil and gas, textiles, marine, pharmaceutical, etc.), an industrial application, or a type of machine or device to which the code module 508 is applicable") 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. 0048] " Analysis of these multiple sets of project data trains the project generation component 206 to accurately convert design input submitted by the user to suitable control code, visualizations, device configurations, etc."; [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 IDE interface, 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.
However, Chen (US 2024/0020096 A1) teaches
receiving, via interaction with the IDE interface, 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 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, 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; ([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 ML model formulates responses to natural language prompts, using analysis to generate code satisfying 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 code inferred to satisfy requirements based on ML model responses to natural language.
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 by improve programming efficiency by allowing developers to specify requirements in natural language, 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 uses encoded industrial training data in custom models for generating control code based on input analysis.
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 include industry knowledge in custom models for prompt generation by ensuring generated code adheres to industry-specific standards and best practices, improving safety and efficiency in industrial control programming where industrial DSL can be, for example, a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Regarding Claim 20, Stump, Chen and Dunn 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 determine application type or vertical and generates code based on that inference.
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 include industry knowledge in custom models for prompt generation by ensuring generated code adheres to industry-specific standards and best practices, improving safety and efficiency in industrial control programming where industrial DSL can be, for example, a scripted language that supports creation of automation objects having relationships defined by an automation object namespace hierarchy (Dunn [Summary]).
Claims 4-6, 8, 10, 14-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Stump in view of Chen further in view of Dunn and Dey (US 2020/0167134 A1).
Regarding Claim 4, Stump, Chen and Dunn teach
The system of Claim 1.
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 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 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.
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 5, Stump, Chen, Dunn and Dey teach
The system of Claim 4.
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). The augmentation action selection features 284 may be presented in the dialog pane 280, allowing the programmer to accept or reject the possible insertion while viewing how such change will affect the code file by viewing the change in real time in the code editing pane 206 ") Examiner Comments: Dey inserts suggested code at specific locations in the program based on context and user acceptance.
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 4.
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. This may involve finding the “intent” of the programmer based on the programmer's actions. Although described primarily in the context of the proactive mode of operation, it should be appreciated that determining the programmer's intent may also be useful in the reactive mode of operation, and thus the reactive chat generation module 106 may similarly determine the programmer's intent to provide more relevant responses to explicit user queries 110 that are based on the context of the programmer's actions in the IDE in addition to the content of the explicit user queries 110.") Examiner Comments: Dey analyzes code elements (e.g., functions, parameters) as context/parameters for generating suggestions from natural language.
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 8, Stump, Chen, and Dunn teach The system of Claim 1.
Stump, Chen and Dunn did not specifically teach
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.
However, Dey 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 responses, embeddable into code contexts.
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 10, Stump, Chen, and Dunn teach
The system of Claim 1.
Stump, Chen and Dunn did not specifically teach
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.
However, Dey 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."; [Para. 0021] " The suggestions and responses may be “actionable” directly from within the interface of the chatbot or other automated dialog system, meaning that the programmer or other user is able to click or otherwise select suggestions made by the chatbot to initiate an action (e.g., a code import event, adding a classpath, adding a library or version of a library, monitoring and updating the code for runtime exceptions, etc.) that is taken in the code IDE. Such actions may be implemented through a hook or other application programming interface (API) that the IDE exposes to the integrated chatbot for publishing in the event of user selection of one or more of the suggestions “) Examiner Comments: Dey generates and renders natural language explanations/details 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 14, is a method claim corresponding to the system claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
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 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.
Conclusion
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