Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This is the initial office action based on the application filed on March 6th, 2024, which claim 1-15 have been presented for examination.
Status of Claims
Claims 1-15 are pending in the application, of which claims 1, 4 and 9 are in independent form and these claims (1-15) are subject to following rejection(s) and/or objection(s) set forth in the following Office Action below.
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-15 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1:
Claims 1-8 are directed to a method and claims 9-15 are directed to a medium (product) and they fall into the statutory categories.
Step 2A Prong 1:
Claim 1 recites:
a). identifying a code release version;
b). retrieving a log of changes made to release code candidate implemented requirement identifier for each change;
c). retrieving planed requirement identifier the code release;
d). comparing both identifiers;
e). determining out-of-scope code is included in the code release version based on comparison;
f). reverting to prior version of the code version that does not include out-of-scope code change;
g). retaining or reapplying code changes for planned requirement identifier to the prior version of release candidate code base; and
h). deploying prior version of the release with the in-scope changes to a production environment;
Limitations (a)–(g) are limitations that, as drafted, are process steps that, under its broadest reasonable interpretations, covers performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “identifying”, “retrieving”, “determining”, “reverting”, “retaining”, “creating” can be performed in the human mind through observation, evaluation, judgement, opinion or can be performed with the aid of pen and paper. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Step 2A Prong 2:
The claim recites the additional elements, i.e., “computer program” and step (h) . However, “computer program” is recited at a high level of generality. Further, step (h) is insignificant extra solution activity. Accordingly, the claim as a whole does not integrate the exception into a practical application.
Step 2B:
The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception itself. Therefore, claim 1 is ineligible.
Claims 2 and 10 recite:
resolving conflicts between code release versions due to inclusion of in scope changes, which can be performed in the human mind through observation, evaluation, judgement, opinion with the aid of a human using a pen, marker and a paper, and presumably viewing and/or reviewing comment contents. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Claims 3 and 11 recite:
performing regression and integration tests recited elements in the claim are at a high level of generality, such concept directly falls into step 2A-prong one, while tiding to the generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. MPEP 2106.05. Therefore, claims 3 and 11 are ineligible.
Regarding independent claim 4:
Claim 4 is as same as claim 1 above except two additional limitation has been recited as follows:
a). creating a code merge request;
b). deploying merged code to a production environment;
-which invoke the same analysis as claim 1 above; thus, simply adding extra-solution activity or generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. MPEP 2106.05. Therefore, claim 4 is ineligible.
Claims 5-8 consecutively recite:
a). receives an identification of impacted software components impacted by implementing the missing in-scope change;
b). impacted software components implement the missing in-scope change;
c). requirement description and the acceptance criteria identify a desired outcome for implementing the missing in-scope change;
d). generating using an artificial intelligence engine and a large language model
limitations (a)-(d) are merely insignificant extra solution activity of receiving identification data and judging or realizing the impact due to code modifications. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
In regards to claim 9, when analyzing claim 9 it renders the same reasons as claim 1 above; therefore, claim 9 is rejected for the same reasons as claim 9 above.
In regards to claims 12-15 recite: recite:
a). receives identification of impacted software components due to missing in-scope change;
b). impacted software components implement the missing in-scope change;
c). requirement description and the acceptance criteria identify a desired outcome for implementing the missing in-scope change;
d). generating using an artificial intelligence engine and a large language model
limitations (a)-(d) are merely insignificant extra solution activity of receiving identification data and judging or realizing the impact due to code modifications. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
These limitations do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, this claim fails both Step 2A prong 2 and Step 2B. Therefore, claims 12-15 are ineligible.
Claims 1-15 when analyzed as a whole are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail(s) to establish that the claim(s) 1-15 are not directed to an abstract idea, or establish itself a tangible or physical system, or an apparatus, or a structure or an entity. The filed invention is merely an abstract concept or an idea.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Ying Qi (Chinese Patent Application Publication No. CN 111857796 A herein after Qi [translation provided with line no.]) in view of Wilson et al. (US Patent Application Publication No. US 2024/0338309 A1 herein after Wilson).
Per claim 1:
Qi discloses:
A method, comprising:
identifying, by a computer program, a code release version for a release candidate codebase (At least see lines 36-39 - integration of the version control tool auxiliary database version. frequently using the version control tool to control the version of the source code, such that the code library is included in the version change range);
retrieving, by the computer program, a log of changes made to the release candidate codebase and an implemented requirements identifier for each change (At least see line 56 - change log monitoring module is used for monitoring the change process of the database);
retrieving, by the computer program, planned requirements identifiers for the code release version from a code requirements database (At least see lines 174-176 - maintenance personnel changes the production environment according to the change content, the database version is updated, and the change log is logged in, which is convenient for tracing and changing record);
comparing, by the computer program, he implemented requirements identifiers and the planned requirements identifiers (At least see lines 161-164 - version comparison module is used for checking the difference point between the editions; The object of each version of the database, by viewing its change log, can view the modified history track. comparing the modified version of the object, checking the difference point of two editions);
Qi sufficiently discloses the method as set forth above, but Qi does not explicitly teach determining, by the computer program and based on the comparison, that an out-of-scope code change is included in the code release version; reverting, by the computer program, the code release version to a prior version of the release candidate codebase that does not include the out-of-scope code change; retaining or reapplying, by the computer program, in-scope code changes for the planned requirement identifiers to the prior version of the release candidate codebase; and
deploying, by the computer program, the prior version of the release candidate codebase with the in-scope changes to a production environment.
However, Wilson discloses:
determining, by the computer program and based on the comparison, that an out-of-scope code change is included in the code release version (At least see ¶[0055] - determine that the building of one or more artifacts has failed. The failure may be attributable to any number of different issues, including but not limited to, source code errors);
reverting, by the computer program, the code release version to a prior version of the release candidate codebase that does not include the out-of-scope code change (At least see ¶[0034] - a software application build is selected for deployment to functional acceptance test computing environment 128a and/or performance acceptance test computing environment 128b after the application build has passed functional testing and/or integration testing);
retaining or reapplying, by the computer program, in-scope code changes for the planned requirement identifiers to the prior version of the release candidate codebase (At least see ¶[0005] - promotes the application artifacts from the performance acceptance test computing environment to a production computing environment when operation of the application artifacts is validated in the performance acceptance test computing environment); and
deploying, by the computer program, the prior version of the release candidate codebase with the in-scope changes to a production environment (At least see ¶[0062] When build validation module 112 determines that testing of the application artifacts in functional test environment 126a is successful, build validation module 112 can transmit this indication to build deployment tool 112 to continue with the production deployment process).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 2:
Wilson also discloses:
resolving, by the computer program, conflicts in the prior version of the release candidate codebase with the in-scope changes (At least see ¶[0057] - candidate release build has encountered errors during functional acceptance testing and providing information for the user to determine what may be causing the issues and to attempt to resolve them).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 3:
Wilson also discloses:
performing, by the computer program, regression and integration tests on the prior version of the release candidate codebase with the in-scope changes (At least see ¶[0058] - security acceptance testing (e.g., verifying the software is secure against attacks and does not contain vulnerabilities) and/or regression acceptance testing).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Claims 4-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ying Qi (Chinese Patent Application Publication No. CN 111857796 A herein after Qi [translation provided with line no.]) in view of Wilson et al. (US Patent Application Publication No. US 2024/0338309 A1 herein after Wilson), and further in view of Avila et al. (US Patent Application Publication No. US 2024/0086183 A1 herein after Avila).
Per claim 4:
Qi discloses:
A method, comprising:
identifying, by a computer program, a code release version for a release candidate codebase (At least see lines 36-39 - integration of the version control tool auxiliary database version. frequently using the version control tool to control the version of the source code, such that the code library is included in the version change range);
retrieving, by the computer program, a log of changes made to the release candidate codebase and an implemented requirements identifier for each change (At least see line 56 - change log monitoring module is used for monitoring the change process of the database);
retrieving, by the computer program, planned requirements identifiers for the code release version from a code requirements database (At least see lines 174-176 - maintenance personnel changes the production environment according to the change content, the database version is updated, and the change log is logged in, which is convenient for tracing and changing record);
comparing, by the computer program, he implemented requirements identifiers and the planned requirements identifiers (At least see lines 161-164 - version comparison module is used for checking the difference point between the editions; The object of each version of the database, by viewing its change log, can view the modified history track. comparing the modified version of the object, checking the difference point of two editions);
Qi sufficiently discloses the method as set forth above, but Qi does not explicitly teach: identifying, by the computer program and based on the comparison, a missing in-scope code change that is not included in the code release version; receiving, by the computer program, a requirement description, acceptance criteria, and implementation prompts for the missing in-scope change; generating, by the computer program, code to implement the missing in-scope change using the requirement description for the missing in-scope change, the acceptance criteria, and the implementation prompts; creating, by the computer program, a code merge request to merge the code to implement the missing in-scope change with the code release version; and deploying, by the computer program, the merged code to a production environment.
However, Wilson discloses:
identifying, by the computer program and based on the comparison, a missing in-scope code change that is not included in the code release version (At least see ¶[0037] - ¶[0040] Release Applications (306)—a selection of the software applications (and/or modules, submodules, other components, etc.) to be included in the candidate release build (thus, module or submodules are not initially included in the release version) [emphasis added]);
receiving, by the computer program, a requirement description, acceptance criteria, and implementation prompts for the missing in-scope change (At least see ¶[0034] - a software application build is selected for deployment to functional acceptance test computing environment 128a and/or performance acceptance test computing environment 128b after the application build has passed functional testing and/or integration testing);
generating, by the computer program, code to implement the missing in-scope change using the requirement description for the missing in-scope change, the acceptance criteria, and the implementation prompts (At least see ¶[0050] - when a bug fix is implemented on a specific component, the user at client device 102 could select just the component where the bug fix is implemented); and
deploying, by the computer program, the merged code to a production environment (At least see ¶[0062] When build validation module 112 determines that testing of the application artifacts in functional test environment 126a is successful, build validation module 112 can transmit this indication to build deployment tool 112 to continue with the production deployment process).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Qi modified by Wilson sufficiently discloses the method as set forth above, but Qi modified by Wilson does not explicitly disclose: creating, by the computer program, a code merge request to merge the code to implement the missing in-scope change with the code release version.
However, Avila discloses:
creating, by the computer program, a code merge request to merge the code to implement the missing in-scope change with the code release version (At least see ¶[0028] - SCM techniques are employed to track a history of changes to a software code base and to resolve conflicts when merging updates from multiple software developers).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Avila into Qi modified by Wilson’s invention because a software development lifecycle comprises a process for planning, creating, testing, and deploying software code (e.g., associated with an application). Continuous integration (CI) generally allows development teams to merge and verify changes more often by automating software builds (e.g., converting source code files into standalone software components that can be executed on a computing device) and software tests, so that errors can be detected and resolved early; thus, lead to allows code changes that pass an automated testing phase to be automatically released into a production environment, thus making the changes visible to end user (see ¶[0016]).
Per claim 5:
Avila also discloses:
receives an identification of impacted software components impacted by implementing the missing in-scope change (At least see ¶[0019] - unique identifier values for the different software code versions can be compared to detect an unexpected, untested and/or anomalous version of the software code).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Avila into Qi modified by Wilson’s invention because a software development lifecycle comprises a process for planning, creating, testing, and deploying software code (e.g., associated with an application). Continuous integration (CI) generally allows development teams to merge and verify changes more often by automating software builds (e.g., converting source code files into standalone software components that can be executed on a computing device) and software tests, so that errors can be detected and resolved early; thus, lead to allows code changes that pass an automated testing phase to be automatically released into a production environment, thus making the changes visible to end user (see ¶[0016]).
Per claim 6:
Wilson also discloses:
impacted software components implement the missing in-scope change (At least see ¶[0037] - ¶[0040] Release Applications (306)—a selection of the software applications (and/or modules, submodules, other components, etc.) to be included in the candidate release build (thus, module or submodules are not initially included in the release version) [emphasis added]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 7:
Wilson also discloses:
requirement description and the acceptance criteria identify a desired outcome for implementing the missing in-scope change (At least see ¶[0029] - bug and issue tracking, incident ticket management, project dependency and metadata control, project deployment status).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 8:
Wilson also discloses:
code to implement the missing in-scope change is generated using an artificial intelligence engine and a large language model (At least see ¶[0053] - object configuration file is a Project Object Model (POM) file (e.g., pom.xml) used by Apache Maven to build the selected software applications Module 114 can automatically update the POM file(s) associated with the selected software applications).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 9:
Qi discloses:
A non-transitory computer readable storage medium, including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising:
identifying a code release version for a release candidate codebase (At least see lines 36-39 - integration of the version control tool auxiliary database version. frequently using the version control tool to control the version of the source code, such that the code library is included in the version change range);
retrieving a log of changes made to the release candidate codebase and an implemented requirements identifier for each change (At least see line 56 - change log monitoring module is used for monitoring the change process of the database);
retrieving planned requirements identifiers for the code release version from a code requirements database (At least see lines 174-176 - maintenance personnel changes the production environment according to the change content, the database version is updated, and the change log is logged in, which is convenient for tracing and changing record);
comparing the implemented requirements identifiers and the planned requirements identifiers (At least see lines 161-164 - version comparison module is used for checking the difference point between the editions; The object of each version of the database, by viewing its change log, can view the modified history track. comparing the modified version of the object, checking the difference point of two editions);
Qi sufficiently discloses the method as set forth above, but Qi does not explicitly teach: determining, based on the comparison, that an out-of-scope code change is included in the code release version; reverting the code release version to a prior version of the release candidate codebase that does not include the out-of-scope code change; retaining or reapplying in-scope code changes for the planned requirement identifiers to the prior version of the release candidate codebase; identifying, based on the comparison, a missing in-scope code change that is not included in the code release version; receiving a requirement description, acceptance criteria, and implementation prompts for the missing in-scope change; generating code to implement the missing in-scope change using the requirement description for the missing in-scope change, the acceptance criteria, and the implementation prompts; creating a code merge request to merge the code to implement the missing in-scope change with the prior version of the release candidate codebase with the in-scope changes to a production environment; and deploying the merged code to a production environment.
However, Wilson discloses:
determining, based on the comparison, that an out-of-scope code change is included in the code release version (At least see ¶[0037] - ¶[0040] Release Applications (306)—a selection of the software applications (and/or modules, submodules, other components, etc.) to be included in the candidate release build (thus, module or submodules are not initially included in the release version) [emphasis added]);
reverting the code release version to a prior version of the release candidate codebase that does not include the out-of-scope code change (At least see ¶[0034] - a software application build is selected for deployment to functional acceptance test computing environment 128a and/or performance acceptance test computing environment 128b after the application build has passed functional testing and/or integration testing);
retaining or reapplying in-scope code changes for the planned requirement identifiers to the prior version of the release candidate codebase (At least see ¶[0034] - a software application build is selected for deployment to functional acceptance test computing environment 128a and/or performance acceptance test computing environment 128b after the application build has passed functional testing and/or integration testing);
identifying, based on the comparison, a missing in-scope code change that is not included in the code release version (At least see ¶[0037] - ¶[0040] Release Applications (306)—a selection of the software applications (and/or modules, submodules, other components, etc.) to be included in the candidate release build (thus, module or submodules are not initially included in the release version) [emphasis added]);
receiving a requirement description, acceptance criteria, and implementation prompts for the missing in-scope change (At least see ¶[0034] - a software application build is selected for deployment to functional acceptance test computing environment 128a and/or performance acceptance test computing environment 128b after the application build has passed functional testing and/or integration testing);
generating code to implement the missing in-scope change using the requirement description for the missing in-scope change, the acceptance criteria, and the implementation prompts (At least see ¶[0050] - when a bug fix is implemented on a specific component, the user at client device 102 could select just the component where the bug fix is implemented); and
deploying, by the computer program, the merged code to a production environment (At least see ¶[0062] When build validation module 112 determines that testing of the application artifacts in functional test environment 126a is successful, build validation module 112 can transmit this indication to build deployment tool 112 to continue with the production deployment process).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Qi modified by Wilson sufficiently discloses the method as set forth above, but Qi modified by Wilson does not explicitly disclose: creating, by the computer program, a code merge request to merge the code to implement the missing in-scope change with the code release version.
However, Avila discloses:
creating, by the computer program, a code merge request to merge the code to implement the missing in-scope change with the code release version (At least see ¶[0028] - SCM techniques are employed to track a history of changes to a software code base and to resolve conflicts when merging updates from multiple software developers).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Avila into Qi modified by Wilson’s invention because a software development lifecycle comprises a process for planning, creating, testing, and deploying software code (e.g., associated with an application). Continuous integration (CI) generally allows development teams to merge and verify changes more often by automating software builds (e.g., converting source code files into standalone software components that can be executed on a computing device) and software tests, so that errors can be detected and resolved early; thus, lead to allows code changes that pass an automated testing phase to be automatically released into a production environment, thus making the changes visible to end user (see ¶[0016]).
Per claim 10:
Wilson also discloses:
resolve, by the computer program, conflicts in the prior version of the release candidate codebase with the in-scope changes (At least see ¶[0057] - candidate release build has encountered errors during functional acceptance testing and providing information for the user to determine what may be causing the issues and to attempt to resolve them).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 11:
Wilson also discloses:
perform, by the computer program, regression and integration tests on the prior version of the release candidate codebase with the in-scope changes (At least see ¶[0058] - security acceptance testing (e.g., verifying the software is secure against attacks and does not contain vulnerabilities) and/or regression acceptance testing).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 12:
Avila also discloses:
receives an identification of impacted software components impacted by implementing the missing in-scope change (At least see ¶[0019] - unique identifier values for the different software code versions can be compared to detect an unexpected, untested and/or anomalous version of the software code).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Avila into Qi modified by Wilson’s invention because a software development lifecycle comprises a process for planning, creating, testing, and deploying software code (e.g., associated with an application). Continuous integration (CI) generally allows development teams to merge and verify changes more often by automating software builds (e.g., converting source code files into standalone software components that can be executed on a computing device) and software tests, so that errors can be detected and resolved early; thus, lead to allows code changes that pass an automated testing phase to be automatically released into a production environment, thus making the changes visible to end user (see ¶[0016]).
Per claim 13:
Wilson also discloses:
impacted software components implement the missing in-scope change (At least see ¶[0037] - ¶[0040] Release Applications (306)—a selection of the software applications (and/or modules, submodules, other components, etc.) to be included in the candidate release build (thus, module or submodules are not initially included in the release version) [emphasis added]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 14:
Wilson also discloses:
requirement description and the acceptance criteria identify a desired outcome for implementing the missing in-scope change (At least see ¶[0029] - bug and issue tracking, incident ticket management, project dependency and metadata control, project deployment status).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
Per claim 15:
Wilson also discloses:
code to implement the missing in-scope change is generated using an artificial intelligence engine and a large language model (At least see ¶[0053] - roject configuration file is a Project Object Model (POM) file (e.g., pom.xml) used by Apache Maven to build the selected software applications Module 114 can automatically update the POM file(s) associated with the selected software applications).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wilson into Qi’s invention because teaching beneficially capture application performance and functionality information at many different stages of software development and testing and in several different testing environments. The captured information is retained at each deployment level and ready to be retrieved via user interface, and the capability is designed such a way that future compliance requirements can be quickly and efficiently integrated into the system, so as to avoid being limited to current tools and compliance efforts (see ¶[0004]).
CONCLUSION
Prior arts made of record are considered pertinent to applicant's disclosure. See MPEP § 707.05 For Examples:
Sridhara et al. (US 20210271466 A1) discloses “Step 502 may include performing a static analysis on source code of (i) the first version of the dependency and (ii) each of the plurality of upgrade candidates. Step 502 may include obtaining documentation information associated with the first version of the dependency and documentation information associated with each of the plurality of upgrade candidates; and performing an automated textual analysis of the obtained documentation information. Step 504 may include classifying the complexity of patching the identified one or more sections of code of the software application. Step 504 may be performed for each of the upgrade candidates, and the process may include steps of: ranking the upgrade candidates based at least in part on the classifying; and outputting a list of said upgrade candidates, based on said ranking, to a human-computer interface. Step 506 may be performed in response to user input with respect to at least one of the upgrade candidates in the list. The process in FIG. 5 may include a step of, in response to user input with respect to at least one of the upgrade candidates in the list, outputting information associated with the one or more sections of code of the software application that need to be patched in order to be compatible with the at least one upgrade candidate” (please see ¶[0031]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZIAUL A. CHOWDHURY whose telephone number is (571)270-7750. The examiner can normally be reached on 9:30PM 6:30PM Monday -Friday.
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, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Status information for published applications may be obtained from Patent Public Search tool (for all users) – A link to the Patent Public Search Tool is available at www. Uspto.gov/PatentPublicSearch. To find a U.S. patent or U.S. patent application publication, open the Patent Public Search tool by selecting “Start search”. Type the U.S. patent or U.S. patent application publication number in the “Search” panel without any punctuation and followed by an”.pn.”.
Should you have questions on access to the system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/ZIAUL A CHOWDHURY/ Primary Examiner, Art Unit 2192