DETAILED ACTION
This Action is a response to the reply filed 18 June 2026. Claims 1, 8 and 15 are amended; claims 19-20 are canceled; claims 21-22 are newly added. Claims 1-18 and 21-22 remain pending for examination.
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
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-6, 8-10, 12-13, 15-17 and 21-22 are rejected under 35 U.S.C. § 103 as being obvious over DePue et al., U.S. 2012/0303325 A1 (“DePue”) in view of Chopra et al., U.S. 11,093,290 B1 (“Chopra”).
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), wherein the feedback indicates a resource utilization condition of the client device during execution of the application (DePue, e.g., ¶36, “Stress profiles may be received from user input and/or modified based on analyzing the data (242 and 244) … a stress profile can be a processor sustained over a predefined percentage of full capacity for a specified period of time … memory usage sustained over a certain percentage of available memory for a specified period of time …”); 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) …”),
wherein the adjusting comprises modifying the at least one configurable aspect according to an action selected by the dynamic performance control, based on the resource utilization condition (DePue, e.g., ¶51, “changing the baseline set of configuration settings after analyzing additional configuration data and performance data … identifying (510) periods of stress, grouping (520), identifying configuration point(s) (530), inferring (540) effects, and determining (550) the changed baseline set of configuration settings …”).
DePue does not more particularly teach that the adjusting is an action selected from an action set comprising a downgrade action reducing performance of the at least one configurable aspect and an upgrade action increasing performance of the configurable aspect. However, Chopra does teach: [modifying the configurable aspect according to an action selected] from an action set comprising a downgrade action that reduces performance of the at least one configurable aspect and an upgrade action that increases performance of the at least one configurable aspect (Chopra, e.g., 9:55-10:5, “If the backup server resource monitor 126 determines that the backup server’s memory or CPU utilization is greater than the backup server’s corresponding backup server resource utilization thresholds, then the backup server resource monitor 126 informs the application data manager 122 to reduce the fetch rate of the copies of the client application resources, and the backup server 110 fetches copies of the client application resources from the clients 102-108 at a reduced fetch rate …” See also, e.g., 10:6-34, “if the backup server’s 80% utilization of its memory drops below its memory utilization threshold, of 75%, then the discovery module 124 fetches the remaining un-fetched copies of … copy metadata 138, 146, and 158 at the default rate …”) for the purpose of identifying resource consumption that exceeds (or drops below) a threshold, and modifying a configurable aspect of an application such that performance is reduced or increased based on a comparison of the consumption to the threshold (Chopra, e.g., 9:55-11:48).
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 adjusting is an action selected from an action set comprising a downgrade action reducing performance of the at least one configurable aspect and an upgrade action increasing performance of the configurable aspect because the disclosure of Chopra shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for resource utilization monitoring and responsive application configuration modification to provide that the adjusting is an action selected from an action set comprising a downgrade action reducing performance of the at least one configurable aspect and an upgrade action increasing performance of the configurable aspect for the purpose of identifying resource consumption that exceeds (or drops below) a threshold, and modifying a configurable aspect of an application such that performance is reduced or increased based on a comparison of the consumption to the threshold (Chopra, Id.).
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 are rejected for the additional reasons given in the rejections of claims 5-6 above.
Regarding claim 21, the rejection of claim 21 is incorporated, and DePue further teaches: wherein the static performance control generates the initial application configurations as the baseline configuration for the application, and wherein the dynamic performance control modifies the baseline configuration during execution of the application based on the feedback wherein the feedback is locally detected feedback (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) …” Examiner’s note: the inference system, which determines the baseline configurations, is the static performance control, and the agents on the machines are the dynamic performance controls, which perform adjustments of configurations to newer baselines that are updated based on feedback (performance data) detected locally (by the agents on the machines at which the software is executing and/or the hardware performance metrics are being collected)).
Regarding claim 22, the rejection of claim 1 is incorporated, and Chopra further teaches: wherein the action set maps the downgrade action to a resource utilization condition indicating that the client device is overloaded, and maps the upgrade action to a resource utilization condition indicating that resources of the client device remain available (Chopra, e.g., 9:55-10:5, “If the backup server resource monitor 126 determines that the backup server’s memory or CPU utilization is greater than the backup server’s corresponding backup server resource utilization thresholds, then the backup server resource monitor 126 informs the application data manager 122 to reduce the fetch rate of the copies of the client application resources, and the backup server 110 fetches copies of the client application resources from the clients 102-108 at a reduced fetch rate …” See also, e.g., 10:6-34, “if the backup server’s 80% utilization of its memory drops below its memory utilization threshold, of 75%, then the discovery module 124 fetches the remaining un-fetched copies of … copy metadata 138, 146, and 158 at the default rate …” Examiner’s note: in this instance, the client device is the backup server, as it is the device on which an application being monitored is executing, and for which performance thereof is adjusted in order to account for resource utilization conditions).
Claims 4, 11 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over DePue in view of Chopra, and in further view of Khosrowpour et al., U.S. 2020/0242000 A1 (“Khosrowpour”).
Regarding claim 4, the rejection of claim 1 is incorporated, but DePue in view of Chopra 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 in view of Chopra 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 Chopra, and in further view of Hamlin et al., U.S. 2024/0193008 A1 (“Hamlin”).
Regarding claim 7, the rejection of claim 1 is incorporated, but DePue in view of Chopra 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 in view of Chopra 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) DePue does not disclose receiving by an application an output of a static performance control executing on a remote computing system, wherein the output is initial application configurations for at least one configurable aspect of the application (Resp. at 10). DePue describes an agent as the recipient of the output of the inference system, rather than the application itself (id.). DePue can operate with the agent or machine receiving suggested settings without the target program itself receiving those settings (id. at 10-11).
Examiner’s Response: The agent of DePue acts as an intermediary between the inference system and the application, via which the agent makes adjustments to the application’s configuration settings comprising the updated baseline. Thus, the application does receive the suggested application configuration adjustments through the agent.
Applicant Further Argues: The output of the remote system of DePue is not initial application configurations used by the application; they are instead generated after collecting configurations and performance data from multiple machines already running the target program (Resp. at 11). At least some of DePue’s configuration points are not application configurations (id.).
Examiner’s Response: The claims recite an initial setting and an updated setting; DePue’s baseline, prior to adjustments, comprises the initial configuration, and the updated configuration (i.e., the new baseline) is the updated configuration setting. That some (but not all) of the configurable aspects of the client device plus application are not application-specific settings does not remove that other configuration settings are application-specific (and registry keys, file versions, and network cards can all be components that interact with and/or are part of an application executing on a client device).
Applicant Further Argues: DePue does not disclose executing the application using the initial application configurations at least as a baseline for the performance of the application (Resp. at 11). DePue does not disclose an application first receiving initial application configurations from a remote static performance control and then executing those configurations as a runtime baseline (id.).
Examiner’s Response: As indicated above, the initial configuration (i.e., the first determined baseline) is provided to the application running on the client device, subsequent to which the application executes using that first baseline. Subsequent to that, based on monitored metrics, the baseline is updated to a new baseline, which represents the updated configuration.
Applicant Further Argues: DePue’s “agent” represents a reporting and data-collection function for later inference by the inference system; this is not the same as executing a dynamic performance control on the client device during application execution that locally controls application runtime behavior relative to initial application configurations (Resp. at 11-12).
Examiner’s Response: As discussed above, the agent does indeed collect and report telemetry data, but also receives and applies updated configuration settings to the applications as they execute on the client devices.
Applicant Further Argues: DePue does not disclose adjusting, by the application, the at least one configurable aspect of the application relative to the baseline of the application to deviate from the initial application configuration, but this action is instead performed by a tool as part of the agent (Resp. at 12). Further, the settings are changed to match the baseline, not to deviate from the initial configuration; and the baseline is a target or recommended configuration set generated from aggregate analysis, not an application baseline used by a local runtime control loop (id.).
Examiner’s Response: As discussed above, the application receives and updates the configuration settings via the agent as received from the inference tool. This is not inconsistent with the claim language as currently presented. Further, as discussed above, a first baseline is an initial configuration; subsequent updated baselines are deviated configurations; and the applications apply and operate under the updated baselines via the agents and the inference tool during application runtime.
Applicant Further Argues: DePue also describes changing the baseline set of configuration settings after analyzing additional configuration and performance data, but changing the baseline itself is not the same as the claimed application adjusting a configurable aspect relative to a baseline to deviate from initial application configurations in response to runtime feedback (Resp. at 12).
Examiner’s Note: Again, the first baseline represents the initial configuration; runtime data is collected to determine which configuration settings should change from that first baseline in order to generate an updated baseline; and the changed configuration settings are sent to the applications via the agents such that they are modified during runtime using runtime telemetry data as feedback.
Applicant Further Argues: Additional amendments have been provided with respect to independent claims 1, 8 and 15 which provide further distinctions over DePue (Resp. at 12-14).
Examiner’s Response: Examiner newly cites to Chopra, and maintains the rejections under the new grounds set forth in full above.
Applicant Further Argues: DePue’s disclosure that performance levels may be defined by user input is not user feedback received by a dynamic performance control regarding device health and application runtime statistics or feedback indicating user preferences for device health, runtime health statistics and performance analysis (Resp. at 14).
Examiner’s Response: The claim recites receiving user feedback by the dynamic performance control regarding the device health and the application runtime statistics, indicating preferences for the device health and runtime health statistics and application performance, wherein the user feedback is the feedback. By a user indicating preferences for performance levels or cutoffs, the user is providing feedback regarding all of the device health, the runtime statistics, and application performance, as a cutoff or performance level depends on the device health, runtime health statistics and application performance. Taking the feedback into consideration when determining the updated configuration settings is therefore consistent with the claim as currently presented.
Applicant Further Argues: DePue does not disclose a learning service indicating that an adjustment of an application configurable aspect will not be effective on the client device and recovering the initial application settings in response to such feedback; updating a baseline set after additional aggregate analysis is not a learning-service determination of client-specific ineffectiveness and is not recovery of initial application configurations (Resp. at 15).
Examiner’s Response: By learning that one change to the baseline configuration will not improve performance (i.e., by applying the change and identifying a performance reduction), updating the baseline to a new baseline having a reverted configuration setting, and then applying that updated baseline, results in a reversion to the previous setting. The learning service therefore is an aspect included within the inference service.
Applicant Further Argues: Even assuming, without conceding, that Khosrowpour teaches the additional features of claim 4, it does not cure the above-identified deficiencies of the independent claims (Resp. at 15-16). The proposed combination therefore lacks both the claimed structure and operation, appears to use Applicant’s disclosure as a roadmap to reorganize DePue’s inference system into a distributed static/dynamic runtime-control architecture not taught by the cited references, and is a reconstruction not supported by an articulated reason with rational underpinning (id. at 16).
Examiner’s Response: As discussed above, Examiner is not persuaded that DePue fails to teach the aforementioned claim limitations. As Applicant does not provide a specific deficiency asserted with respect to Khosrowpour or the combination thereof with DePue that does not rely on that failure, Examiner is not persuaded that the combination is otherwise unsupported.
Applicant Further Argues: Hamlin does not cure the deficiencies previously identified with respect to the independent claims, which are made clearer by additional amendments made thereto (Resp. at 16-17). The Office Action does not articulate a sufficient technical reason why a person of ordinary skill in the art would have modified DePue’s aggregate baseline inference system using Hamlin to arrive at a local dynamic performance control that selects between downgrade and upgrade actions based on a current resource utilization condition, and this proposed combination would require redesigning DePue’s aggregate inference system into the claimed local runtime control loop (id. at 17).
Examiner’s Response: As discussed above, Examiner is not persuaded that DePue fails to teach the aforementioned claim limitations. As Applicant does not provide a specific deficiency asserted with respect to Hamlin or the combination thereof with DePue that does not rely on that failure, Examiner is not persuaded that the combination is otherwise unsupported.
Concluding Response: In view of the foregoing remarks, Examiner is not persuaded that DePue fails to teach the claim limitations asserted by Applicant, and maintains each of the rejections under the new grounds set forth in full above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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