DETAILED ACTION
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 § 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.
Claims 1, 7, 10, 16, 19 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Sutter et al. (US PGPUB 2005/0071810; hereinafter “Sutter”) in view of Zaidi et al. (US PGPUB 2018/0349119; hereinafter “Zaidi”), Goldin et al. (US PGPUB 2014/0068569; hereinafter “Goldin”), Saha et al. (US PGPUB 2020/0201741; hereinafter “Saha”), Zhang et al. (US PGPUB 2024/0256423; hereinafter “Zhang”) and Ganesan et al. (US Patent 11,726,902; hereinafter “Ganesan”).
Claim 1: (Currently Amended)
Sutter teaches a method for providing a source code with predictable performance characteristics, the method comprising:
performing a static analysis on the source code to identify one or more functions of the source code and a type associated with each of the one or more functions ([0055] “Static Analysis” [0056] “In the present invention, the analysis is designed to take into account all necessary interface-compatibility, type-correctness and run-time behavior preservation requirements, as introduced in Section above Static Analysis,” wherein Paragraphs [0042]-[0049] of Sutter describe that the “Static Analysis” operations include determination of “types” associated with various “methods”, i.e. “functions”. [0172] “6. Optimization of the container for the type of objects stored in them, if static analysis can determine these types.”);
performing a dynamic analysis on the source code by executing the source code and capturing telemetry data for the execution of each of the one or more functions ([0051] “In order to determine the usage characteristics of the various objects created by an application, the program is instrumented. This instrumentation involves nothing more than replacing standard classes with customized versions that gather statistics about the number of objects allocated, the number of times each method is called, etc. The instrumented program is then executed on some representative input data and profile information is collected,” wherein “instrumentation” is a type of “dynamic analysis”.); and
remediating the one of the one or more functions ([0054] “A combination of static analysis information and points-to information is used to drive several optimizations such as lazy allocation, caching of the last retrieved item, selecting non-default initial sizes and growth strategies, optimizing access operations for situations where containers often remain empty, and several others.” [0177] “In addition to the profiling statistics discussed in Section Instrumentation above, static analysis information is used to detect situations where certain methods are never invoked on a container object that originates from a given allocation site A. This information is used to remove methods and fields from the custom class used at A. The bookkeeping fields used for implementing fail-fast iterators are an example of a situation where this is useful. Other optimizations that rely on static analysis information are the specialization of a container's element type, and finalization of a containers methods and fields.”).
With further regard to Claim 1, Sutter does not teach the following, however, Zaidi teaches:
defining a threshold minimum number of times for execution of the one or more functions of the source code to collect an adequate data set of telemetry data for the one or more functions ([0036] “at block 402, the captured API trace is run on the GPU. In an embodiment, the captured API trace is repeatedly replayed on the GPU, for example, by a replayer application, to generate enough samples.” [0041] “the replayer could stop after the API trace is run a specified number of times”);
wherein the captured telemetry data includes an execution time associated with each of the one or more functions ([0027] “The shader program 310 may consist of one or more clauses, for example, clauses A, B, C as shown. A clause is a sequence of instructions that are guaranteed to execute from the start to end without an interruption,” wherein the “clauses” are the “one or more functions”. [0045] “At block 503, the execution duration for the sequences of uninterrupted instructions identified at block 502 is calculated.” [0064] “Finally, at block 509, the time generated based on the timestamps assigned by the hardware (e.g., in ‘GPU cycles’ or clock periods) are converted to real GPU time… to obtain the real GPU time, performance counters may be used separately to determine the GPU time spent per GPU command.”) and
wherein the dynamic analysis includes execution of the one or more functions of the source code at least the threshold minimum number of times ([0041] “At block 406, a determination is made as to whether the repeated running of the API trace on the GPU has provided enough samples for analysis. For example, at block 407, the replayer could stop after the API trace is run a specified number of times or for a certain amount of time”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter with the specified execution quantity as taught by Zaidi in order to “insure that the sample buffer 340 receives enough samples from the driver in order to provide accurate shader profiling results” (Zaidi [0041]).
With further regard to Claim 1, Sutter in view of Zaidi does not teach the following, however, Goldin teaches:
capturing a state of the processor before and after the execution of each of the one or more functions, and a state of the memory before and after the execution of each of the one or more functions ([0018] “The profiler can receive the directive or directives, identify the section of code specified in the directive(s) and can dynamically instrument that section of code in the target application process. When the instrumented code is executed, the code path can be detoured from the un-instrumented, original code path, instead invoking the profiler.” [0024] “The term ‘detouring’ as used herein refers to deviating from an original code path of a segment of code (function, block, group of instructions, or instruction) to a different code path which performs an action or action involved in collection of the specified information… both before and after the original code path of the segment of code is performed. For example, suppose the user directives 118 indicate that current state of certain variables are to be collected whenever the function foo is called in user code such as user code 120 executing in a target application process,” wherein the “state of certain variables” are representative of “a state of the memory”. [0025] “The user directed profiler 106 may trigger activity that results in collection of stack information and may log the collection of stack information or any other information the user directed profiler 106 can collect,” wherein “stack information” is one type of information which represents “a state of the processor”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi with the captured state information as taught by Goldin in order “to help a developer optimize a program” (Goldin [0015]).
With further regard to Claim 1, Sutter in view of Zaidi and Goldin does not teach the following, however, Saha teaches:
calculating a source code execution variability score for each of the one or more functions based at least in part on the execution time, the state of the processor before and after execution, and the state of the memory before and after execution, and the type associated with each of the one or more functions ([0019] “the program 110 may be sliced into statements that are distinct or separate from lines of code, such that a given statement may cover multiple lines of code and/or only be a portion of a line of code… such slicing may be done in a static fashion, such that statements are identified based on control flow and/or data flow analyses. Additionally or alternatively, the slicing of the program may be performed in a dynamic fashion, such that the statements are identified based on the data dependency from execution. Thus, while referred to as lines of code, any such portion or slice of the program 110 is contemplated as being analyzed to determine whether such a portion includes a fault.” [0026] “the risk score for a given line of code may be based on a number of factors…Various examples of determining the risk score may be described with reference to FIG. 4,” wherein the “risk score”, i.e. the “variability score”, is based on “factors” which include the different types of captured data discussed by Sutter, Zaidi and Goldin above.); and
based on a determination that the source code execution variability score associated with one of the one or more functions is above a threshold value, remediating the one of the one or more functions ([0027] “the fault locator 130 may use the risk scores to identify fault locations within the program 110. For example, the fault locator 130 may identify lines of code with risk scores above a threshold as being locations of faults within the program 110.” [0029] “the fault corrector 150 may operate to correct or otherwise replace lines of code with an associated risk score above a threshold,” wherein the process to “replace lines of code” is the “remediating”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi and Goldin with the score and threshold determination as taught by Saha in order to provide “an increase in computer efficiency and the preservation of computing resources… [since] by using the improved approaches described in the present disclosure, fewer false positives… are produced such that fewer lines of code must be analyzed or replaced by such an automated system” (Saha [0015]).
With further regard to Claim 1, Sutter in view of Zaidi, Goldin and Saha does not teach the following, however, Zhang teaches:
wherein the remediation includes prompting a large language model to create an alternative version of the one or more functions and updating the source code by replacing the one or more functions with the alternative version ([0071] “a software development process of repairing software includes: obtaining a source code; formulating a series of prompts based on at least the source code; submitting the prompts to a large language machine learning model; receiving responses from the model; and correcting errors or omissions in the source code based on the responses.” [0086] “Some embodiments automatically repair mistakes in students' programming assignments using a large language model trained on code (LLMC).”),
wherein the alternative version of the one or more functions generated by the large language model is validated by executing the alternative version and comparing its execution variability score to the threshold value ([0105] “As shown in FIG. 6, the student's buggy program first enters a syntax repair phase 304… The LLMC then generates repair candidates, which are validated by the syntax oracle.” [0115] “Some embodiments use the instructor's test suite (consisting of inputs and expected outputs) as the semantic oracle. A program has been repaired if it produces the expected outputs for the given inputs,” wherein the “expected outputs” are outputs which are more consistent, as taught by Ganesan below, thereby yielding code with a lower “execution variability score”, i.e. the “risk score” as taught above Saha.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin and Saha with the remediating using a large language model as taught by Zhang in order “to perform a source code improvement process to improve a first version of a source code” (Zhang [0063]) and further wherein “Using an LLMC removes the need for custom symbolic repair logic or retraining of a new neural model, and it allows MMAPR to handle both syntactic and semantic mistakes” (Zhang [0083]).
With further regard to Claim 1, Sutter in view of Zaidi, Goldin, Saha and Zhang does not teach the following, however, Ganesan teaches:
wherein the alternative version is generated to reduce the source code execution variability score (Col. 7 Ln. 51-55: “The consistency checker 258 repeatedly executes input bots using, for example, the same sample of tasks or actions, such as some or all of the inputs generated by the scenario simulator 256, to check for consistency of behavior and/or output.” Col. 8 Ln. 36-40: “The benchmarking logic can include, for example, a score or combination of scores based on results of executing other modules such as… the consistency checker 258.” Col. 8 Ln. 25-27: “the recommendations can indicate a specific coding change (e.g., a formula for translating or replacing a code section),” wherein “replacing a code section” performed in Ganesan in order to improve the “consistency of behavior and/or output”, i.e. to “reduce the source code execution variability score”, wherein the “source code execution variability score” is taught above Saha.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha and Zhang with the remediating using a large language model as taught by Ganesan in order to “provide for more efficient execution of the functionality and/or correction of bugs” (Ganesan Col. 9 Ln. 41-42).
Claim 7:
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Zhang and Ganesan does not teach the following, however, Saha teaches:
wherein a type of remediation performed is based at least in part on a difference between the source code execution variability score and the threshold value ([0027] “the fault locator 130 may use the risk scores to identify fault locations within the program 110. For example, the fault locator 130 may identify lines of code with risk scores above a threshold as being locations of faults within the program 110.” [0029] “the fault corrector 150 may operate to correct or otherwise replace lines of code with an associated risk score above a threshold,” wherein when the “difference” between the “score” and the “threshold” indicates that the “score” is less than the “threshold” then the “type of remediation performed” is ‘none’ and when the “score” is greater than the “threshold” then the “type of remediation performed” is the ‘replacement of lines of code’ as taught above in Saha.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Zhang and Ganesan with the remediation as taught by Saha in order to provide “an increase in computer efficiency and the preservation of computing resources… [since] by using the improved approaches described in the present disclosure, fewer false positives… are produced such that fewer lines of code must be analyzed or replaced by such an automated system” (Saha [0015]).
Claims 10 and 16:
With regard to Claims 10 and 16, these claims are equivalent in scope to Claims 1 and 7 rejected above, merely having a different independent claim type, and as such Claims 10 and 16 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 7.
With further regard to Claim 10, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Sutter reference also anticipates these additional elements of Claim 10, for example, Sutter teaches:
A computing system having a memory having computer readable instructions and one or more processors for executing the computer readable instructions, the computer readable instructions controlling the one or more processors to perform operations ([0205] “The processing system according to a preferred embodiment of the present invention can be realized in a centralized fashion in one computer system.” [0208] “An example of a computer system 1200 is shown in FIG. 12. The computer system 1200 includes one or more processors, such as processor 1204.” [0213] “Computer programs (also called computer control logic) are stored in main memory 1206 and/or secondary memory 1212… Such computer programs, when executed, enable the computer system 1200 to perform the features of the present invention as discussed herein”)
Claim 19:
With regard to Claim 19, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 19 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 19, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Sutter reference also anticipates these additional elements of Claim 19, for example, Sutter teaches:
A computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform operations ([0207] “A computer system may include, inter alia, one or more computers and at least a computer readable medium.” [0212] “The terms ‘computer program medium,’ ‘computer usable medium,’ and ‘computer readable medium’ are used to generally refer to media such as main memory 1206 and secondary memory 1212.” [0213] “Computer programs (also called computer control logic) are stored in main memory 1206 and/or secondary memory 1212… Such computer programs, when executed, enable the computer system 1200 to perform the features of the present invention as discussed herein”).
Claim 24: (New)
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Zhang and Ganesan does not teach the following, however, Saha teaches:
wherein the remediation comprises providing the one or more functions to a software developer together with the calculated source code execution variability score for manual review and replacement ([0028] “the output 140 may include a listing of each of the lines of code sorted by risk score such that the lines of code most likely to include a fault are listed at the top of the set of lines of code. The output 140 may additionally or alternatively include the numerical values calculated for the risk scores.” [0031] “the human operator 160 may be presented with the output 140 and may utilize the fault corrector 150 to replace or modify one or more lines of the program 110 manually to address the faults located within the output 140. For example, the human operator 160 may manually retype certain lines of code, may be presented with suggested lines of code or suggested edits to certain lines of code, etc.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Zhang and Ganesan with the remediation as taught by Saha in order to provide “an increase in computer efficiency and the preservation of computing resources… [since] by using the improved approaches described in the present disclosure, fewer false positives… are produced such that fewer lines of code must be analyzed or replaced by such an automated system” (Saha [0015]).
Claims 2, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claims 1, 10 and 19 above, and further in view of Lin et al. (US Patent 11,503,061; hereinafter “Lin”).
Claim 2:
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Lin teaches:
wherein the remediating the one of the one or more functions comprises automatically replacing a portion of the one of the one or more functions with a suitable alternative that has a lower variability score than the portion (Col. 9 Ln. 19: “the remediation planning system 220 outputs a selection of the best remediation plans 266, which is determined based on the risk score reductions or rank metrics.” Col. 18 Ln. “Field 824 shows the resulting risk scores that were obtained after application of each remediation plan. For example, by applying the first plan (just action [A]), the risk score of the XYZ server fleet will be reduced from 0.88 to 0.32”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the lowering of a score as taught by Lin in order “to programmatically determine remediation plans with the optimal balance of security gains and associated costs” (Lin Col. 5 Ln. 9).
Claims 11 and 20:
With regard to Claims 11 and 20, these claims are equivalent in scope to Claim 2 rejected above, merely having a different independent claim type, and as such Claims 11 and 20 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 2.
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claims 1 and 10 above, and further in view of Shani et al. (US PGPUB 2017/0031800; hereinafter “Shani”).
Claim 3:
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Shani teaches:
wherein the dynamic analysis includes performing an analysis of a variance of the captured telemetry data ([0001] “A code metric can be a dynamic metric (measuring the execution of code).” [0010] “A widely used code metric for tracking and managing software project expectations, progress, quality, and flexibility is a code complexity metric… that estimate the variance level of execution paths, inputs, outputs and other aspects of a written code unit.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the analysis as taught by Shani since “Such code metrics can be useful tools in tracking and managing software project expectations, progress, quality, and flexibility” (Shani [0001]).
Claim 12:
With regard to Claim 12, this claim is equivalent in scope to Claim 3 rejected above, merely having a different independent claim type, and as such Claim 12 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 3.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claims 1 and 10 above, and further in view of Thomson et al. (US PGPUB 2011/0161918; hereinafter “Thomson”).
Claim 6:
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Thomson teaches:
wherein the source code execution variability score is between zero and one and is based on a combination of a standard deviation of the captured telemetry data, a skew of the captured telemetry data, and a kurtosis of the captured telemetry data ([0534] “The data generation function allows the developer to define probability distributions in two ways: Firstly, it provides the possibility to display a probability chart for supplied parameters and thus makes it easier for the developer to imagine what the generated values would be. Secondly it provides hints for the more complex probability distributions, i.e. Skew and Kurtosis properties where the values are constrained by the values of the lower level moments.” [0543] “The types of probability distribution that can be applied to a Date-Time Data object include:” [0544] “Normal, defined by minimum, maximum, mean and standard deviation values”. [0545] “Normal Skew Kurtotic, a normal distribution having third and fourth central moment values as additional parameters”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the further analysis processes as taught by Thomson since “it provides the possibility to display a probability chart for supplied parameters and thus makes it easier for the developer to imagine what the generated values would be” (Thomson [0534]).
Claim 15:
With regard to Claim 15, this claim is equivalent in scope to Claim 6 rejected above, merely having a different independent claim type, and as such Claim 15 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 6.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claims 1 and 10 above, and further in view of Kulkarni et al. (US PGPUB 2020/0379975; hereinafter “Kulkarni”).
Claim 8:
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Kulkarni teaches:
wherein executing the source code includes executing the source code in a cloud computing environment ([0021] “In embodiments of the present invention, program code of an online transaction processor utilizes existing infrastructure in one or more resources of a distributed computing environment, such as a cloud computing environment.”) and
receiving application program interface (API) calls to perform the one or more functions ([0042] “action by the program code is initiated responsive to the program code obtaining a request, via an API 240, from a business applications 210 running of the OS 220.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the method as taught by Kulkarni in order to “take advantage of hardware and software features of the resources of the distributed computing system into which they are implemented” (Kulkarni [0037]).
Claim 17:
With regard to Claim 17, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 17 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang, Ganesan and Kulkarni as applied to Claims 8 and 17 above, and further in view of Abuelsaad et al. (US PGPUB 2013/0173781; hereinafter “Abuelsaad”).
Claim 9:
Sutter in view of Zaidi, Goldin, Saha, Zhang, Ganesan and Kulkarni teaches all the limitations of claim 8 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang, Ganesan and Kulkarni does not teach the following, however, Abuelsaad teaches:
wherein the threshold value is based at least in part on a network traffic value in the cloud computing environment ([0004] “an approach for activity-based virtual machine (VM) availability in a networked computing environment (e.g., a cloud computing environment) … Based on the contents of the network packets, the system may determine which applications/processes on particular VMs that are associated with the traffic. Users of this system may configure rules and thresholds (e.g., based on traffic of a specific type, traffic bound for a specific type of application running on a server, etc.).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang, Ganesan and Kulkarni with the threshold based on traffic as taught by Abuelsaad so that “capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in” (Abuelsaad [0027]).
Claim 18:
With regard to Claim 18, this claim is equivalent in scope to Claim 9 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 9.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claim 1 above, and further in view of Hooker et al. (US PGPUB 2016/03500228; hereinafter “Hooker”).
Claim 21: (New)
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Hooker teaches:
wherein the telemetry data further includes a state of the processor cache before and after the execution of each of the one or more functions ([0223] “At block 3604, the program is instrumented to analyze characteristics related to configurable aspects of the processor such as cache memory mappings, prefetcher MAT scores, and cache configuration modes. Examples of the characteristics include cache hit rate, branch prediction accuracy, working set size, average cache line lifetime, and cache pollution (e.g., the number of cache lines prefetched but never used).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the captured data including a state of the processor cache as taught by Hooker in order “to determine good configurations, or mappings, of configurable aspects of the processor, such as its cache memory or prefetchers” (Hooker [0221]).
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claim 1 above, and further in view of Brown et al. (US PGPUB 2022/0391308; hereinafter “Brown”).
Claim 22: (New)
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Brown teaches:
wherein the static analysis comprises performing an entity analysis to determine the proportion of code types, loops, declarations, and primitives in the source code ([0069] “at least one of the following information are captured for each method call: whether the corresponding method is static, whether the corresponding method is abstract, whether the corresponding method has a void type, method return information for the corresponding method (e.g., whether the corresponding method returns anything, the data type returned by the corresponding method, and/or the like), method argument parameter information for any argument parameters of the corresponding method, method variable name information for any variables declared in the corresponding method, method variable data type information for any variables declared in the corresponding method, method object declaration information for any object declarations in the corresponding method, method loop information for any loops in the corresponding method, method conditional statement information for any conditional statements in the corresponding method, and/or the like.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the captured data including a state of the processor cache as taught by Brown in order to “improve the operational reliability and computational efficiency of software solutions which are generated using unit testing techniques” (Brown [0020]).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan as applied to Claim 1 above, and further in view of Dean et al. (US PGPUB 2016/0357660; hereinafter “Dean”).
Claim 23: (New)
Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan teaches all the limitations of claim 1 as described above. Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan does not teach the following, however, Dean teaches:
wherein the dynamic analysis includes identifying a type of distribution for the execution times of each of the one or more functions and calculating parameters for the distribution including at least one of mean, median, standard deviation, skew, or kurtosis ([0046] “Monitor 130 may look for inconsistent behavior, using statistical thresholds, in for example … a function's average execution time, the average overall application execution time… and any other collected values that may be used to signify code characteristics or behaviors.” [0047] “monitor 130 may utilize one or more statistical thresholds to cluster code function portions, for example by k-means clustering, based on the characteristics or behaviors of the code portions, such as number of invocations or execution times. Monitor 130 may use the clusters to identify any code portions whose characteristics are not consistent across multiple test runs in a single test phase.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Sutter in view of Zaidi, Goldin, Saha, Zhang and Ganesan with the captured data including a state of the processor cache as taught by Dean in order “ to identify code behaving inconsistently” (Dean [0046]).
Response to Arguments
Applicant's arguments, see Pages 8-10 of the Remarks filed September 25, 2025, with respect to the rejections under 35 U.S.C. 103 of Claims 1-3, 6-12 and 15-20 have been fully considered but they are not persuasive. With respect to the Applicant’s argument that the newly amended language of Claims 1, 10 and 19 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Goldin et al. (US PGPUB 2014/0068569) reference as discussed above in the respective rejections.
Further, with respect to the Applicant’s argument, Page 9 Paragraph 4 of the Remarks, that “Saha’s risk score is fundamentally different from a variability score…” , a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim.
With respect to the Applicant’s further arguments, Page 10 Paragraph 2 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to Claims 1, 10 and 19 discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Murchison et al. (US PGPUB 2024/0184691) discloses systems and techniques for testing software changes and determining a repeatability of software tests, including determining, based on test scores generated by a software test performed a number of times, a repeatability score for the software test on changes to the software code.
Rhein et al. (“Variability-Aware Static Analysis at Scale: An Empirical Study,” 2018) discusses the strengths and weaknesses associated with variability-aware and sample-based static-analysis techniques by means of seven concrete control-flow and data-flow analyses applied to five real-world subject systems.
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 Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/J.G.M/ Examiner, Art Unit 2197
/BRADLEY A TEETS/ Supervisory Patent Examiner, Art Unit 2197