DETAILED ACTION
This Action is a response to the RCE filed 16 March 2026. Claims 1, 8 and 15 are amended; no claims are canceled or newly added. Claims 1-20 remain pending for examination. In view of the amendments and further consideration of Applicant’s response, the rejections under 35 U.S.C. § 101 have been withdrawn.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 16 March 2026 has been entered.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3, 5-6, 8-10, 12-13, 15-17 and 19-20 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by DePue et al., U.S. 2012/0303325 A1 (“DePue”).
Regarding claim 1, DePue teaches: A method (DePue, e.g., claim 1, “A computer-implemented method …”) comprising: receiving, by an application (DePue, e.g., ¶32, “system (200) can also include target machines (230), which can each be running a target program (232) and an agent (234) …”), an output of a static performance control executing on a remote computing system (DePue, e.g., ¶32, “system (200) can include an inference system (210), which can access a data store (220) …” See also, e.g., FIG. 2, clearly showing that the inference system and data store are remote from the target machine(s)), wherein the output of the static performance control is initial application configurations for at least one configurable aspect of the application (DePue, e.g., ¶37, “representation of analyzing machine representations … analysis may be done in the inference system (210) …” See also, e.g., ¶40, “Once the settings and their relative effects on the machines’ performance has been inferred …, good settings … and/or bad settings to be avoided … can be specified as such in a baseline set of configuration settings (350).” and, e.g., ¶41, “baseline set of configuration settings (250) may be communicated to a machine (230) … A tool, which can be a program module that is part of the agent (234) on the machine (230), may be used to change the configuration settings to match those of the baseline set of configuration settings (250) …”);
executing, by a client device, the application using the initial application configurations at least as a baseline for the performance of the application; detecting, by a dynamic performance control executing on the client device during execution of the application, feedback regarding device health and application runtime health statistics (DePue, e.g., ¶51, “technique may also include changing the baseline set of configuration settings after analyzing additional configuration data and performance data … repeating steps of … identifying configuration point(s) (530), inferring (540) effects, and determining (550) the changed baseline set of configuration settings … Changing the baseline set of configuration settings may also include collecting additional performance and/or configuration data, such as collecting additional data after the baseline set of configuration settings have been used …” See also, e.g., ¶32, “target machines (230), which can each be running a target program (232) and an agent (234). The agent (234) on each machine (230) can access instrumentation to collect performance data (242) and configuration data (244) from the machine … agent (234) may collect the data (242 and 244) using one or more of various techniques …, such as by making and receiving application programming interface calls … polling states of physical devices …” Examiner’s note: collecting application data, such as via instrumentation, and polling physical device states, combine to show detecting (and reporting) feedback regarding device health and application runtime health statistics); and
adjusting, by the application, the at least one configurable aspect of the application relative to the baseline of the application and which to deviate from the initial application configurations to account for the feedback regarding the device health and the application runtime health statistics (DePue, e.g., ¶51, “determining (550) the changed baseline set of configuration settings. The new baseline set of configuration settings can then be used (560). Changing the baseline set of configuration data may also include … collecting additional data after the baseline set of configuration settings have been used … analysis and changing of the baseline set of configuration settings may be repeated so that the baseline set can be adjusted as conditions change and/or more data becomes available for analysis.” See also, e.g., ¶41, “baseline set of configuration settings (250) may be communicated to a machine (230) … A tool, which can be a program module that is part of the agent (234) on the machine (230), may be used to change the configuration settings to match those of the baseline set of configuration settings (250) …”).
Claims 8 and 15 are rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 8, DePue further teaches: A computing system comprising: a processor; and a memory storing instructions that, when executed by the processor, configure the system (DePue, e.g., claim 11, “A computer system comprising: at least one processor; and at least one memory comprising instructions stored thereon that when executed by the processor cause the at least one processor to perform acts …”) to: [[[perform the method of claim 1]]]; and with respect to claim 15, DePue further teaches: A non-transitory computer-readable storage medium, the computer-readable storage medium including instructions that when executed by at least one processor, cause the at least one processor (DePue, e.g., claim 20, “One or more computer-readable storage media having computer-executable instructions embodied thereon that, when executed by at least one processor, cause the at least one processor to perform acts …”) to: [[[perform the method of claim 1]]].
Regarding claim 2, the rejection of claim 1 is incorporated, and DePue further teaches: receiving user feedback by the dynamic performance control regarding the device health and the application runtime health statistics, the user feedback indicating preferences for the device health and the application runtime health statistics and the performance of the application, wherein the user feedback is the feedback regarding the device health and the application runtime health statistics (DePue, e.g., ¶38, “inference system can identify configuration settings on the machines in a group, and infer their effect on the machines’ performance … machine representations (310) may be grouped into representations of ‘good’ machines (322) exhibiting good performance of a specified type, and … ‘poor machines’ … Other levels could also be specified … The different performance levels can be defined by user input … grouping of individual machines could be done … in response to user input. For example, a sorted list of machine performance levels can be displayed, and user input can be received to provide a specified cutoff between performance levels.” Examiner’s note: the feedback regards performance, which includes application performance and device status (see the rejection of claim 1). Thus, the user in DePue is providing feedback regarding device health and application runtime statistics, indicating preferences therefor (such as which performance metrics should belong to which levels of performance)).
Regarding claim 3, the rejection of claim 1 is incorporated, and DePue further teaches: receiving feedback from a learning service indicating that the adjusting of the at least one configurable aspect of the application will not be effective on the client device and recover the initial application configurations (DePue, e.g., ¶42, “After the baseline set of configuration settings (250) has been defined, those settings can be analyzed again at different times and/or using different machines to see if the baseline set of configuration settings (250) are still valid. This could result in the baseline set of configuration settings (250) being modified as a result of such additional analysis …” See also, e.g., ¶40, “Once the settings and their relative effects on the machines’ performance has been inferred as discussed above … bad settings to be avoided (334) (i.e., those with inferred negative effect on performance) can be specified as such …” Examiner’s note: the process is iterative; thus, in an instance where a baseline configuration comprises a particular configuration setting, and further analysis finds that that particular configuration setting has a negative performance effect, that setting will be avoided in a configuration setting update, such as to return to a previous setting).
Claims 9-10 and 16-17 are rejected for the additional reasons given in the rejections of claims 2-3 above.
Regarding claim 5, the rejection of claim 2 is incorporated, and DePue further teaches: updating, by the application, the dynamic performance control based on the user feedback indicating preferences for the device health and the application runtime health statistics and the performance of the application to be applied in a future use of the application (DePue, e.g., ¶38, “inference system can identify configuration settings on the machines in a group, and infer their effect on the machines’ performance … machine representations (310) may be grouped into representations of ‘good’ machines (322) exhibiting good performance of a specified type, and … ‘poor machines’ … Other levels could also be specified … The different performance levels can be defined by user input … grouping of individual machines could be done … in response to user input. For example, a sorted list of machine performance levels can be displayed, and user input can be received to provide a specified cutoff between performance levels.” Examiner’s note: the feedback regards performance, which includes application performance and device status (see the rejection of claim 1). Thus, the user in DePue is providing feedback regarding device health and application runtime statistics, indicating preferences therefor (such as which performance metrics should belong to which levels of performance). As the determination of the baseline set of configuration settings is iterative, after each round of analysis, such as in response to this user feedback, the baseline set of configuration settings may be updated, such that the agent applies the updated configuration settings upon dissemination from the inference system).
Regarding claim 6, the rejection of claim 5 is incorporated, and DePue further teaches: wherein an adjusting the at least one configurable aspect of the application is to meet the user feedback indicating preferences for the device health and the application runtime health statistics and the performance of the application (DePue, e.g., ¶38, “inference system can identify configuration settings on the machines in a group, and infer their effect on the machines’ performance … machine representations (310) may be grouped into representations of ‘good’ machines (322) exhibiting good performance of a specified type, and … ‘poor machines’ … Other levels could also be specified … The different performance levels can be defined by user input … grouping of individual machines could be done … in response to user input. For example, a sorted list of machine performance levels can be displayed, and user input can be received to provide a specified cutoff between performance levels.” Examiner’s note: the feedback regards performance, which includes application performance and device status (see the rejection of claim 1). Thus, the user in DePue is providing feedback regarding device health and application runtime statistics, indicating preferences therefor (such as which performance metrics should belong to which levels of performance). As the determination of the baseline set of configuration settings is iterative, after each round of analysis, such as in response to this user feedback, the baseline set of configuration settings may be updated, such that the agent applies the updated configuration settings upon dissemination from the inference system).
Claims 12-13 and 19-20 are rejected for the additional reasons given in the rejections of claims 5-6 above.
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 4, 11 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over DePue in view of Khosrowpour et al., U.S. 2020/0242000 A1 (“Khosrowpour”).
Regarding claim 4, the rejection of claim 1 is incorporated, but DePue does not more particularly teach that the static performance control includes a cloud-based machine learning algorithm and the dynamic performance control includes a machine learning algorithm on the client device. However, Khosrowpour does teach: wherein the static performance control includes a cloud-based machine learning algorithm (Khosrowpour, e.g., FIG. 1, machine learning performance score module 115), and wherein the dynamic performance control includes a machine learning algorithm on the client device (Khosrowpour, e.g., FIG. 1, machine learning performance score model 164) for the purpose of utilizing machine learning in a distributed fashion to determine which telemetry metrics have an impact on performance and to use historical configuration and telemetry data to optimize the configurations of new instances of applications for execution (Khosrowpour, e.g., ¶¶17-24).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for iterative determination of configuration impact on performance as taught by DePue to provide that the static performance control includes a cloud-based machine learning algorithm and the dynamic performance control includes a machine learning algorithm on the client device because the disclosure of Khosrowpour shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for low-overhead application performance determination and optimization to provide that the static performance control includes a cloud-based machine learning algorithm and the dynamic performance control includes a machine learning algorithm on the client device for the purpose of utilizing machine learning in a distributed fashion to determine which telemetry metrics have an impact on performance and to use historical configuration and telemetry data to optimize the configurations of new instances of applications for execution (Khosrowpour, Id.).
Claims 11 and 18 are rejected for the additional reasons given in the rejection of claim 4 above.
Claims 7 and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over DePue in view of Hamlin et al., U.S. 2024/0193008 A1 (“Hamlin”).
Regarding claim 7, the rejection of claim 1 is incorporated, but DePue does not more particularly teach adjusting the configurable aspect of the application to select a reduced performance parameter of the configurable aspect of the application which is correlated to a reduction in device and application runtime health statistics. However, Hamlin does teach: wherein the adjusting the at least one configurable aspect of the application is to select a reduced performance parameter of the at least one configurable aspect of the application which is correlated to a reduction in device health and the application runtime health statistics (Hamlin, e.g., ¶137, “Under a set of less favorable conditions (e.g., if battery level is below a second threshold level … if a level of utilization of high-performance AI device 308 is above a threshold level, etc.), however, polic(ies) 602 may specify that sensor hub and low-power AI device 307 be used to apply a less computationally costly AI model (or fewer models)”) providing an orchestration system for managing at least firmware and devices in a distributed system, the orchestration system including at least policies and one or more artificial intelligence models, and configured to receive at least device and firmware telemetry data and user information in order to evaluate system performance and determine whether configuration changes may improve performance of the information handling system (Hamlin, e.g., ¶¶125-138 et seq.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for iterative determination of configuration impact on performance as taught by DePue to provide for adjusting the configurable aspect of the application to select a reduced performance parameter of the configurable aspect of the application which is correlated to a reduction in device and application runtime health statistics because the disclosure of Hamlin shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for run-time storage stack performance evaluation and optimization to provide for adjusting the configurable aspect of the application to select a reduced performance parameter of the configurable aspect of the application which is correlated to a reduction in device and application runtime health statistics for the purpose of providing an orchestration system for managing at least firmware and devices in a distributed system, the orchestration system including at least policies and one or more artificial intelligence models, and configured to receive at least device and firmware telemetry data and user information in order to evaluate system performance and determine whether configuration changes may improve performance of the information handling system (Hamlin, Id.).
Claim 14 is rejected for the additional reasons given in the rejection of claim 7 above.
Response to Arguments
In the Remarks, Applicant Argues: (1) The amendments to the claims clarify and recite a specific technical implementation including a static performance control executing on a remote computing system generating a baseline configuration, and a dynamic performance control executing on the client device that monitors device health and application runtime health statistics for feedback and adjusts application configuration relative to feedback (Resp. at 7-8). This specific architecture and technical implementation represents a practical application of any abstract idea and/or significantly more than any abstract idea (id. at 8-9). (2) Khosrowpour fails to teach or suggest the static and dynamic performance controls as required to be configured pursuant to the amended claims, and accordingly the rejections of the claims in view of Khosrowpour should be withdrawn (id. at 9-12).
Examiner’s Response: (1) In view of the amendments and given consideration of Applicant’s arguments, the rejections under 35 U.S.C. § 101 have been withdrawn. (2) In view of the amendments, Examiner newly cites to DePue, and maintains the rejections under the new grounds set forth in full above.
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
Prosecution Insights