DETAILED ACTION
This Action is a response to the reply filed 15 September 2026. Claims 1, 5, 11, 15-16 and 20 are amended; claims 4, 14 and 19 are canceled; and claims 21-23 are newly added. Claims 1-3, 5-13, 15-18 and 20-23 remain pending for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
While the independent claims still do recite the mental process step of “generating documentation associated with development of the at least one set of software code by processing at least a portion of the information in the one or more data structures …”, the additional element presented in the amendment, considered in combination with the other elements of the claim, recites significantly more than the abstract idea. The rejections under 35 U.S.C. § 101 are accordingly withdrawn.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 5-11, 15-16 and 20-23 are rejected under 35 U.S.C. § 103 as being unpatentable over Gabel et al., U.S. 2024/0184566 A1 (“Gabel”) in view of Pena Pena et al., U.S. 2025/0245483 A1 (“Pena Pena”).
Regarding claim 1, Gabel teaches: A computer-implemented method (Gabel, e.g., ¶42, “FIG. 3 is a flowchart that illustrates a method that trains the machine-learning model(s) 230 to assist with performing engineering tasks … method acts … for certain steps involved in and/or between the clients 202-204 and/or the servers 206-208 of FIG. 2”) comprising:
compiling, from one or more data sources, information pertaining to at least one set of software code in one or more data structures (Gabel, e.g., ¶83, “system retrieves context data which establishes a context for the software engineering task … from the dynamic data pipeline 232, such as the description to fix the … error …” See also, e.g., ¶84, “system transforms a software engineering task’s context data to be in the format used to predict for the software engineering task …” See also, e.g., ¶¶43-50, “system retrieves data from multiple data stores … connected to a central location … which include a data source associated with multiple software engineering projects associated with a single enterprise … which include an open-source software project … project history … issue report … source code … link commits of source code by a version control system …to the issue reports in the issue tracker 216 that the commits resolve, and link the issue reports to the more general documents that the issue reports reference …”);
generating documentation associated with development of the at least one set of software code by processing at least a portion of the information in the one or more data structuresat least one large language model (LLM) (Gabel, e.g., ¶48, “training server 206 encodes a project history as text and has the project history learned within a large language model …” See also, e.g., ¶51, “system transforms the data to be compatible with a data format used to train any machine-learning model(s) …” See also, e.g., ¶54, “system trains the machine-learning model(s) with the transformed data to assist with a performing a software engineering task by making a prediction of source code changes for the software engineering task …” See also, e.g., ¶83, “agent 244 retrieving context data which establishes the software engineering task’s context from the dynamic data pipeline 232, such as the description … issue report … priority … source code changes …” See also, e.g., ¶85, “machine-learning model(s) 242 using the transformed context data to predict a first set of source code changes … and a second set of source code changes …” See also, e.g., ¶91, “machine learning model(s) 242 responding to Sofia modifying the issue report for the software engineering task to fix the body validation error response and remove a variable name when it is not embedded, to specify that the completed the source code changes … and using such a modification as context data for predicting other source code changes for another completion of the software engineering task …” Examiner’s note: the generated completion predictions and generated updated issue reports comprise documentation generated using at least one LLM and used to perform one or more automated actions); and
performing one or more automated actions based at least in part on one or more portions of the generated documentation associated with the development of the at least one set of software code (Gabel, e.g., ¶89, “system enables a software developer to complete a software engineering task by outputting the predicted completions of the software engineering task to the code editor or issue tracker … within or beside the issue tracker 216, with each predicted completion depicted in the form of a difference …” See also, e.g., ¶91, “machine-learning model(s) 242 responding to Sofia modifying the issue report for the software engineering task … to specify that she completed the source code changes … and using such a modification as context data for predicting other source code changes for another completion of the software engineering task …”);
wherein the method is performed by at least one processing device comprising a processor coupled to a memory (Gabel, e.g., ¶168, “an exemplary system for implementing the subject matter disclosed herein includes a hardware device 900, including a processing unit 902, a memory 904 … and a bus 914 that couples elements 904-912 to the processing unit 902”).
Gabel does not more particularly teach that the LLM is fine-tuned with at least one PEFT algorithm that modifies at least a portion of the LLM using one or more matrices injected into the LLM, and wherein one or more weights of the LLM, existing prior to injection of the matrices, remain unchanged in connection with the PEFT algorithm. However, Pena Pena does teach: [at least one LLM] fine-tuned with at least one parameter-efficient fine-tuning (PEFT) algorithm that modifies at least a portion of the at least one LLM using one or more matrices injected into the at least one LLM, and wherein one or more weights, existing prior to injection of the one or more matrices, of the at least one LLM remain unchanged in connection with the at least one PEFT algorithm (Pena Pena, e.g., ¶58, “The policy (LLM) is fine-tuned with supervised training … using a domain adaption technique, such as parameter-efficient fine-tuning (PEFT) … PEFT method for fine-tuning the policy may be Low-Rank Adaptation (LoRA) … freezes pre-trained model weights and injects trainable rank decomposition matrices …”) for the purpose of adapting a large-scale pre-trained model to a new task without significantly increasing the number of parameters in a way that decreases storage and computational requirements and overcomes issues of catastrophic forgetting (Pena Pena, e.g., ¶58).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for artificial intelligence-assisted software documentation prediction and generation as taught by Gabel to provide that the LLM is fine-tuned with at least one PEFT algorithm that modifies at least a portion of the LLM using one or more matrices injected into the LLM, and wherein one or more weights of the LLM, existing prior to injection of the matrices, remain unchanged in connection with the PEFT algorithm because the disclosure of Pena Pena shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for generating completeness graphs for compliance domains within projects to provide that the LLM is fine-tuned with at least one PEFT algorithm that modifies at least a portion of the LLM using one or more matrices injected into the LLM, and wherein one or more weights of the LLM, existing prior to injection of the matrices, remain unchanged in connection with the PEFT algorithm for the purpose of adapting a large-scale pre-trained model to a new task without significantly increasing the number of parameters in a way that decreases storage and computational requirements and overcomes issues of catastrophic forgetting (Pena Pena, Id.).
Claims 11 and 16 are rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 11, Gabel further teaches: A non-transitory processor-readable storage medium having stored thein program code of one or more software programs, wherein the program code when executed by at least one processing device causes the at least one processing device (Gabel, e.g., ¶42, “FIG. 3 is a flowchart that illustrates a method that trains the machine-learning model(s) 230 to assist with performing engineering tasks … method acts … for certain steps involved in and/or between the clients 202-204 and/or the servers 206-208 of FIG. 2.” See also, e.g., Gabel, e.g., ¶168, “an exemplary system for implementing the subject matter disclosed herein includes a hardware device 900, including a processing unit 902, a memory 904 … and a bus 914 that couples elements 904-912 to the processing unit 902”): [[[to perform the method of claim 1]]]; and with respect to claim 16, Gabel further teaches: An apparatus comprising: at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured (Gabel, e.g., ¶42, “FIG. 3 is a flowchart that illustrates a method that trains the machine-learning model(s) 230 to assist with performing engineering tasks … method acts … for certain steps involved in and/or between the clients 202-204 and/or the servers 206-208 of FIG. 2.” See also, e.g., Gabel, e.g., ¶168, “an exemplary system for implementing the subject matter disclosed herein includes a hardware device 900, including a processing unit 902, a memory 904 … and a bus 914 that couples elements 904-912 to the processing unit 902”): [[[to perform the method of claim 1]]].
Regarding claim 5, the rejection of claim 1 is incorporated, and Gabel further teaches: wherein processing at least a portion of the information in the one or more data structures using at least one LLM comprises processing at least a portion of the information in the one or more data structures using at least one LLM fine-tuned using technical information related to the at least one set of software code (Gabel, e.g., ¶48, “training server 206 encodes a project history as text and has the project history learned within a large language model …” Examiner’s note: as discussed above, the project history of a particular software development includes at least code (changes) and issue reports, etc., which comprise technical information related to at least one set of software code).
Claims 15 and 20 are rejected for the additional reasons given in the rejection of claim 5 above.
Regarding claim 6, the rejection of claim 1 is incorporated, and Gabel further teaches: wherein the one or more data structures comprise multiple data structures, each data structure associated with a distinct category of code-related information (Gabel, e.g., ¶83, “system retrieves context data which establishes a context for the software engineering task … from the dynamic data pipeline 232, such as the description to fix the … error …” See also, e.g., ¶84, “system transforms a software engineering task’s context data to be in the format used to predict for the software engineering task …” See also, e.g., ¶¶43-50, “system retrieves data from multiple data stores … connected to a central location … which include a data source associated with multiple software engineering projects associated with a single enterprise … which include an open-source software project … project history … issue report … source code … link commits of source code by a version control system …to the issue reports in the issue tracker 216 that the commits resolve, and link the issue reports to the more general documents that the issue reports reference …”), and
wherein generating documentation associated with the development of the at least one set of software code comprises combining one or more portions of the code-related information from each of two or more of the multiple data structures (Gabel, e.g., ¶51, “system transforms the data to be compatible with a data format used to train any machine-learning model(s) …” See also, e.g., ¶54, “system trains the machine-learning model(s) with the transformed data to assist with a performing a software engineering task by making a prediction of source code changes for the software engineering task …” See also, e.g., ¶83, “agent 244 retrieving context data which establishes the software engineering task’s context from the dynamic data pipeline 232, such as the description … issue report … priority … source code changes …” See also, e.g., ¶85, “machine-learning model(s) 242 using the transformed context data to predict a first set of source code changes … and a second set of source code changes …”).
Regarding claim 7, the rejection of claim 1 is incorporated, and Gabel further teaches: wherein performing one or more automated actions comprises automatically training at least a portion of the one or more artificial intelligence techniques using feedback related to the generated documentation associated with the development of the at least one set of software code (Gabel, e.g., ¶58, “after initially training the machine-learning model(s) the system iteratively retrieves additional data from the data sources, links the additional data, transforms the additional data, and trains the machine-learning model(s) with transformed additional data …” See also, e.g., ¶60, “training of the machine-learning model(s) 230 may then restart its process using the current machine-learning model(s) as input, focusing solely on the updates of the data …” See also, e.g., ¶93, “system optionally commits the source code changes based on the predicted source code changes associated with one of the completions of the software engineering task, as accepted by the code editor and/or the issue tracker associated with the software developer, to source code associated with the software engineering task …” Examiner’s note: the generated documentation comprises the predicted source code changes, and the feedback pertaining thereto is the developer’s acceptance of one of the predicted source code changes and the commit thereof).
Regarding claim 8, the rejection of claim 1 is incorporated, and Gabel further teaches: wherein performing one or more automated actions comprises automatically transmitting the generated documentation associated with the development of the at least one set of software code to one or more code repositories related to the at least one set of software code (Gabel, e.g., ¶85, “machine-learning model(s) 242 using the transformed context data to predict a first set of source code changes … and a second set of source code changes …” See also, e.g., ¶93, “system optionally commits the source code changes based on the predicted source code changes associated with one of the completions of the software engineering task, as accepted by the code editor and/or the issue tracker associated with the software developer, to source code associated with the software engineering task …” Examiner’s note: the documentation is the predicted source code changes, which may be accepted and committed in an automated fashion, wherein a commit would be transmitted to the version control system / repository).
Claim 21 is rejected for the additional reasons given in the rejection of claim 7 or the rejection of claim 8 above.
Regarding claim 9, the rejection of claim 1 is incorporated, and Gabel further teaches: wherein compiling information pertaining to at least one set of software code in one or more data structures comprises compiling, in the one or more data structures, information related to one or more of at least one codebase associated with the at least one set of software code, one or more commits associated with the at least one set of software code, one or more code branches associated with the at least one set of software code, and one or more continuous integration and continuous delivery (CICD) pipelines associated with the at least one set of software code (Gabel, e.g., ¶83, “system retrieves context data which establishes a context for the software engineering task … from the dynamic data pipeline 232, such as the description to fix the … error …” See also, e.g., ¶¶43-50, “system retrieves data from multiple data stores … connected to a central location … which include a data source associated with multiple software engineering projects associated with a single enterprise … which include an open-source software project … project history … issue report … source code … link commits of source code by a version control system …to the issue reports in the issue tracker 216 that the commits resolve, and link the issue reports to the more general documents that the issue reports reference …” Examiner’s note: commits, issue reports and related code comprise information related to a code base, commits and/or branches, and an iterative process for writing code, identifying issues and resolving the issues is consistent with a CICD pipeline).
Claim 22 is rejected for the additional reasons given in the rejection of claim 9 above.
Regarding claim 10, the rejection of claim 1 is incorporated, and Gabel further teaches: wherein compiling information pertaining to at least one set of software code in one or more data structures comprises compiling, in the one or more data structures, information related to at least one of one or more issues associated with the at least one set of software code, one or more defects associated with the at least one set of software code, one or more deployed versions of the at least one set of software code, and existing documentation associated with the at least one set of software code (Gabel, e.g., ¶83, “system retrieves context data which establishes a context for the software engineering task … from the dynamic data pipeline 232, such as the description to fix the … error …” See also, e.g., ¶¶43-50, “system retrieves data from multiple data stores … connected to a central location … which include a data source associated with multiple software engineering projects associated with a single enterprise … which include an open-source software project … project history … issue report … source code … link commits of source code by a version control system …to the issue reports in the issue tracker 216 that the commits resolve, and link the issue reports to the more general documents that the issue reports reference …” Examiner’s note: source code, commits and related issue reports comprise issues and/or defects associated with one or more versions of the code (whether deployed or undeployed), and at least project history comprises existing documentation associated with the code).
Regarding claim 23, the rejection of claim 1 is incorporated, but Gabel does not more particularly teach that generating documentation associated with development of the software code by processing information in one or more data structures using at least one LLM fine-tuned with at least one PEFT algorithm comprises fine-tuning the at least one LLM using at least one low-rank adaptation (LoRA) technique. However, Pena Pena does teach: wherein generating documentation associated with development of the at least one set of software code by processing at least a portion of the information in the one or more data structures using at least one LLM fine-tuned with at least one PEFT algorithm comprises fine-tuning the at least one LLM using at least one low-rank adaptation (LoRA) technique (Pena Pena, e.g., ¶58, “The policy (LLM) is fine-tuned with supervised training … using a domain adaption technique, such as parameter-efficient fine-tuning (PEFT) … PEFT method for fine-tuning the policy may be Low-Rank Adaptation (LoRA) … freezes pre-trained model weights and injects trainable rank decomposition matrices …”) for the purpose of adapting a large-scale pre-trained model to a new task without significantly increasing the number of parameters in a way that decreases storage and computational requirements and overcomes issues of catastrophic forgetting (Pena Pena, e.g., ¶58).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for artificial intelligence-assisted software documentation prediction and generation as taught by Gabel in view of Pena Pena to provide that generating documentation associated with development of the software code by processing information in one or more data structures using at least one LLM fine-tuned with at least one PEFT algorithm comprises fine-tuning the at least one LLM using at least one low-rank adaptation (LoRA) technique because the disclosure of Pena Pena shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for generating completeness graphs for compliance domains within projects to provide that generating documentation associated with development of the software code by processing information in one or more data structures using at least one LLM fine-tuned with at least one PEFT algorithm comprises fine-tuning the at least one LLM using at least one low-rank adaptation (LoRA) technique for the purpose of adapting a large-scale pre-trained model to a new task without significantly increasing the number of parameters in a way that decreases storage and computational requirements and overcomes issues of catastrophic forgetting (Pena Pena, Id.).
Claims 2-3, 12-13 and 17-18 are rejected under 35 U.S.C. § 103 as being unpatentable over Gabel in view of Pena Pena, and in further view of Farrier, James, U.S. 2021/0263728 A1 (“Farrier”).
Regarding claim 2, the rejection of claim 1 is incorporated, but Gabel in view of Pena Pena does not more particularly teach that software code changes are detected using at least one webhook-based technique. However, Farrier does teach: detecting one or more changes associated with the at least one set of software code using at least one webhook-based technique (Farrier, e.g., ¶46, “systems and methods described herein may use any or all of a variety of methods for monitoring a code repository for new commits. one example is an application programming interface (API) callback, for example, a web-hook API, wherein a server overseeing a code repository transmits a function call or other message to notify a system of the invention that a new commit has taken place …”) for the purpose of enhancing software development efficiency by intelligently identifying tests associated with newly submitted code commits and using iteratively updated commit and test data to more quickly identify and run tests and to identify appropriate developers for particular sections of software code (Farrier, e.g., ¶¶7-17).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for artificial intelligence-assisted software documentation prediction and generation as taught by Gabel in view of Pena Pena to provide that software code changes are detected using at least one webhook-based technique because the disclosure of Farrier shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for artificial intelligence-assisted code-to-test mapping generation and updating to provide that software code changes are detected using at least one webhook-based technique for the purpose of enhancing software development efficiency by intelligently identifying tests associated with newly submitted code commits and using iteratively updated commit and test data to more quickly identify and run tests and to identify appropriate developers for particular sections of software code (Farrier, Id.).
Regarding claim 3, the rejection of claim 2 is incorporated, but Gabel in view of Pena Pena does not more particularly teach modifying at least a portion of generated documentation associated with the software code development based at least in part on the detected changes. However, Farrier does teach: modifying at least a portion of the generated documentation associated with the development of the at least one set of software code based at least in part on the one or more detected changes associated with the at least one set of software code (Farrier, e.g., ¶50, “collected data … Details of one or more commits may be gathered either via webhook … make an API call when a new commit is received in order to query a system of the invention to determine which test or tests to run.” See also, e.g., ¶52, “A machine learning model will eventually build a finer-grained mapping of individual tests to individual files and regions of the code base …” Examiner’s note: the documentation of Farrier comprises at least the mapping of tests to code, which is updated when new commit information is detected and the information is fed into the machine learning model) for the purpose of enhancing software development efficiency by intelligently identifying tests associated with newly submitted code commits and using iteratively updated commit and test data to more quickly identify and run tests and to identify appropriate developers for particular sections of software code (Farrier, e.g., ¶¶7-17).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for artificial intelligence-assisted software documentation prediction and generation as taught by Gabel in view of Pena Pena to provide for modifying at least a portion of generated documentation associated with the software code development based at least in part on the detected changes because the disclosure of Farrier shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for artificial intelligence-assisted code-to-test mapping generation and updating to provide for modifying at least a portion of generated documentation associated with the software code development based at least in part on the detected changes for the purpose of enhancing software development efficiency by intelligently identifying tests associated with newly submitted code commits and using iteratively updated commit and test data to more quickly identify and run tests and to identify appropriate developers for particular sections of software code (Farrier, Id.).
Claims 12-13 and 17-18 are rejected for the additional reasons given in the rejections of claims 2-3 above.
Response to Arguments
In the Remarks, Applicant Argues: Applicant traverses the rejections of the claims under 35 U.S.C. §§ 101, 102 and 103, but has amended the claims to expedite prosecution, and the claims as amended are eligible under 35 U.S.C. § 101 (Resp. at 8-12) and recite allowable subject matter under 35 U.S.C. §§ 102 and 103 in view of Gabel and Farrier (id. at 12-14).
Examiner’s Response: As indicated above, Examiner finds the claims as amended to be eligible under 35 U.S.C. § 101. In view of the amendments, Examiner newly cites to Pena Pena and maintains the rejections under the new grounds set forth in full above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
