DETAILED ACTION
This action is responsive to the application filed on 05/14/2024. Claims 1-20 are pending and have been examined. This action is Non-final.
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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C.
120, 121, 365(c), or 386(c) is acknowledged.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 1,
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
Step 2A Prong 1:
(a) “applying at least a portion of the information characterizing the selected software development project …, wherein the at least one trained generative AI model predicts at least a portion of a software deployment pipeline associated with the selected software development project” - The limitation is directed to evaluating information describing a software-development project and determining or formulating appropriate software-deployment-pipeline content for the project. The limitation therefore recites observations, evaluations, and judgments, with aid of pen and paper, and thus the limitation is directed to a mental process.
Step 2A Prong 2 and Step 2B:
(a) “obtaining at least one trained generative artificial intelligence (AI) model” - This limitation merely provides the computer tool used to carry out the abstract evaluation. The trained model is recited at a high level of generality without a particular model architecture, parameter arrangement, attention mechanism, training algorithm, loss function, or other technical implementation that improves the operation of the model. The limitation therefore amounts to an instruction to apply the judicial exception using a generic computer tool and does not integrate the exception into a practical application. (see MPEP 2106.05(f)).
(b) “wherein the at least one trained generative AI model is trained using a plurality of CI/CD configuration files” - This limitation identifies the subject matter of the training data used to prepare the model. Merely limiting generic model training to CI/CD configuration files does not improve the model, computer, or CI/CD technology and amounts to limiting the abstract idea to a particular field of use, and thus it does not integrate to a practical application, nor provide significantly more than the judicial exception (see MPEP 2106.05(h)).
(c) “obtaining information characterizing a selected software development project” - This limitation is directed to gathering the information that will be evaluated to formulate the deployment-pipeline content. The claim does not recite a particular technical procedure for obtaining the information. The limitation constitutes insignificant pre-solution data-gathering activity and cannot integrate the exception into a practical application nor provide significantly more than the exception. (see MPEP 2106.05(g)) and 2106.05(d)).
(d) “as one or more system prompts to the at least one trained generative AI model” - This limitation merely specifies the manner in which information is supplied to the generally recited generative-AI model. The claim does not recite an improved prompt structure, inference mechanism, tokenizer, or model-input architecture. It amounts to using the computer tool according to its ordinary function and does not integrate to a practical application, nor provide significantly more than the judicial exception. (see MPEP 2106.05(f)).
(e) “wherein the method is performed by at least one processing device comprising a processor coupled to a memory” - The processing device, processor, and memory are generic computer components recited at a high level of generality. The components merely provide the environment in which the abstract evaluation is carried out. The Specification broadly describes the processor as any microprocessor, microcontroller, ASIC, FPGA, or other processing circuitry and the memory as RAM, ROM, or other memory. Mere instructions to implement an abstract idea using generic computer components do not integrate the exception into a practical application nor provide significantly more than the judicial exception. (see 2106.05(f)).
Thus, claim 1 is non-patent eligible. Claims 9 and 15 are analogous to claim 1 and thus face the same rejection above.
Regarding claim 2,
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
There are no elements to be evaluated under Step 2A Prong 1.
Step 2A Prong 2 and Step 2B:
(a) “The method, of claim 1, wherein the plurality of CI/CD configuration files are associated with an organization associated with the selected software development project” - This limitation merely restricts the source of the training data to configuration files associated with a particular organization. Limiting the information supplied to or used by a generic computer process according to its source or content does not improve computer technology or AI-model functionality. The limitation constitutes a field-of-use and data-source restriction and does not integrate the exception into a practical application. See MPEP §§ 2106.05(g) and 2106.05(h).
Thus, claim 2 is non-patent eligible. Claims 10 and 16 are analogous to claim 2 and thus face the same rejection above.
Regarding claim 3,
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
There are no elements to be evaluated under Step 2A Prong 1.
Step 2A Prong 2 and Step 2B:
(a) “The method of claim 1, wherein a training of the at least one trained generative AI model updates at least one pre-trained generative AI model to learn a syntax associated with the plurality of CI/CD configuration files.” - This limitation generally recites updating or fine-tuning a pre-trained model without specifying how the update is technically performed. The claim does not recite a particular model architecture, parameter-update rule, training objective, loss function, memory configuration, or other model-level mechanism that improves how the model operates. The limitation merely prepares the generic AI tool to perform the abstract evaluation and does not integrate the exception into a practical application, nor provide significantly more than the judicial exception (see MPEP 2106.05(g)) and (2106.05(d)(I)).
Thus, claim 3 is non-patent eligible. Claims 11 and 17 are analogous to claim 3 and thus face the same rejection above.
Regarding claim 4,
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
Step 2A Prong 1:
(a) “The method of claim 1, wherein the predicted portion of the software deployment pipeline associated with the selected software development project comprises one or more pipeline jobs in one or more pipeline stages in the software deployment pipeline associated with the selected software development project” — This limitation is directed to determining the tasks or jobs appropriate for a software project and organizing those jobs into deployment stages. A software developer or DevOps professional can evaluate project requirements and determine an appropriate organization and sequence of deployment jobs mentally or with written materials. The limitation therefore recites evaluations and judgment, and thus the limitation is directed to a mental process.
There are no elements to be evaluated under Step 2A Prong 2 and Step 2B.
Thus, claim 4 is non-patent eligible. Claims 12 and 18 are analogous to claim 4 and thus face the same rejection above.
Regarding claim 5,
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
Step 2A Prong 1:
(a) “in response to the at least one user selecting the selected software development project from the plurality of software development projects, the at least one trained generative AI model predicts the one or more pipeline jobs in the one or more pipeline stages in the software deployment pipeline” - This limitation is directed to evaluating a selected project and determining the deployment jobs and stages appropriate for that project. Reviewing a selected project and determining appropriate deployment tasks constitute evaluations and judgments that can practically be performed by a software developer or DevOps professional. The limitation recites a mental process.
Step 2A Prong 2 and Step 2B:
“wherein a graphical user interface of an integrated development environment presents a plurality of software development projects to at least one user” - The graphical user interface and integrated development environment merely present available projects and provide the technological environment in which the abstract evaluation is initiated. The claim does not recite a particular GUI structure, display technique, IDE architecture, or user-interface improvement. The limitation amounts to mere instructions to apply the abstract idea in a generic computer environment, and does not integrate to a practical application, nor provide significantly more than the judicial exception (see MPEP 2106.05(h)).
Thus, claim 5 is non-patent eligible. Claims 12 and 18 are analogous to claim 5 and thus face the same rejection above.
Regarding claim 6
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
There are no additional elements to be evaluated under Step 2A Prong 1.
Step 2A Prong 2 and Step 2B:
(a) “The method of claim 1, wherein the predicted portion of the software deployment pipeline associated with the selected software development project is presented to at least one user” - The limitation recites presenting the result of the abstract evaluation to a user, which is directed to insignificant post-solution output activity (see MPEP 2106.05(g)). Furthermore, under Step 2B, the act of merely displaying a result to a user is a well-understood, routine, and conventional activity (WURC), and it does not provide significantly more than the judicial exception (see MPEP 2106.05(d)(II)).
(b) “in a software deployment pipeline editor” - The editor merely provides the computer environment in which the informational result is displayed. The claim does not recite a particular improvement to the editor or a technical mechanism by which the editor validates or executes the predicted pipeline. The limitation amounts to linking the abstract idea to a particular technological environment, which does not integrate to a practical application, nor provide significantly more than the judicial exception (see MPEP 2106.05(h)).
Thus, claim 6 is non-patent eligible.
Regarding claim 7,
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
There are no elements to be evaluated under Step 2A Prong 1.
Step 2A Prong 2 and Step 2B:
“applying at least one portion, selected based at least in part on the cursor position, of text from the at least one CI/CD configuration file as one or more system prompts to the at least one trained generative AI model, wherein the at least one trained generative AI model provides suggested software code as an automatic completion of the at least one portion of text from the at least one CI/CD configuration file” - The limitation recites applying at least one portion of text from a file as one or more trained generative AI model which the model will then provide the software code as a completion of the portioned texts from the CI/CD configuration file. The limitation amounts to no more than mere instructions to apply onto a computer, and thus it cannot be integrated to a practical application, nor provide significantly more than the judicial exception (see MPEP 2106.05(f)).
“obtaining information characterizing a cursor position in at least one CI/CD configuration file being edited by at least one user” - The limitation recites obtaining cursor-position information constitutes gathering contextual information used to perform the abstract code-completion evaluation. The claim does not recite an unconventional cursor-detection mechanism. The limitation is considered an insignificant extra-solution activity that cannot be integrated to a practical application (see MPEP 2106.05(g)). Furthermore, under Step 2B, the act of mere data gathering/obtaining information from a file edited by a user is a well-understood, routine, and conventional activity (WURC), and thus does not provide significantly more than the judicial exception (see MPEP 2106.05(d)(II)).
“at least one portion, selected based at least in part on the cursor position, of text from the at least one CI/CD configuration file” - Selecting text based on the cursor position merely identifies the information to be analyzed. The claim does not recite a particular parser, syntax tree, semantic-analysis process, context-window architecture, or technical selection algorithm. The limitation therefore does not improve computer functionality nor integrate the exception into a practical application/provide significantly more than the judicial exception.
Thus, claim 7 is non-patent eligible. Claims 13 and 19 are analogous to claim 5 and thus face the same rejection above.
Regarding claim 8
Step 1: The claim is directed to a method, which is one of the four statutory categories. Therefore, the claim satisfies Step 1.
Step 2A Prong 1:
“wherein the predicted portion of the software deployment pipeline associated with the selected software development project comprises one or more corrections of one or more of a syntax and a structure of at least one CI/CD configuration file being edited by at least one user” - This limitation is directed to reviewing configuration-file content, identifying a syntactic or structural issue, and determining a correction. Reviewing written instructions for compliance with syntax or structural conventions and determining how an error should be corrected constitute observations, evaluations, and judgments that can practically be performed by a software developer. The limitation therefore recites a mental process.
There are no elements to be evaluated under Step 2A Prong 2 and Step 2B.
Thus, claim 8 is non-patent eligible. Claims 14 and 20 are analogous to claim 8 and thus face the same rejection as above.
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.
Claim(s) 1, 3-6, 9, 11-12, 15, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over NPL reference “Automated DevOps Pipeline Generation for Code Repositories using Large Language Models”, by Mehta et. al. (referred herein as Mehta) in view of NPL reference “Automated Code generation for Information Technology Tasks in YAML through Large Language Models”, by Pujar et. al. (referred herein as Pujar) further in view of US 20240086157 A1, by Patil et. al. (referred herein as Patil).
Regarding claim 1, Mehta teaches:
A method, comprising: ([Mehta, page 1] “Our methodology involves data collection from public GitHub repositories, prompt engineering for LLM utilization, and evaluation metrics encompassing exact match scores, BLEU scores, and a novel DevOps Aware score.”), wherein the examiner interprets “Our methodology involves” to be the same as A method, comprising: because they are both directed to a defined series of operations for using a large language model to generate and evaluate a DevOps workflow.)
obtaining at least one trained generative artificial intelligence (AI) model, ([Mehta, page 2] “In our work, we develop an app that invoked the GPT 4 (gpt-4-1106-preview) chat completion API to generate workflow and raise a pull request for the developers to review, improvise by conversing with the bot and merge the workflow file.”, wherein the examiner interprets “invoked the GPT 4 (gpt-4-1106-preview) chat completion API” to be the same as obtaining at least one generative artificial intelligence (AI) model because they are both directed to accessing and using a generative large language model to generate software-workflow content.)
obtaining information characterizing a selected software development project; ([Mehta, page 2] “The app runs on Azure functions and uses the Octokit client to interact with GitHub and get information about the repository, such as its structure and contents.” AND [Mehta, page 2] “The context provided during this request includes the repository file structure and the default branch of the repository.”, wherein the examiner interprets “get information about the repository, such as its structure and contents” and “the repository file structure and the default branch of the repository” to be the same as obtaining information characterizing a selected software development project because they are both directed to obtaining technical information describing the structure, contents, and branch characteristics of the software-project repository.)
applying at least a portion of the information characterizing the selected software development project as one or more system prompts to the at least one trained generative AI model, ([Mehta, page 1] “For generating a YAML file for a given repository, ideally, the more information about the repository in the prompt, the better performance is expected to be achieved.” AND [Mehta, page 1] “In this work, we customize the prompt with the following 2 parts as our first attempt. Particularly, for designing context, we consider 2 pieces of task-specific information, which are file structure and default branch based on our observation.” AND [Mehta, page 2] “The context provided during this request includes the repository file structure and the default branch of the repository.” AND [Mehta, page 2] “In this scenario, the GPT is invoked with the context of the existing workflow and all previous conversations that the user has had within that pull request.”, wherein the examiner interprets “information about the repository in the prompt,” “file structure and default branch,” and “the context of the existing workflow” to be the same as at least a portion of the information characterizing the selected software development project because they are all directed to project-specific technical information describing the selected repository, and wherein the examiner interprets providing the repository information “in the prompt” and invoking GPT “with the context of the existing workflow” to be the same as applying the project information as one or more system prompts to the at least one trained generative AI model because they are both directed to supplying project-specific information as prompting context that guides the generative AI model.)
wherein the at least one trained generative AI model predicts at least a portion of a software deployment pipeline associated with the selected software development project; ([Mehta, page 1] “This paper presents a detailed investigation into the use of Large Language Models (LLMs) - specifically, GPT 3.5 and GPT 4 - to generate and evaluate GitHub Action workflows for DevOps tasks.” AND [Mehta, page 1] “Automation has become integral to modern software development, and GitHub Action workflows stand as a pivotal tool in orchestrating streamlined software delivery pipelines.” AND [Mehta, page 2] “As shown in Figure 3, the bot can automatically generate a workflow for a GitHub repository when a user creates a new issue with a title that begins with @devops and a body that specifies any custom requests.” AND [Mehta, page 4] “This app can be installed in any GitHub repository and used to generate GitHub build and test workflows for that repository.”, wherein the examiner interprets using “GPT 3.5 and GPT 4 - to generate and evaluate GitHub Action workflows for DevOps tasks” and generating “GitHub build and test workflows” to be the same as the at least one trained generative AI model predicts at least a portion of a software deployment pipeline because they are both directed to a generative AI model producing build-and-test workflow content that constitutes at least a portion of a software delivery pipeline, and wherein the examiner interprets automatically generating a workflow “for a GitHub repository” and generating workflows “for that repository” to be the same as associated with the selected software development project because they are both directed to generating a workflow specifically for the repository corresponding to the selected software project.)
Mehta does not teach wherein the at least one trained generative AI model is trained using a plurality of CI/CD configuration files…wherein the method is performed by at least one processing device comprising a processor coupled to a memory.
Pujar teaches:
wherein the at least one trained generative AI model is trained using a plurality of CI/CD configuration files; ([Pujar, page 1] “Ansible Wisdom is a transformer-based model, extended by training with a new dataset containing Ansible-YAML.” AND [Pujar, page 3] “Our curated dataset contains ∼1.1M Ansible task and playbook YAMLs, and ∼2.2M other generic YAML files.” AND [Pujar, page 3] “To improve the pre-trained model understanding of the semantics and syntax of YAML, we build WISDOM-ANSIBLE-MULTI and WISDOM-YAML-MULTI, which are trained from the CODEGEN checkpoint with a dataset that contains only Ansible-YAML files and a dataset that contains Ansible-YAML and generic YAML files, respectively (see table I for detail).” AND [Pujar, page 3] “We trained the model using our YAML dataset for 9 epochs using 16 A100 GPUs with 80 GB of memory.”, wherein the examiner interprets “a transformer-based model, extended by training” and models that “are trained from the CODEGEN checkpoint” to be the same as the at least one trained generative AI model is trained because they are both directed to training or extending a pretrained transformer-based generative model, and wherein the examiner interprets “∼1.1M Ansible task and playbook YAMLs, and ∼2.2M other generic YAML files” and “We trained the model using our YAML dataset” to be the same as training the model using a plurality of configuration files because they are both directed to training a generative model using a collection containing numerous YAML configuration files.)
Mehta and Pujar do not teach wherein the method is performed by at least one processing device comprising a processor coupled to a memory.
wherein the method is performed by at least one processing device comprising a processor coupled to a memory. ([Patil, [0114]], The processing device 1202-1 in the processing platform 1200 comprises a processor 1210 coupled to a memory 1212.”, wherein the examiner interprets “comprises a processor 1210 coupled to a memory 1212” to be the same as performing a task/method by a processing device that comprises a processor coupled to memory, because they are both directed to coupled memory within a device to perform a task/method.)
Mehta, Pujar, Patil, and the instant application are analogous art because they are all directed to computer-implemented generation of software-automation or software-deployment configuration code using project or task information and code-generation systems.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the obtaining a generative AI model disclosed by Mehta to include the “transformer-based model, extended by training with a new dataset containing Ansible-YAML” disclosed by Pujar. One would be motivated to do so to effectively improve the generative model’s understanding of the syntax and structure of YAML configuration files and thereby improve the performance and syntactic accuracy of the CI/CD workflows generated by Mehta, as suggested by Pujar ([Pujar, page 6] “adding a large collection of YAMLs to pre-train or extend the pre-training of an existing model offer a large boost in performance for the Ansible task generations.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to further include the “at least one processing device comprising a processor coupled to a memory” disclosed by Patil. One would be motivated to do so to reliably and efficiently execute the project-information processing and software-deployment-pipeline generation operations using computer hardware, as suggested by Patil ([Patil, [0024]] “Such embodiments allow software developers and other DevOps professionals to reliably and efficiently generate and distribute software deployment pipelines.”). Claims 9 and 15 are analogous to claim 1, aside from differences in claim type, and therefore the same rejection applies.
Regarding 3, Mehta, Pujar, and Patil teaches The method of claim 1, (see rejection of claim 1.)
Pujar further teaches wherein a training of the at least one trained generative AI model updates at least one pre-trained generative AI model to learn a syntax associated with the plurality of CI/CD configuration files ([Pujar, page 3] “To improve the pre-trained model understanding of the semantics and syntax of YAML, we build WISDOM-ANSIBLE-MULTI and WISDOM-YAML-MULTI, which are trained from the CODEGEN checkpoint with a dataset that contains only Ansible-YAML files and a dataset that contains Ansible-YAML and generic YAML files, respectively (see table I for detail).” AND [Pujar, page 6] “WISDOM-ANSIBLE-MULTI was initialized with the weights of CODEGEN-MULTI and we extended the pre-training using Ansible YAML.”, wherein the examiner interprets models that are “trained from the CODEGEN checkpoint” and “initialized with the weights of CODEGEN-MULTI” followed by extending the pre-training to be the same as a training of the at least one trained generative AI model updates at least one pre-trained generative AI model because they are both directed to continuing the training of an existing pretrained generative model using additional domain-specific data, and wherein the examiner interprets training performed “[t]o improve the pre-trained model understanding of the semantics and syntax of YAML” to be the same as to learn a syntax associated with the plurality of CI/CD configuration files because they are both directed to training the model to understand the syntax of the YAML configuration-file domain. Mehta is relied upon for teaching that the relevant YAML files are CI/CD configuration files used for build, test, and deployment operations.)
Mehta, Pujar, Patil, and the instant application are analogous art because they are all directed to generative models for producing YAML-based software-automation and deployment configuration code.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 1 disclosed by Mehta, Pujar, and Patil to include the model that was “initialized with the weights of CODEGEN-MULTI” and for which “we extended the pre-training using Ansible YAML” disclosed by Pujar. One would be motivated to do so to effectively improve the model’s understanding of CI/CD YAML syntax and the accuracy of its generated CI/CD workflows, as suggested by Pujar ([Pujar, page 6] “adding a large collection of YAMLs to pre-train or extend the pre-training of an existing model offer a large boost in performance for the Ansible task generations.”). Claims 11 and 17 are analogous to claim 3, aside from differences in claim type, and therefore the same rejection applies.
Regarding 4, Mehta, Pujar, and Patil teaches The method of claim 1, (see rejection of claim 1.)
Mehta further teaches wherein the predicted portion of the software deployment pipeline associated with the selected software development project comprises one or more pipeline jobs ([Mehta, page 3] “The evaluation process involves examining the ‘jobs’ section, which comprises ‘steps’ specifying actions and commands for execution.” AND [Mehta, page 4] “This app can be installed in any GitHub repository and used to generate GitHub build and test workflows for that repository.”, wherein the examiner interprets the generated workflow’s “jobs” section comprising executable actions and commands to be the same as one or more pipeline jobs because they are both directed to executable jobs forming part of a generated software-delivery workflow.)
Patil further teaches Patil teaches wherein the predicted portion of the software deployment pipeline associated with the selected software development project comprises one or more pipeline jobs in one or more pipeline stages in the software deployment pipeline associated with the selected software development project ([Patil, [0090] “In one or more embodiments, one or more missing pipeline stages in the software deployment pipeline are recommended based at least in part on one or more pipeline stages in the recommended development and operations blueprint.” AND “[Patil, 0091] “In some embodiments, the plurality of reusable software development resources comprises one or more of: (i) one or more pipeline job templates available from the
development and operations collaboration tool”, wherein the examiner interprets the recommended pipeline jobs “in one or more pipeline stages in the software deployment pipeline… one or more pipeline job templates available from the development and operations” to be the same as the predicted portion comprising one or more pipeline jobs in one or more pipeline stages because they are both directed to automatically determining and providing pipeline jobs organized within the stages of a software-deployment pipeline.)
Mehta, Pujar, Patil, and the instant application are analogous art because they are all directed to automatically generating or recommending jobs and other executable content for software-deployment pipelines.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 1 disclosed by Mehta, Pujar, and Patil to include “recommending one or more missing pipeline jobs in one or more pipeline stages” disclosed by Patil. One would be motivated to do so to efficiently organize the generated build, test, and deployment operations into suitable pipeline stages and provide any jobs needed for a complete deployment pipeline, as suggested by Patil (([Patil, [0090] “In one or more embodiments, one or more missing pipeline stages in the software deployment pipeline are recommended based at least in part on one or more pipeline stages in the recommended development and operations blueprint.” AND “[Patil, 0091] “In some embodiments, the plurality of reusable software development resources comprises one or more of: (i) one or more pipeline job templates available from the development and operations collaboration tool”). The pipeline-job-and-stage limitations of claims 12 and 18 are analogous to claim 4. The additional GUI-selection limitations of claims 12 and 18 are addressed with claim 5.
Regarding claim 5, Mehta, Pujar, and Patil teaches The method of claim 4 (see rejection of claim 4).
Patil further teaches wherein a graphical user interface of an integrated development environment presents a plurality of software development projects to at least one user, and in response to the at least one user selecting the selected software development project from the plurality of software development projects, the at least one trained generative AI model predicts the one or more pipeline jobs in the one or more pipeline stages in the software deployment pipeline ([Patil, 0092] “In at least one embodiment, the graphical user interface presents a plurality of software development projects to the user, and in response to the user selecting the selected software development project from the plurality of software development projects, the graphical user interface presents a software deployment pipeline creation window to the user to process the software deployment pipeline.” AND [Patil, [0083] “In step 908, one or more missing pipeline jobs are recommended in one or more of the pipeline stages of the software deployment pipeline based at least in part on the pipeline jobs in the corresponding pipeline stage of the recommended DevOps blueprint.”, wherein the examiner interprets the graphical user interface presenting “a plurality of software development projects” and responding to selection of “the selected software development project” to be the same as a graphical user interface presents a plurality of software development projects to at least one user, and in response to the at least one user selecting the selected software development project from the plurality of software development projects because the language describes the same project-presentation and selection sequence, and wherein the examiner interprets recommending “pipeline jobs” in “the pipeline stages” after the project-specific pipeline window is presented to be the same as predicting the one or more pipeline jobs in the one or more pipeline stages because they are both directed to automatically determining jobs within pipeline stages for the selected project.)
Mehta, Pujar, Patil, and the instant application are analogous art because they are all directed to user interfaces and trained code-generation systems for creating project-specific software-automation and deployment code.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 4 disclosed by Mehta, Pujar, and Patil to include the graphical user interface that “presents a plurality of software development projects to the user” and responds to selection of the selected project as disclosed by Patil. One would be motivated to do so to efficiently permit the user to identify the project for which the generative model should create pipeline jobs and stages, as suggested by Patil ([Patil, 0092] “In at least one embodiment, the graphical user interface presents a plurality of software development projects to the user, and in response to the user selecting the selected software development project from the plurality of software development projects, the graphical user interface presents a software deployment pipeline creation window to the user to process the software deployment pipeline.”) Claims 12 and 18 are analogous to claim 5, aside from differences in claim type, and therefore the same rejection applies.
Regarding claim 6, Mehta, Pujar, and Patil teaches The method of claim 1 (see rejection of claim 1).
Mehta further teaches wherein the predicted portion of the software deployment pipeline associated with the selected software development project is presented to at least one user… for approval prior to adding the predicted portion to the software deployment pipeline ([Mehta, page 2] “In our work, we develop an app that invoked the GPT 4 (gpt-4-1106-preview) chat completion API to generate workflow and raise a pull request for the developers to review, improvise by conversing with the bot and merge the workflow file.”; [Mehta, page 4] “If you’re satisfied with the workflow, you can merge the pull request. (6) If you need modifications, add a comment in the pull request detailing the changes required.”, wherein the examiner interprets raising a pull request containing the generated workflow “for the developers to review” and permitting the developer to merge the workflow only when “satisfied with the workflow” to be the same as presenting the predicted pipeline portion for approval prior to adding the predicted portion to the software deployment pipeline because they are both directed to presenting generated workflow content for user review and requiring user acceptance before that content is merged into the project.)
Mehta does not teach in a software deployment pipeline editor.
Patil further teaches in a software deployment pipeline editor ([Patil, [0057] “the graphical user interface 400 comprises an icon 410 to access a visual software deployment pipeline editor” AND [Patil, [0084] “One or more of the recommended pipeline stages and/or the recommended pipeline jobs that are accepted by the user are added to the software deployment pipeline in step 910.”, wherein the examiner interprets the “visual software deployment pipeline editor” to be the same as a software deployment pipeline editor because they are both directed to an editor interface for creating or modifying a software-deployment pipeline, and wherein the examiner interprets recommended pipeline stages or jobs that “are accepted by the user” before they “are added to the software deployment pipeline” to be the same as presentation for approval prior to adding the predicted portion to the software deployment pipeline because they are both directed to requiring user acceptance before recommended pipeline content is inserted into the pipeline.)
Mehta, Pujar, Patil, and the instant application are analogous art because they are all directed to presenting automatically generated software-deployment-pipeline content to a developer for review and incorporation into a project.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 1 disclosed by Mehta, Pujar, and Patil to present the generated workflow through the “visual software deployment pipeline editor” disclosed by Patil. One would be motivated to do so to efficiently provide the user with a visual, project-specific environment for reviewing and approving generated pipeline content before incorporating that content into the software-deployment pipeline, as suggested by Patil (Patil, [0057] “the graphical user interface 400 comprises an icon 410 to access a visual software deployment pipeline editor” AND [Patil, [0084] “One or more of the recommended pipeline stages and/or the recommended pipeline jobs that are accepted by the user are added to the software deployment pipeline in step 910.”)
Claim(s) 2, 10, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta in view of Pujar in view of Patil further in view of NPL reference “FINE TUNING LLMS FOR ENTERPRISE: PRACTICAL GUIDELINES AND RECOMMENDATIONS”, by Raj et. al. (referred by Raj.)
Regarding 2, Mehta, Pujar, and Patil teaches The method of claim 1, (see rejection of claim 1.)
Mehta further teaches wherein the plurality of CI/CD configuration files (see rejection of claim 1; [Mehta, page 3] “Contain at least 1 .yml or .yaml file within .github/workflows folder. It indicates the presence of GitHub Actions.” AND [Mehta, page 3] “By design, GitHub Actions can be implemented for various purposes, such as build, test, deployment, etc.”, wherein the examiner interprets a “.yml or .yaml file within .github/workflows folder” indicating “the presence of GitHub Actions” for “build, test, deployment” to be the same as the plurality of CI/CD configuration files because they are both directed to multiple YAML workflow files that configure continuous-integration build-and-test operations and continuous-deployment operations.)
Mehta, Pujar, and Patil does not teach wherein the plurality of CI/CD configuration files are associated with an organization associated with the selected software development project.
Raj teaches wherein the plurality of CI/CD configuration files are associated with an organization associated with the selected software development project ([Raj, page 1] “fine tuning LLaMA, an open source LLM using proprietary documents and code from an enterprise repository” AND [Raj, page 2] “Even though LLM are already trained with lots of data which makes them to generate code depending on the input, the challenge is generating code about a specific enterprise domain code” AND [Raj, page 5] “The third method involves tokenizing the whole code base irrespective of the file type into the supported sequence length. This method doesn’t involve gathering any other data. The LLM model with this tokenized data is trained for the purpose of next token prediction usecase”, wherein the examiner interprets “proprietary documents and code from an enterprise repository” to be the same as the plurality of CI/CD configuration files are associated with an organization because they are both directed to software files belonging to and maintained within the repository of a particular enterprise or organization, and wherein the examiner interprets “specific enterprise domain code” to be the same as associated with the selected software development project because they are both directed to software data from the particular enterprise domain to which the software-development project belongs.)
Mehta, Pujar, Patil, Raj, and the instant application are analogous art because they are all directed to trained models and computer-implemented systems for generating project-specific software automation or deployment code using software data associated with a project or organization.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 1 disclosed by Mehta, Pujar, and Patil to include the “proprietary documents and code from an enterprise repository” disclosed by Raj. One would be motivated to do so to effectively tailor the generative model to the organization-specific software conventions and project data of the enterprise and thereby improve the relevance and accuracy of the generated CI/CD workflow, as suggested by Raj ([Raj, page 1] “achieve improved accuracy”). Claims 10 and 16 are analogous to claim 2, aside from differences in claim type, and therefore the same rejection applies.
Claim(s) 7, 13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta in view of Pujar in view of Patil further in view of US 20230048186 A1, by Clement et. al. (referred herein as Clement).
Regarding claim 7, Mehta, Pujar, and Patil teaches The method of claim 1 (see rejection of claim 1).
Mehta further teaches further comprising obtaining information characterizing a cursor position in at least one CI/CD configuration file being edited by at least one user ([Mehta, page 2] “In this scenario, the GPT is invoked with the context of the existing workflow and all previous conversations that the user has had within that pull request.” AND [Mehta, page 2] “Figure 4 demonstrates the direct interaction between the user and the LLM via the pull request, facilitating the necessary workflow updates.”, wherein the examiner interprets the “existing workflow” being subjected to “workflow updates” through user interaction to be the same as at least one CI/CD configuration file being edited by at least one user because they are both directed to a user modifying an existing CI/CD workflow configuration with assistance from a generative model.)
Mehta does not teach and applying at least one portion, selected based at least in part on the cursor position, of text from the at least one CI/CD configuration file as one or more system prompts to the at least one trained generative AI model, wherein the at least one trained generative AI model provides suggested software code as an automatic completion of the at least one portion of text from the at least one CI/CD configuration file.
Clement teaches applying at least one portion, selected based at least in part on the cursor position, of text from the at least one CI/CD configuration file as one or more system prompts to the at least one trained generative AI model, wherein the at least one trained generative AI model provides suggested software code as an automatic completion of the at least one portion of text from the at least one CI/CD configuration file ([Clement, 0123] “generating an ordered sequence of subtokens representing a context of a source code program in a source code editor at a current cursor position, the source code program written in a first programming language, the context including a file-level context and a local context…providing the select partial candidate sequence as a candidate to complete the line of source code at the current cursor position.” AND [Clement, [0121] “extract a local context of the source code program at a current cursor position; and input the file-level context and the local-context to the deep learning model to generate the candidate.”, wherein the examiner interprets the “current cursor position” to be the same as information characterizing a cursor position because both identify the editing position in the source-code file, and wherein the examiner interprets extracting “a local context of the source code program at a current cursor position” to be the same as selecting at least one portion, selected based at least in part on the cursor position, of text because they are both directed to selecting source-code context based on its relationship to the cursor, and wherein the examiner interprets inputting “the file-level context and the local-context to the deep learning model” to be the same as applying the selected text as one or more system prompts to the at least one trained generative AI model because they are both directed to supplying selected textual context as input that guides a trained transformer model, and wherein the examiner interprets providing a candidate “to complete the line of source code at the current cursor position” to be the same as providing suggested software code as an automatic completion because they are both directed to predicting and presenting code that completes partially written code at the cursor location.)
Mehta, Pujar, Patil, Clement, and the instant application are analogous art because they are all directed to trained generative models that use software-project and source-file context to generate code within a software-development environment.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 1 disclosed by Mehta, Pujar, and Patil to include generating context “at a current cursor position,” inputting the local context to a deep learning model, and providing a candidate to complete the line of code as disclosed by Clement. One would be motivated to do so to efficiently provide contextually relevant CI/CD code completions while the user edits the workflow file and to reduce common coding errors, as suggested by Clement ([Clement, 0123] “generating an ordered sequence of subtokens representing a context of a source code program in a source code editor at a current cursor position, the source code program written in a first programming language, the context including a file-level context and a local context…providing the select partial candidate sequence as a candidate to complete the line of source code at the current cursor position.” AND [Clement, [0121] “extract a local context of the source code program at a current cursor position; and input the file-level context and the local-context to the deep learning model to generate the candidate.”) Claims 13 and 19 are analogous to claim 7, aside from differences in claim type, and therefore the same rejection applies.
Claim(s) 8, 14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta in view of Pujar in view Patil further in view of NPL reference “Repair Is Nearly Generation: Multilingual Program Repair with LLMs”, by Joshi et. al. (referred herein as Joshi).
Regarding claim 8, Mehta, Pujar, and Patil teaches The method of claim 1 (see rejection of claim 1).
Mehta further teaches wherein the predicted portion of the software deployment pipeline associated with the selected software development project comprises one or more corrections of one or more of a syntax and a structure of at least one CI/CD configuration file being edited by at least one user ([Mehta, page 3] “Firstly, the syntax of the workflow is checked which checks if appropriate keys are used, the file follows workflow syntax and the structure is correct.” AND [Mehta, page 2] “Figure 4 demonstrates the direct interaction between the user and the LLM via the pull request, facilitating the necessary workflow updates.”, wherein the examiner interprets checking whether “the file follows workflow syntax and the structure is correct” to be the same as evaluating a syntax and a structure of at least one CI/CD configuration file because they are both directed to determining whether the CI/CD workflow file complies with its required syntax and structural arrangement, and wherein the examiner interprets the user and LLM interaction “facilitating the necessary workflow updates” to be the same as editing the CI/CD configuration file because they are both directed to modifying an existing workflow.
Mehta does not expressly teach that the predicted portion generated by the model comprises one or more corrections to the syntax or structure of the CI/CD configuration file.)
Joshi teaches:
wherein the predicted portion of the software deployment pipeline associated with the selected software development project comprises one or more corrections of one or more of a syntax and a structure of at least one CI/CD configuration file being edited by at least one user ([Joshi, page 1] “More recently, neural approaches have been successfully applied to repairing syntax and diagnostics errors.” AND [Joshi, page 1] “We introduce RING, a multilingual repair engine powered by a large language model trained on code (LLMC) such as Codex. Such a multilingual engine enables a flipped model for programming assistance, one where the programmer writes code and the AI assistance suggests fixes, compared to traditional code suggestion technology.”, wherein the examiner interprets a “repair engine powered by a large language model” through which “the AI assistance suggests fixes” to be the same as the trained generative AI model providing one or more corrections because they are both directed to an LLM generating proposed changes that repair user-written code, and wherein the examiner interprets “repairing syntax and diagnostics errors” to be the same as providing corrections of a syntax because they are both directed to correcting code that does not comply with the applicable language syntax. Mehta is relied upon for teaching that the code being checked and updated is a CI/CD workflow configuration file and that both its workflow syntax and structure are evaluated.)
Mehta, Pujar, Patil, Joshi, and the instant application are analogous art because they are all directed to using large language models to generate, evaluate, or repair software code within a software-development workflow.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the method of claim 1 disclosed by Mehta, Pujar, and Patil to include the LLM-powered repair functionality through which “the AI assistance suggests fixes” disclosed by Joshi. One would be motivated to do so to effectively correct syntax errors in the generated CI/CD configuration file and reduce the manual effort needed to identify and repair invalid generated workflows, as suggested by Joshi ([Joshi, page 1] “a prompt-based strategy that conceptualizes repair as localization, transformation, and candidate ranking, can successfully repair programs in multiple languages with minimal effort.”). Claims 14 and 20 are analogous to claim 8, aside from differences in claim type, and therefore the same rejection applies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVAN KAPOOR whose telephone number is (703) 756-1434. The examiner can normally be reached Monday - Friday: 9:00AM - 5:00 PM EST (times may vary).
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, David Yi can be reached at (571) 270-7519. 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.
/DEVAN KAPOOR/Examiner, Art Unit 2126
/DAVID YI/Supervisory Patent Examiner, Art Unit 2126
Prosecution Insights