DETAILED ACTION
This action is responsive to Remarks and Claim amendments filed on June 04, 2026.
Claims 1, 3-4, 6, 8-10, 14-16 and 18 have been amended.
Claims 1-20 are pending and are presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendments
The objection of claims 1-9 is withdrawn in view of applicant’s amendments.
Response to Arguments
Applicant’s arguments filed June 04, 2026 have been fully considered but are not persuasive. As an initial matter, Applicant’s arguments are directed principally to the Fanning-Vaezi-Shani combination as presented in the non-final Office Action. In view of Applicant’s amendment, the rejection has been recast as set forth below, with Vaezi as the primary reference and further in view of Fanning, Holl, and Byrd. Each of Applicant’s arguments is addressed below in the context of the rejection as now applied. I. Principle of operation. Applicant argues (Remarks, pages 2-5) that modifying Fanning’s static-analysis system with Vaezi’s dynamic execution would change Fanning’s principle of operation and render Fanning unsatisfactory for its intended purpose under In re Ratti and MPEP 2143.01. This argument is directed to a combination that no longer forms the basis of the rejection. As set forth below, the rejection is recast with Vaezi — which itself implements the virtual secured environment, executes the validation test, and deploys the validated code — as the primary reference. Fanning is relied upon only for the relevancy ranking and for recording feedback in a log. The rejection therefore does not modify Fanning’s static-analysis operation, does not replace Fanning’s core operating mechanism, and does not repurpose Fanning as a deployment system. Accordingly, the combination neither changes Fanning’s principle of operation nor renders Fanning unsatisfactory for its intended purpose, and the In re Ratti and MPEP 2143.01 arguments are moot. In the alternative and on the merits, the test for obviousness is not whether the features of one reference may be bodily incorporated into the structure of another, but what the combined teachings would have suggested to one of ordinary skill in the art. See In re Keller, 642 F.2d 413 (CCPA 1981); MPEP 2145. Adding runtime validation to a static-analysis tool does not destroy the static-analysis function; static and dynamic analysis are complementary techniques. Indeed, Fanning itself recognizes that static analyzers do not observe the runtime behaviors of a program and consequently reason over approximations that yield false positives (Fanning paragraph [0094]), which provides a reason to supplement static analysis with runtime validation rather than teaching away from it. II. The contention that Fanning already achieves the goal. Applicant argues (Remarks, page. 5) that Fanning already manages vulnerabilities through a success rate (Fanning paragraph [0163]) and that no improvement is needed. This argument is directed to the superseded motivation statement and primary reference. Under the recast rejection, the motivation does not rest on curing a deficiency in Fanning. Moreover, Fanning’s success rate is a retrospective quality metric computed across a large code base; it does not validate a specific replacement code change at runtime in an isolated environment prior to deployment, which is the function supplied by Vaezi. Fanning’s own acknowledgment of static-analysis false positives (paragraph [0094]) confirms a benefit to runtime validation. III. Reasoned motivation to combine. Applicant argues (Remarks, pages. 5-6), citing Cutsforth, Arendi, In re NuVasive, and Personal Web, that the motivation to combine is conclusory. The new grounds set forth express, non-conclusory motivations that explain how each combination works and why a person of ordinary skill would make it: conditioning deployment of a replacement code set on its measured likelihood of success and providing closed-loop learning that increases or decreases the safety ranking based on the test outcome (Holl), and providing additional testing proportional to the significance of the changed code so as to catch regressions in critical code before deployment (Byrd). These reasoned, evidence-supported explanations satisfy the cited authority. IV. “A high relevance ranking and a high safety ranking.” Applicant argues (Remarks, pages. 6-7) that Fanning paragraph [0083] discloses only a source code quality ranking and a relevance ranking and fails to teach “a high safety ranking.” Applicant’s reading of Fanning paragraph [0083] is acknowledged, and the recast rejection does not rely on Fanning for the safety ranking. Holl is applied to teach the safety ranking — a historical confidence score representing a probability of success associated with the code (Holl column 4 line 31 – column 5 line 6, column, column 15 lines 28-44) — its use to select the code for deployment when the score satisfies a threshold (Holl column 5 line 7-22, column 20 lines 59-63), and the updating of that ranking based on test feedback (Holl column 6 lines 1-31, column 15 lines 8-15). Fanning is relied upon for the relevancy ranking only (Fanning paragraphs [0066], [0083]). Applicant’s argument is therefore addressed by the rejection as now applied. V. The significance determination and conditional additional test. Applicant argues (Remarks, pages 7) that the amended limitations — determining whether the previous set of code is significant based on an interaction with one or more applications, and performing at least one additional test when significant — are not taught by the cited art. Byrd is applied to these limitations: Byrd determines whether changed code is significant based on its modeled interactions with other programming structures of the application (Byrd paragraphs [0011], [0018], [0022]) and recommends additional testing for significant code prior to deployment (Byrd paragraph [0011], [0017], [0042]). Applicant’s argument is therefore addressed. VI. Dependent Claims 6-9, 14-15, and 18. Applicant argues these claims are allowable solely by virtue of their dependence from allegedly allowable independent claims. Because the independent claims remain unpatentable for the reasons set forth above, the dependent claims fall with them. Bezzi, Yang, and Shao are maintained for the respective additional limitations of Claims 6-9, 14-15 and 18 as set forth below. VII. Request for Evidentiary Support. The rejection relies entirely on documentary prior-art references with pinpoint citations and does not rely on Official Notice, “common knowledge,” or facts within the Examiner’s personal knowledge. Accordingly, no citation or affidavit under MPEP 2144.03 and 37 CFR 1.104(d)(2) is required. For the foregoing reasons, Applicant’s arguments are not persuasive, and the rejections are maintained as recast below. Because the new grounds of rejection were necessitated by Applicant’s amendment, this action is properly made final.
Claim Objections
Claims 5-6 and 10-15 are objected to because of the following informalities: Claim 5 recites “wherein the one or more other components of the external source that hosts the application include at least a database.”. Please replace “system” to –external source-- and “includes” to –include--. Please amend the claim language as indicated in bold. Appropriate correction is required. Claim 10 recites “A method for implementing code changes, the method comprising:” Please amend the claim language as indicated in bold. Appropriate correction is required.
Dependent claims 6 and 11-15 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 (and similar for claims 10 and 16) recites the limitation “in response to determining that the previous set of code is significant, perform at least one additional test of the identified new set of code prior to sending the identified new set of code to the external source for implementation;” in lines 20-22. The limitation is unclear since the term “additional” presupposes a prior “test”, but the claim never recites a baseline “test”. For purpose of examination, “performing at least one additional test” will be interpreted as a “performing at least one test”.
Dependent claims 2-9, 11-15 and 17-20 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 10-13, 16-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vaezi et al. (US Pub. No. 2025/0328652, hereinafter Vaezi – previously presented) in view of Fanning et al. (US Pub. No. 2024/0095027, hereinafter Fanning – previously presented) in view of Holl et al. (US Pat. No. 11,943,131, hereinafter Holl) and further in view of Byrd (US Pub. No. 2019/0026108).
With respect to claim 1 (Currently Amended), Vaezi teaches a system for implementing code changes, comprising: a memory storing a code repository, the code repository storing one or more sets of replacement lines of code [[, each of the one or more sets of replacement lines of code having a relevancy ranking and a safety ranking;]] (Vaezi paragraphs [0044]-[0047] and [0110], a system having processors and electronic storages/memory; paragraph [0018], “the application may store new or modified containers and other modules within the sample codebase, which may be used for rebuilding… A sample codebase may be associated with a repository or a suitable storage system for code”; paragraph [0007], storing the rebuild code set and code sample in a container). Vaezi stores one or more sets of modified/replacement code in a code repository.) and a processor operably coupled to the memory and configured to: (Vaezi paragraph [0045] processors and control circuitry; paragraph [0110] “memory storing instructions that, when executed by the processors, cause the processors to effectuate operations”). receive a notice from an external source that a previous set of code associated with an application needs to be changed, wherein the external source hosts the application (Vaezi paragraph [0029], “In response to detecting a vulnerability associated with a given application, the system may determine, or obtain information relating to, one or more affected components”; paragraph [0040], the system transmits “a notification of any errors or test results associated with a vulnerability fix”. The detected vulnerability in the application hosted by the system is a notice that a previous set of code needs to be changed). identify a new set of code from the code repository [[based at least in part upon the new set of code having a high relevance ranking and a high safety ranking]], wherein the identified new set of code is from the one or more sets of replacement lines of code stored in the memory (Vaezi paragraph [0030], “the system may generate one or more modifications (e.g., vulnerability fixes to a code sample…)”; paragraph [0031], “the system may retrieve one or more of these code strings and modify the code sample of the container affected by the vulnerability accordingly”. Vaezi identifies the new (modified/replacement) set of code from the codebase). implement a virtual secured environment that comprises a simulation of the application and one or more other components of the external source that hosts the application, wherein in the simulation, the previous set of code is replaced with the identified new set of code (Vaezi paragraph [0036], “A test script may generate or simulate environments (e.g., container-specific or application-specific) in which to execute the tests”; paragraph [0038], “the system may execute the validation test in an environment specific to an application, a container, or another component of the system… isolated contexts”; paragraph [0067], rebuilding the container using the source code modified in response to the vulnerability. The isolated, application-/container-specific test environment running the rebuilt (replacement) code is the claimed virtual secured environment). [[in response to performing at least one additional test of the identified new set of code,]] receive feedback from the virtual secured environment, wherein the feedback includes an indication of whether the identified new set of code causes a failure, wherein the identified new set of code is indicated to cause the failure when a determination is made that the identified new set of code causes a security vulnerability or loss of function of one or more components of the simulation (Vaezi paragraph [0036], the test script provides “verification of whether a vulnerability has been successfully addressed, and/or if the modification generated other issues”; paragraph [0041], “a validation failure may include an indication that the validation test generated results that are incompatible with any expected results” and that a container or application is “incompatible with any applicable functionality or performance requirements”. The validation result is the feedback; an unaddressed vulnerability is the claimed security vulnerability and incompatibility with functionality requirements is the claimed loss of function). send the new set of code to the external source for implementation when the feedback does not indicate a failure (Vaezi paragraph [0036], “validation of any implemented modifications or fixes prior to deployment”; paragraph [0039], “the system may execute validation tests prior to deployment… deployment may include rollout or scaling, which may be continual and automated as in the case of a CI/CD system”; paragraph [0006], “subsequent deployment to the target environments”. Vaezi deploys the validated (passing) replacement code to the target environment). Vaezi is silent to disclose, however, in an analogous art, Fanning teaches:
each of the one or more sets of replacement lines of code having a relevancy ranking [[and a safety ranking]] (Fanning paragraph [0066], computing “a relevance score 408 of the first quality standard with respect to the first source code”; paragraph [0083], “a relevance ranking… based at least on relevance scores 408”; paragraph [0004], “ranking source codes based on a specified coding quality standard”).
identify a new set of code from the code repository based at least in part upon the new set of code having a high relevance ranking [[and a high safety ranking]] (Fanning paragraph [0052], “select 712 one of the conformant code instances 310 as a presentable recommendation 314”; paragraph [0024], ranking pieces of code to support “decisions such as… whether to update a given program’s code or replace it”. Fanning selects/recommends code based on its relevance/quality ranking).
record the feedback in a log (Fanning paragraph [0017], “Compilation attempt results, build attempt results, test results… are each also a part of the development history that could… be represented as data that is stored, indexed, and later retrieved”. Fanning records test results/feedback as stored, indexed data).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify Vaezi’s automated vulnerability-mediation system to associate a relevancy ranking with the stored replacement code sets, to select the new set of code based at least in part upon a high relevancy ranking, and to record the validation feedback in a log, as taught by Fanning, in order to objectively prioritize and select among candidate replacement code using quantitative relevance/quality metrics and to maintain an auditable record of development results, thereby improving the efficiency and reliability of the code-replacement decision (Fanning paragraphs [0024], [0026]). Vaezi in view of Fanning is silent to disclose, however, in an analogous art, Holl teaches:
each of the one or more sets of replacement lines of code having [[a relevancy ranking and]] a safety ranking (Holl column 4 line 49 – column 5 line 6, an automated response “includes… executable code (e.g., a code snippet)… that the device executes”; column 4 lines 31-48, “Historical confidence scores… represent historical probabilities of success of the automated responses”; column 15 lines 28-44, “confidence scores may be associated to a service catalog of predefined change types… such as upgrading software on a router… scoring the success/confidence of the service task”. Holl’s historical confidence score is a safety ranking associated with each stored set of replacement code).
identify a new set of code from the code repository based at least in part upon the new set of code having [[a high relevance ranking and]] a high safety ranking (Holl column 5 lines 7-22, “determines whether to deploy automated responses… based on historical confidence scores… compares the historical confidence scores 122 to the confidence thresholds”; column 20 lines 59-63, “determining to execute the automated response when evaluating the rule indicates that each historical probability exceeds or is equal to a corresponding one of the… thresholds”. Holl selects the code for deployment when its safety ranking (confidence score) is high, i.e., exceeds the threshold).
update the safety ranking of the identified new set of code stored in the code repository based on the feedback received from the virtual secured environment (Holl column 6 lines 1-31, “After the device executes the automated response… controller 104 performs a ‘complex confidence calculation’ to update/recompute the historical confidence scores… When the test results indicate that the service health improved… increases the historical confidence scores… when the… service health degraded… decreases the historical confidence scores”; column 15 lines 8-15, “when the test results indicate success, the controller increases each historical probability, and when the test results indicate failure, the controller decreases each historical probability”. Holl updates the stored safety ranking based on the test/validation feedback).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi and Fanning to associate a safety ranking, in the form of a historical confidence/probability-of-success score, with each stored replacement code set, to select the new set of code based at least in part upon a high safety ranking, and to update that safety ranking based on the feedback received from the test environment, as taught by Holl, in order to condition deployment of replacement code on its measured likelihood of success and to provide closed-loop learning that increases the score for code that succeeds and decreases it for code that fails or degrades the system, thereby improving the resilience and reliability of the automated code-replacement system and preventing repeat failures (Holl column 1 lines 25-37, column 2 lines 45-63, column 6 lines 49-60).
Vaezi in view of Fanning in view of Holl is silent to disclose, however, in an analogous art, Byrd teaches:
determine whether the previous set of code is significant based at least on an interaction between the previous set of code and one or more applications (Byrd paragraph [0011], “An application code graph may be generated in which the programming structures are represented by the nodes while their interactions are modeled as links. The importance of the programming structures may be determined based on the weights assigned to the nodes”; paragraph [0018], an edge “may represent the volume of data flow between two methods”; paragraph [0022], programming structures “indicated in the application code graph 102 as being of significant impact in the functioning of the application”. Byrd determines the significance of the previous code from its modeled interactions with other programming structures of the application). in response to determining that the previous set of code is significant, perform at least one additional test of the identified new set of code prior to sending the identified new set of code to the external source for implementation (Byrd paragraph [0011], “If an update to an application involves a programming structure that is critical to the functioning of the application, further testing may be recommended”; paragraph [0017], “Prior to deployment of the change to the source code, the ranking model 104 may be combined with the information regarding the change 106 in order to proactively predict the potential runtime impact”; paragraph [0022], “generate a recommendation 108 that additional testing is required”; paragraph [0042], “if… the programming structures are sufficiently important and the code change(s) significantly affect application performance, further testing of the code changes is recommended”. Byrd performs the additional testing for significant code prior to deployment).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi, Fanning, and Holl to determine whether the previous set of code is significant based on its interaction with one or more applications, and, in response, to perform at least one additional test of the identified new set of code prior to sending it for implementation, as taught by Byrd, in order to provide a testing context proportional to the importance of the changed code to the functioning of the application, thereby catching regressions in critical code before deployment and improving application performance and reliability (Byrd paragraphs [0010]-[0011], [0039]).
With respect to claim 2 (Original), Vaezi teaches wherein the new set of code is identified at least in part by using a trained machine learning system (Vaezi paragraph [0033]-[0034], “transmit an indication of the vulnerability… to an artificial intelligence model in order to generate the modified code sample… the artificial intelligence model may be trained on historic rebuild code sets and/or modified code samples”; paragraph [0065]).
With respect to claim 3 (Currently Amended), Vaezi teaches wherein the processor is further configured to:
identify an additional new set of code from the code repository when the feedback indicates that a failure occurs (Vaezi paragraph [0042], “in response to a validation failure… an enforcement action may include modifications to the modified code sample, including bug fixes… code refactoring”; paragraph [0072], the system “may modify the code sample further”). replace in the virtual secured environment, the previous set of code and the new set of code with the identified additional new set of code (Vaezi paragraphs [0072]-[0073], rebuilding the container utilizing the further-modified source code so that the prior code sample is replaced by the further-modified sample; paragraph [0067], “rebuild the container… utilizing source code modified in response to the detected vulnerability”). operate the application in the virtual secured environment with the identified additional new set of code (Vaezi paragraph [0036], re-executing the test script in the simulated environment; paragraph [0072], re-running the validation test on the rebuilt container). receive additional feedback from the virtual secured environment (Vaezi paragraphs [0040]-[0041], detecting “a validation confirmation or a validation failure” for the re-validation). send the additional new set of code to the external source for implementation when the additional feedback does not indicate a failure (Vaezi paragraph [0039], deploying the validated code “prior to deployment… rollout or scaling” upon a passing re-validation).
Vaezi in view of Holl in view of Byrd is silent to disclose; however, in an analogous art, Fanning teaches record the additional feedback in the log (Fanning paragraph [0017], “test results… stored, indexed, and later retrieved”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify Vaezi’s automated vulnerability-mediation system to associate a relevancy ranking with the stored replacement code sets, to select the new set of code based at least in part upon a high relevancy ranking, and to record the validation feedback in a log, as taught by Fanning, in order to objectively prioritize and select among candidate replacement code using quantitative relevance/quality metrics and to maintain an auditable record of development results, thereby improving the efficiency and reliability of the code-replacement decision (Fanning paragraphs [0024], [0026]).
With respect to claim 4 (Currently Amended), Vaezi in view of Holl in view of Byrd is silent to disclose; however, in an analogous art, Fanning teaches wherein the processor is further configured to assign the relevancy ranking [[and the safety ranking]] to each of the one or more sets of replacement lines of code based at least in part upon previous deployments of the one or more sets of replacement lines of code (Fanning paragraphs [0070]-[0072], the counts and rankings are obtained and “recalculated” at “multiple points… in time” based on then-current results of prior code events).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify Vaezi’s automated vulnerability-mediation system to associate a relevancy ranking with the stored replacement code sets, to select the new set of code based at least in part upon a high relevancy ranking, and to record the validation feedback in a log, as taught by Fanning, in order to objectively prioritize and select among candidate replacement code using quantitative relevance/quality metrics and to maintain an auditable record of development results, thereby improving the efficiency and reliability of the code-replacement decision (Fanning paragraphs [0024], [0026]).
Vaezi in view of Fanning in view of Byrd is silent to disclose, however, in an analogous art, Holl teaches wherein the processor is further configured to assign [[the relevancy ranking and]] the safety ranking to each of the one or more sets of replacement lines of code based at least in part upon previous deployments of the one or more sets of replacement lines of code (Holl column 4 lines 31-48, “system 100 recomputes or updates historical confidence scores 122 over time to indicate the historical success of the automated responses”; column 6 lines 32-48, “historically grades the confidence… based on prior impacts to service health”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi and Fanning to associate a safety ranking, in the form of a historical confidence/probability-of-success score, with each stored replacement code set, to select the new set of code based at least in part upon a high safety ranking, and to update that safety ranking based on the feedback received from the test environment, as taught by Holl, in order to condition deployment of replacement code on its measured likelihood of success and to provide closed-loop learning that increases the score for code that succeeds and decreases it for code that fails or degrades the system, thereby improving the resilience and reliability of the automated code-replacement system and preventing repeat failures (Holl column 1 lines 25-37, column 2 lines 45-63, column 6 lines 49-60).
With respect to claim 5 (Original), Vaezi teaches wherein the one or more other components of the system that hosts the application includes at least a database (Vaezi paragraph [0006], “web applications with an associated database functionality”; paragraph [0068], the test script tests “data entry or data extraction from a database associated with the container”).
With respect to Claims 10-13, the claims are directed to a method that recites limitations similar to the system of Claims 1-4, respectively, and are rejected for the same reasons set forth for Claims 1-4 above).
With respect to Claims 16-17 and 19-20, the claims are directed to a non-transitory computer-readable medium that recites limitations similar to the system of Claims 1-4, respectively, and are rejected for the same reasons set forth for Claims 1-4 above; wherein Vaezi also teaches such a medium (Vaezi paragraph [0096], “tangible, non-transitory, computer-readable media storing instructions”).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Vaezi et al. (US Pub. No. 2025/0328652, hereinafter Vaezi – previously presented) in view of Fanning et al. (US Pub. No. 2024/0095027, hereinafter Fanning – previously presented) in view of Holl et al. (US Pat. No. 11,943,131, hereinafter Holl) in view of Byrd (US Pub. No. 2019/0026108) and further in view of Bezzi et al. (US Pub. No. 2019/0347424, hereinafter Bezzi).
With respect to claim 6 (Currently Amended), Vaezi in view of Fanning in view of Holl in view of Byrd is silent to disclose, however, in an analogous art, Bezzi teaches wherein the memory includes a cache for at least temporarily storing data to be written to the database by the application until the new set of code is implemented (Bezzi paragraph [0037], “a commit history cache 224 repository where commits can be temporarily stored to reduce the number of connections to external repository to improve performance”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi, Fanning, Holl, and Byrd to include a cache for at least temporarily storing data until the new set of code is implemented, as taught by Bezzi, in order to reduce the number of external repository connections and improve performance (Bezzi paragraph [0037]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Vaezi et al. (US Pub. No. 2025/0328652, hereinafter Vaezi – previously presented) in view of Fanning et al. (US Pub. No. 2024/0095027, hereinafter Fanning – previously presented) in view of Holl et al. (US Pat. No. 11,943,131, hereinafter Holl) in view of Byrd (US Pub. No. 2019/0026108) and further in view of Yang et al. (US Pub. No. 2024/0028330, hereinafter Yang – previously presented).
With respect to claim 7 (Original), Vaezi in view of Fanning in view of Holl in view of Byrd is silent to disclose, however, in an analogous art, Yang teaches wherein the system further comprises two or more nodes that each host the application, and wherein sending the new set of code to the external source for implementation comprises deploying the new set of code to each of the two or more nodes that host the application (Yang paragraph [0066], “launching multiple different virtual machines to simulate the many different types of instances of a distributed application that together cooperate to implement the distributed application”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi, Fanning, Holl, and Byrd so that the system comprises two or more nodes that each host the application and the new set of code is deployed to each such node, as taught by Yang, in order to manage and validate code changes across the multiple instances of a distributed application in a resource-efficient manner (Yang paragraph [0066]).
Claims 8-9, 14-15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vaezi et al. (US Pub. No. 2025/0328652, hereinafter Vaezi – previously presented) in view of Fanning et al. (US Pub. No. 2024/0095027, hereinafter Fanning – previously presented) in view of Holl et al. (US Pat. No. 11,943,131, hereinafter Holl) in view of Byrd (US Pub. No. 2019/0026108) and further in view of Shao et al. (US Pub. No. 2021/0149793, hereinafter Shao – previously presented).
With respect to claim 8 (Currently Amended), Vaezi in view of Fanning in view of Holl in view of Byrd is silent to disclose, however, in an analogous art, Shao teaches wherein determining the previous set of code is significant is based at least on another interaction between the previous set of code and one or more devices (Shao paragraph [0020], the cognitive code coverage system provides “weights to code snippets… to factor in how much testing should be performed on a particular code snippet”; paragraph [0025], the significance/weight is derived from software metrics including “call references”; paragraph [0037], characteristics “indicative of a code snippet of higher priority”; FIG. 1 and paragraphs [0053]-[0054], the system operating across the computing devices that execute the code).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi, Fanning, Holl, and Byrd to determine that the previous set of code is significant based on another interaction between the previous set of code and one or more devices, as taught by Shao, in order to weight the testing importance of the code according to its interactions across the system, thereby ensuring that more significant code receives adequate testing (Shao paragraphs [0004], [0020]).
With respect to claim 9 (Currently Amended), Vaezi in view of Fanning in view of Holl in view of Byrd is silent to disclose, however, in an analogous art, Shao teaches wherein determining the previous set of code is significant is based at least in part by using a trained machine learning system (Shao Abstract, “training a machine learning model using the labeled dataset to output a code coverage weight for code snippets”; paragraphs [0020], [0036]; FIGS. 1-2, the machine learning model 160 outputs the priority-based weight).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the combination of Vaezi, Fanning, Holl, and Byrd to determine the significance of the previous set of code at least in part by using a trained machine learning system, as taught by Shao, in order to objectively and consistently determine the testing importance of the code without reliance on programming-language-specific predefined rules (Shao paragraphs [0003]-[0004]).
With respect to Claims 14-15, the claims are directed to a method that recites limitations similar to the system of Claims 8-9, respectively, and are rejected for the same reasons set forth for Claims 8-9 above.
With respect to Claim 18, the claim is directed to a non-transitory computer-readable medium that recites limitations similar to the system of Claim 8, and is rejected for the same reasons set forth for Claim 8 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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 at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights