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 .
This office action is in response to applicant’s amendment filed on 07/31/2026.
Claims 1-20 are pending and examined.
Claims 16 and 17 appear to be redundant. Correction is requested.
Claim 12 recites “sending, by the circuitry the model”. Applicant is advised to amend it to “sending, by the circuitry to the model”.
Response to Arguments
Per 103 rejection, applicant’s arguments filed on 07/31/2026 have been fully considered. However, applicant’s arguments are moot in light of new grounds of rejection with new references applied.
The examiner is available for a phone interview with applicant.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 6, 8, 15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Cascaval et al. (US PGPUB 2007/0226698) hereinafter Cascaval.
Per claim 1, Cascaval discloses a processor comprising: circuitry configured to (Fig. 2); send, to a model, data corresponding to values of a plurality of hardware performance counters during runtime execution of an application, wherein the model is trained to use hardware performance counter values with respective to identify computational patterns and distinguish between optimized and unoptimized versions of program code that implement the computational patterns (Fig. 4; claim 1; paragraphs [0058][0059][0069]-[0080]; sending runtime performance data to a Continuous Program Optimizer for analysis, the runtime performance data includes hardware performance counters; the CPO analyzes the runtime performance data to determine various computational patterns, to detect performance problems (unoptimized versions); if there is no performance problem, it means the code is optimized already); receive, from the model, an output based on the data, the output identifying a given computational pattern and indicating that a version of program code used by the application to implement the given computational pattern is unoptimized; and responsive to the output, replace, during runtime execution of the application, the unoptimized version of program code with an optimized version of program code that implements the given computational pattern (claim 1; paragraphs [0058][0059][0069]-[0080]; during program execution time, responsive to identification of the runtime behavior of the program code, applying heuristic models to select at least one region of the program code (the unoptimized version of program code) for which application of a performance improvement algorithm is expected to improve runtime performance of the program code and, for each selected region, selecting at least one performance improvement algorithm (an optimized version of program code) from a plurality of performance improvement algorithms based on analysis of the runtime behavior of the region; recompiling each selected region according to the at least one selected performance improvement algorithm for that region to generate a corresponding recompiled region).
Per claim 6, Cascaval further discloses send values of one or more monitored hardware performance counters to the model; and receive an identification of the optimized version of program code from the model based on the values (claim 1; paragraphs [0058][0059][0069]-[0080]; sending runtime performance data to a Continuous Program Optimizer for analysis, the runtime performance data includes hardware performance counters; the CPO analyzes the runtime performance data to determine various computational patterns, to detect performance problems (unoptimized versions); applying heuristic models to select at least one region of the program code for which application of a performance improvement algorithm is expected to improve runtime performance of the program code and, for each selected region, selecting at least one performance improvement algorithm (an optimized version of program code) from a plurality of performance improvement algorithms based on analysis of the runtime behavior of the region).
Claims 8 and 15 recite similar limitations as claim 1. Thus, claims 8 and 15 are rejected under similar rationales as claim 1.
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 2, 5, 9 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Cascaval, in view of DeMonner et al. (US PGPUB 2022/0019517) hereinafter DeMonner.
Per claim 2, Cascaval does not explicitly teach receive an indication of the criteria used to compare versions of program code, determine the optimized version of program code satisfies the criteria more than the unoptimized of program code based at least in part on the indication of criteria comprising specifying lower resource utilization. However, DeMonner suggests the above (Claims 1, 3; comparing performance of one version of executable code to the performance of another (improved) version of executable code, performance can be execution time or memory utilization (indication of criteria, resource utilization), in response to determine there is improved performance, performs optimization of the unoptimized code with the improved version of executable code). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval and DeMonner to allow a user to specify which performance metrics are used for comparing two versions of code; this gives the user more flexibility and control over the performance comparison process.
Claim 9 recites similar limitations as claim 2. Thus, claim 9 is rejected under similar rationales as claim 2.
Per claim 5, Cascaval does not explicitly teach maintain, for each version of the program code, performance data collected from execution of a plurality of applications on the processor, the performance data including values of hardware performance counters indicative of resource utilization and execution latency; and wherein the optimized version of the program code is selected based at least in part on the performance data indicating that the optimized version provides improved execution of a computational pattern that has been previously observed in another application. However, Cascaval in view of DeMonner suggests maintain, for each version of the program code, performance data collected from execution of a plurality of applications on the processor, the performance data including values of hardware performance counters indicative of resource utilization and execution latency; and wherein the optimized version of the program code is selected based at least in part on the performance data indicating that the optimized version provides improved execution of a computational pattern that has been previously observed in another application (DeMonner, paragraphs [0034][0035][0040]; the optimization process replaces libraries (unoptimized version) of the user application that exhibit inferior performance characteristics as compared with improved equivalent methods (improved code); the original methods deemed for replacement (optimized version) may be identified based on estimated performance improvements determined from the comparative performance analysis of the captured traces as compared to pre-determined performance profiles of the client library and the curated third-party libraries; analysis may involve traces and historic performance profiles from multiple user applications; i.e. saving historical performance data of different versions of code from different applications; paragraph [0013]; performance data includes resource utilization and execution latency; Cascaval, claim 1; paragraphs [0058][0059][0069]-[0080]; sending runtime performance data to a Continuous Program Optimizer for analysis, the runtime performance data includes hardware performance counters; the CPO analyzes the runtime performance data to determine various computational patterns, to detect performance problems (unoptimized versions); applying heuristic models to select at least one region of the program code for which application of a performance improvement algorithm is expected to improve runtime performance of the program code and, for each selected region, selecting at least one performance improvement algorithm). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval and DeMonner to record hardware performance counters indicative of resource utilization and execution latency of different versions of a program code, and use this information to optimize a low performance version of program code with improved performance version of the code, so the program can execute with overall improved performance.
Per claims 16-17, Cascaval does not explicitly teach receive an indication of the criteria used to compare versions of program code, determine the optimized version of program code satisfies the criteria more than the unoptimized of program code based at least in part on the indication of criteria comprising specifying higher performance. However, DeMonner suggests the above (Claims 1, 3; comparing performance of one version of executable code to the performance of another (improved) version of executable code, performance can be execution time or memory utilization (indication of criteria, resource utilization), in response to determine there is improved performance, performs optimization of the unoptimized code with the improved version of executable code). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval and DeMonner to allow a user to specify which performance metrics are used for comparing two versions of code; this gives the user more flexibility and control over the performance comparison process.
Claims 3 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Cascaval, in view of DeMonner, and in view of Yamamoto (US PGPUB 2013/0132048).
Per claim 3, Cascaval does not explicitly teach receive an indication of the criteria used to compare versions of program code, determine the optimized version of program code satisfies the criteria more than the unoptimized of program code based at least in part on the indication of criteria comprising specifying lower power consumption. However, DeMonner in view of Yamamoto suggests the above (DeMonner, claims 1, 3; comparing performance of one version of executable code to the performance of another (improved) version of executable code, performance can be execution time or memory utilization (indication of criteria, resource utilization), in response to determine there is improved performance, performs optimization of the unoptimized code with the improved version of executable code; Yamamoto, paragraphs [0167][0126]; comparing performing of two versions of code to determine the code with lower power consumption). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval, DeMonner and Yamamoto to allow a user to specify a performance metric of lower power consumption is used for comparing two versions of code; this gives the user more flexibility and control over the performance comparison process.
Per claim 10, it is a method claim having similar limitations as cited in claim 3. Thus, claim 10 is also rejected under the same rationale as cited in the rejection of claim 3.
Claims 4, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cascaval, in view of DeMonner, and in view of Goetz et al. (US PGPUB 2017/0090959) hereinafter Goetz.
Per claim 4, Cascaval does not explicitly teach to compare the unoptimized version of program code and the optimized version of program code, responsive to locating both the unoptimized version of program code and the optimized version of program code in a runtime library that comprises versions of function calls to be called by the application. However, Goetz suggests responsive to locating both the unoptimized version of program code and the optimized version of program code in a runtime library that comprises versions of function calls to be called by the application (claim 1; paragraph [0069]; locating a runtime library that contains multiple versions of a class (function), which can be called by an application); DeMonner further suggests to compare the unoptimized version of program code and the optimized version of program code (Claims 1, 3; comparing performance of one version of executable code to the performance of another (improved) version of executable code, performance can be execution time or memory utilization, in response to determine there is improved performance, performs optimization of the executable code with the improved version of executable code). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval, DeMonner and Goetz to compare two versions of executable code in a runtime library, to optimize the executable code when there is performance improvement in another version of the executable code, for better resource utilization.
Per claim 11, it is a method claim having similar limitations as cited in claim 4. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of claim 4.
Per claim 19, it is a system claim having similar limitations as cited in claim 4. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 4.
Claims 7, 12, 14 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cascaval, in view of Ganguli et al. (US PGPUB 2018/0006903) hereinafter Ganguli.
Per claim 7, Cascaval does not explicitly teach wherein the output further identifies a type of workload being processed by the application and associates the given computational pattern with the type of workload. However, Ganguli suggests the above (Fig.3; claim 1, paragraphs [0017][0023][0032]; collecting hardware performance event data for analysis, to generate a workload fingerprint; the workload fingerprint includes a workload type and a phase sequence (pattern), the workload characteristics integrated through the sequence of phases can be combined and represented by a workload fingerprint). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval and Ganguli to generate a workload fingerprint that includes a workload type and a phase sequence, as the workload fingerprint is useful for future resource allocation (Ganguli, paragraph [0017]).
Claim 14 recites similar limitations as claim 7. Thus, claim 14 is rejected under similar rationales as claim 7.
Per claim 12, Cascaval further discloses generating, by the circuitry, indications of a plurality of hardware events based at least in part on monitored hardware performance counters; sending, by the circuitry the model, data corresponding to one or more of the hardware performance counters; and
generating, the model, identification of at least the unoptimized version of program code based on the data corresponding to one or more of the hardware performance counters (claims 1, 8; paragraphs [0058][0059][0069]-[0080]; sending runtime performance data to a Continuous Program Optimizer for analysis, the runtime performance data includes hardware performance counters; identifying characteristics (events) of an execution environment of the data processing system; the CPO analyzes the runtime characteristics, to detect performance problems (unoptimized versions); if there is no performance problem, it means the code is optimized already).
Cascaval does not explicitly teach wherein the model has been trained to identify different versions of computational patterns and workloads by processing a variety of applications on the circuitry and inspecting the hardware performance counters. However, Ganguli suggests the above (Fig.3; claim 1, paragraphs [0017][0018][0021][0023][0024]; various workloads can be used as a training set for a phase detection model, the model can be used to identify a workload type and a phase sequence (pattern); the model went through a learning process to inspect CPU performance counters and metrics of the various workloads used as training sets). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval and Ganguli to train a model to identify different versions of workloads and computational patterns using hardware counter data, as the collected data is useful for future resource allocation (Ganguli, paragraph [0017]).
Claim 18 recites similar limitations as claim 12. Thus, claim 18 is rejected under similar rationales as claim 12.
Claims 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cascaval, and in view of Arnold (US PGPUB 2010/0269106).
Per claim 13, Cascaval further suggests replacing the unoptimized version of program code at a given point in time corresponding to a particular type of workload has been identified by the model (claim 1; paragraphs [0058][0059][0069]-[0080][0103]; sending runtime performance data to a Continuous Program Optimizer for analysis, the runtime performance data includes hardware performance counters; the CPO analyzes the runtime performance data to determine various computational patterns and a specific workload configuration, to detect performance problems (unoptimized versions); selecting at least one performance improvement algorithm (an optimized version of program code) to replace the unoptimized version of program code). Cascaval does not explicitly teach in response to determining the unoptimized version of program code is not currently being executed. However, Arnold suggests the above (paragraph [0003][0006]; determine when it is safe to modify program code during runtime, it is unsafe to modify a code that is being executed, i.e. it is only safe when the code to be modified is not being executed). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cascaval and Arnold to modify a code at a safe time (the code is not being executed), as modifying a code when it is being executed may result in an error.
Per claim 20, it is a system claim having similar limitations as cited in claim 13. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 13.
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 HANG PAN whose telephone number is (571)270-7667. The examiner can normally be reached 9 AM to 5 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, Chat Do can be reached at 571-272-3721. 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.
/HANG PAN/Primary Examiner, Art Unit 2193
Prosecution Insights