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 RCE filed on 12/17/2025.
Claims 1-20 are pending and examined.
Claims 9 and 10 appear to be redundant (a minor difference of “by the circuitry”). Correction is advised.
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
Applicant’s arguments filed on 12/17/2025 have been fully considered.
However, the claims are rejected under new grounds of rejection with new references (Renes and Arnold) applied.
The examiner is available for a phone interview with applicant.
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, 5-6, 8, 12, 15, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Metsch et al. (US PGPUB 2019/0317737) hereinafter Metsch, in view of Renes et al. (US PGPUB 2023/0004831) hereinafter Renes, in view of DeMonner et al. (US PGPUB 2022/0019517) hereinafter DeMonner.
Per claim 1, Metsch discloses a processor comprising circuitry configured to: circuitry configured to: send data corresponding to values of a performance profile to a model trained to correlate performance profile values with respective computational patterns (paragraphs [0014][0054][0081][0015]; collecting execution traces/profiles of a set of functions (a first version of program code), a ML model can be used to detect patterns, using a pattern detector/model to detect an execution pattern from an execution profile provided by a server, an adaptation identifier to identify a possible instruction adaptation that may be applied to the instruction associated with the execution pattern); replace the first version of program code with a second version of program code, in response to: a model dynamically detecting at runtime a given computational pattern based on the data ; and the second version of program code being optimized to perform one or more operations of the given computational pattern with improved performance metrics relative to the first version (claim 1; paragraphs [0052][0053][0022][0015]; a pattern detector/model to detect an execution pattern at a runtime from an execution profile; after identifying a possible instruction adaptation associated with the execution pattern, applying the proposed instruction adaptation, an instruction is modified (version 1 of program code becomes version 2 of program code); a code adaptation can improve the performance of the underlying function of the program code (i.e. the code adaptation can perform the operations of the given computational pattern with improved performance)).
While Metsch discloses collecting performance profile of an application and send the performance profile to a model to detect computational patterns, Metsch does not explicitly teach send data corresponding to values of a plurality of hardware performance counters to a model trained to correlate hardware performance counter values with respective computational patterns. However, Renes suggests the above (paragraphs [0014][0029][0030]; analyzing application performance by sending hardware performance counter data to a machine learning model trained to detect anomalous behaviors (computational patterns)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Metsch and Renes to use a machine learning model to detect computational patterns from hardware performance counter data, as hardware performance counter data can provide important information about behavior of the application execution.
Metsch does not explicitly state generate, during runtime execution of the application, result data by executing source data with the second version of program code. However, DeMonner suggests the above (claim 1; paragraph [0012]; in response to determining that the improved code has improved performance over the executable code, modifying execution of the application to invoke the improved executable code (second version) in lieu of the executable code (first version) while the application process remains running (during runtime); execution of program code (client library) includes receiving arguments (source data) and producing return values (result data)). 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 Metsch, Renes and DeMonner to generate result data by executing source data with the second version of program code instead of the first version of program code, as this would improve the performance of the program execution.
Per claim 5, DeMonner in view of Renes further 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 second version of the program code is selected based at least in part on the performance data indicating that the second 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 (original code) of the user application that exhibit inferior performance characteristics as compared with improved equivalent methods (improved code); the original methods deemed for replacement 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 from other applications; paragraph [0013]; performance data includes resource utilization and execution latency; Renes further discloses collecting hardware performance counter data to detect patterns, paragraphs[0029][0030]).
Per claim 6, Renes further suggests send values of one or more monitored hardware performance counters to the model (paragraphs [0029][0030], send hardware performance counter data to a model to detect patterns). Metsch further suggests receive an identification of the second version of program code from the model based on the values (paragraphs [0014][0054][0081]; collecting execution traces/profiles of a set of functions (a first version of program code), utilizing machine learning models to identify pieces of a program which would benefit most from alterations; paragraphs [0052][0053][0022]; after identifying a possible instruction adaptation associated with an execution pattern, applying the proposed instruction adaptation (identifying a second version to replace the first version)).
Per claim 12, Renes further suggests generating, by the circuitry, indications of the 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 (paragraphs [0029][0030], send hardware performance counter data to a model to detect patterns). Metsch in view of DeMonner further suggests generating, the model, identification of at least the first version of program code based on the data corresponding to one or more of the hardware performance counters (Metsch; paragraphs [0014][0015][0054][0081]; collecting execution traces/profiles of a set of functions (a first version of program code), sending them to a machine learning model to identify computational patterns of the program; a pattern detector to detect an execution pattern (first version) from the execution profile); 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 (Metsch; paragraph [0015]; the model may be trained with data to recognize patterns and/or associations and follow such patterns and/or associations when processing input data such that other input(s) result in output(s) consistent with the recognized patterns and/or associations; DeMonner, paragraphs [0034][0035][0040]; a 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; it would have been obvious to train the model using historic performance profiles from different user applications and workloads, as more training will produce more accurate model for performance optimization).
Per claim 8, it is a method claim having similar limitations as cited in claim 1. Thus, claim 8 is also rejected under the same rationale as cited in the rejection of claim 1.
Per claim 15, it is a system claim having similar limitations as cited in claim 1. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 1.
Per claim 18, it is a system claim having similar limitations as cited in claim 12. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 12.
Claims 2 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Metsch, in view of Renes, in view of DeMonner, and in view of Sagy (US PGPUB 2020/0012493).
Per claim 2, DeMonner further suggests determine the second version of program code satisfies the criteria more than the first version of program code based at least in part on the indication of criteria comprising specifying lower resource utilization (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 executable code with the improved version of executable code).
DeMonner does not explicitly teach “receive an indication of the criteria used to compare versions of program code”. However, Sagy suggests the above (paragraphs [0168]-[0170]; receiving a user input specifying a classification filter to apply to the first and second sets of performance metrics, and display a quantitative comparison of the filtered first and second sets of performance metrics; i.e. the filter is used to specify particular performance metrics used for comparison). 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 Metsch, Renes, DeMonner and Sagy to allow a user to specify which performance metrics are used for comparing two version of code; this gives the user more flexibility and control over the performance comparison process.
Per claims 16 and 17, DeMonner further suggests determine the second version of program code satisfies the criteria more than the first version of program code based at least in part on the indication of criteria comprising specifying higher performance (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 (indication of criteria-higher performance); in response to determine there is improved performance, performs optimization of the executable code with the improved version of executable code).
DeMonner does not explicitly teach “receive an indication of the criteria used to compare versions of program code”. However, Sagy suggests the above (paragraphs [0168]-[0170]; receiving a user input specifying a classification filter to apply to the first and second sets of performance metrics, and display a quantitative comparison of the filtered first and second sets of performance metrics; i.e. the filter is used to specify particular performance metrics used for comparison). 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 Metsch, Renes, DeMonner and Sagy to allow a user to specify which performance metrics are used for comparing two version of code; this gives the user more flexibility and control over the performance comparison process.
Claims 3, 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Metsch, in view of Renes, in view of DeMonner, in view of Sagy, and in view of Yamamoto (US PGPUB 2013/0132048).
Per claim 3, DeMonner further suggests determine the second version of program code satisfies the criteria more than the first version of program code based at least in part on the indication of criteria comprising specifying lower resource consumption (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 executable code with the improved version of executable code).
DeMonner does not explicitly teach “receive an indication of the criteria used to compare versions of program code”. However, Sagy suggests the above (paragraphs [0168]-[0170]; receiving a user input specifying a classification filter to apply to the first and second sets of performance metrics, and display a quantitative comparison of the filtered first and second sets of performance metrics; i.e. the filter is used to specify particular performance metrics used for comparison). 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 Metsch, Renes, DeMonner and Sagy to allow a user to specify which performance metrics are used for comparing two version of code; this gives the user more flexibility and control over the performance comparison process.
While DeMonner discloses (claims 1-3) performance comparison between two versions of code, determine the code with lower resource consumption, DeMonner does not explicitly disclose to determine the code with lower power consumption. However, Yamamoto discloses the above (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 Metsch, Renes, DeMonner, Sagy and Yamamoto to compare performance between two versions of code, determine the code with lower resource consumption, in order to perform an optimization process (which will reduce power consumption of the application).
Per claim 9, it is a method claim having similar limitations as cited in claim 3. Thus, claim 9 is also rejected under the same rationale as cited in the rejection of claim 3.
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 7, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Metsch, Renes and DeMonner, in view of Dice et al. (hereinafter Dice) Publication No US 2011/0202907.
Per claim 7, Metsch fails to disclose the circuitry is configured to recompile program code of the application during runtime to replace the first version of program code with the second version of program code. However, Dice et al. disclose
“the circuitry is configured to recompile program code of the application during runtime to replace the first version of program code with the second version of program code” (e.g. Dice, par.[0048 and 0058] as these citations discloses recompiling code during runtime).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to add the circuitry is configured to recompile program code of the application during runtime to replace the first version of program code with the second version of program code as seen in Dice et al.’s invention into Metsch’s inventions because it would allow optimizing, recompiling and replacing an inefficient software option during execution thus reducing the time.
Per claim 14, it is a method claim having similar limitations as cited in claim 7. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of claim 7.
Claims 4, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Metsch, in view of Renes, in view of DeMonner, and in view of Goetz et al. (US PGPUB 2017/0090959) hereinafter Goetz.
Per claim 4, Metsch does not explicitly teach “responsive to locating both the first version of program code and the second version of program code in a runtime library that comprises versions of function calls to be called by the application, wherein the circuitry is further configured to compare the first version of program code and the second version of program code”. However, Goetz suggests ““responsive to locating both the first version of program code and the second 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 “wherein the circuitry is further configured to compare the first version of program code and the second 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 Metsch, Renes, 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 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Metsch, in view of Renes, in view of DeMonner, and in view of Arnold (US PGPUB 2010/0269106).
Per claim 13, Metsch further suggests “replacing the first version of program code at a given point in time corresponding to a particular type of workload has been identified by the deep learning model” (paragraphs [0014][0054][0081]; collecting execution traces/profiles (hardware events) of a set of functions (a first version of program code), utilizing machine learning models to identify pieces of a program which would benefit most from alterations; each piece of program represents a particular type of workload (instructions to be executed); paragraphs [0052][0053][0022]; after identifying a possible instruction adaptation associated with an execution pattern, applying the proposed instruction adaptation, an instruction is modified (version 1 of program code is replaced by version 2 of program code)). Metsch does not explicitly teach in response to determining the first 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 Metsch, Renes, DeMonner 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
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