DETAILED ACTION
This communication is responsive to the application, filed March 9, 2026. Claims 1-20 are pending in this application.
Examined under the first inventor to file provisions of the AIA
The present application was filed on April 4, 2024, which is on or after March 16, 2013, and thus is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ho et al. (US 2022/0276690 A1) in view of Chayat et al. (US 10,433,035 B2) and further in view of Trobough et al. (US 10,198,333 B2).
As per claim 1: An Information Handling System (IHS) [Ho; Fig. 1; (102), comprising:
one or more memory devices [Ho; Fig. 2, (system memory 205)]; and
one or more processors coupled to the one or more memory devices [Ho; Fig. 2, (processors 201)], wherein the one or more memory devices comprise instructions that, upon execution by the one or more processors, cause the IHS to:
monitor telemetry that comprises a specification of operational status information for hardware components of the IHS;
Ho discloses [0005] an IHS may include instructions to receive telemetry data associated with an operating behavior of the IHS.
detect a stress event related to a first of the hardware components of the IHS;
identity one or more stress tests for the first hardware component of the IHS;
configure generation and collection of additional telemetry for the first hardware component and one or more additional hardware components of the IHS related to the stress event, comprising a specification of the additional telemetry to be collected and a frequency at which the additional telemetry is to be collected for a duration of the one or more stress tests;
Ho discloses [Fig. 5; 0061-0062] predicting any stress event that may exist on the resources that could potentially cause the CPU to incur a stall condition. The method determines whether the predicted stress can be reduced by adjustment of core stall management mechanism. The stress test is the adjustment of the core stall mechanism itself (e.g. ramping frequency to see if it stalls). Ho discloses collection of telemetry data from components, but fails to explicitly disclose comprising specification of additional telemetry to be collected and a frequency at which it is to be collected. Chayat discloses a similar system, which further teaches [cols. 3-8; Figs. 2-7] a telemetry control architecture in which a memory stores telemetry profiles that specify a collection trigger, a set of telemetry registers to be read, and a telemetry data destination. The virtualized telemetry controller monitors collection triggers (periodic timers), detects when a trigger condition is satisfied, then uses the profile to identify a subset of telemetry registers (additional telemetry collection based on trigger/profile). The collection trigger may specify periodic timing or rules, which define how often telemetry is collected for the associated set of registers.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Ho with that of Chayat. One would have been motivated to collect additional telemetry because it reduces CPU or network bandwidth [Chayat; col. 2, lines 5-19].
conduct the stress tests while the telemetry and the additional telemetry are monitored to replicate the detected stress event; and
when the detected stress event is replicated, determine a root cause hardware component of the IHS based on machine learned evaluation of the telemetry and the additional telemetry.
Ho disclose [0051, 0061-0062] adjustment of the core stall mechanism and using machine learning to derive certain features associated with the IHS, but fails to explicitly disclose replicating the detected stress event to determine a root cause. Trobough discloses a similar system, which further teaches [Fig. 24-27; col. 34-35] providing replication via test/replay flows and worst-case excitation with continuous capture. The data capture during replication/replay is used to identify the causal subsystem/condition. The workflow of Fig. 24-27 explicitly show a root-cause by post processing divergence detection, comparing replay vs live to detect divergences, reconstructing transactions by source for analysis.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Ho and Chayat with that of Trobough. One would have been motivated to replicate the detected event because it allows to test cases for worst-case scenarios [Trobough; col. 10, lines 55-67].
As per claim 2: The IHS of claim 1, wherein the instructions executed by the one or more processors further cause the IHS to identity a second hardware component of the IHS that is related to the stress event.
Ho discloses [0018-0021] learning the behavior of other resources so that stall conditions of most or all resources can be predicted and coordinating operation of core stall management with other resources. Correlating the CPU stalls to non-CPU resources inherently identifies other hardware components related to the stress event.
As per claim 3: The IHS of claim 2, wherein the stress event further comprises events throttled by the one or more processors due to thermal constraints, and wherein the second hardware component further comprises an airflow cooling fan.
Ho discloses [0018, 0042] power and thermal control systems within platform resources and the EC providing core functions and power management. In PC/server architectures, power management via the EC routinely includes thermal policy enforcement and fan control.
As per claim 4: The IHS of claim 1, wherein when the detected stress event is not replicated, the stress event is designated as spurious as an input in the machine learned evaluation configured to determine the root cause hardware component.
Trobough discloses [Fig. 26; col. 34, lines 48-67] post processing divergence detection leverages DFx hardware features, save system states, and replay execution results are compared to obtain post processing divergence detection results. Fig. 26 teaches a formal workflow to classify non-reproducible outcomes by comparing replay vs. live runs (i.e. labeling events that fail to recur as deivergences/noise, which maps to “spurious” designation and feeding outcomes back into control logic for analytics).
As per claim 5: The IHS of claim 1, wherein the machine learned evaluation is configured to generate an output configured to specify a hardware component of the IHS as the root cause of the stress event.
Ho discloses [0061-0063] generating profile recommendations using a machine learning (ML) service to control or adjust operation of the core stall management mechanism, based on telemetry from GPU, storage, and other resources. The ML output identifies which component/setting to adjust, effectively pointing to the responsible hardware for the stress event.
As per claim 6: The IHS of claim 1, wherein the operational status information for hardware components of the IHS further comprises utilization of a network controller of the IHS and wherein the stress event further comprises timeout errors in an attempt to communicate with the network controller.
Ho discloses [0018-0021, 0032, 0051] the communication resources, wired network controllers and wireless network controllers may generate telemetry data, which is gathered by the IHS machine learning service.
As per claim 7: The IHS of claim 6, wherein the one or more stress tests further comprise a stress test of speeds supported by the network controller.
Ho discloses [0018-0021, 0051] profile recommendations adjust parameters and managing resources as part of optimization. The adjusting/validating NIC link parameters/speeds is a routine stress test within the disclosed communication resources management.
As per claim 8: The IHS of claim 1, wherein the operational status information for hardware components of the IHS further comprises a status of a storage drive of the IHS and wherein the stress event further comprises a timeout error in an attempt to communicate with the storage drive.
Ho discloses [0021, 0036, 0061] storage device stalls due to storage loading. The IHS machine learning service may detect that due to actions currently being performed, a relatively large amount of storage resource could cause a stall/timeout condition on the CPU resource.
As per claim 9: The IHS of claim 8, wherein the stress event is replicated and root cause is determined to be caused by error correction operations by the storage drive.
Trobough discloses [Fig. 24-27; col. 34-35] providing replication via test/replay flows and worst-case excitation with continuous capture. The data capture during replication/replay is used to identify the causal subsystem/condition. The workflow of Fig. 24-27 explicitly show a root-cause by post processing divergence detection, comparing replay vs live to detect divergences, reconstructing transactions by source for analysis.
As per claim 10: The IHS of claim 1, wherein the operational status information for hardware components of the IHS further comprises a network availability reported by an SoC (System-on-Chip) of the IHS and wherein the one or more stress tests further comprise tests of bandwidth supported by a network controller of the IHS.
Ho discloses [0032-0033] graphics processor may be integrated as a SoC and telemetry data gathered from communication resources NIC (222/223). The SoC integrated components and NIC telemetry support availability/bandwidth testing by the optimization workflow.
As per claim 11: The IHS of claim 10, wherein the network availability reported by the SoC further comprises an availability of virtualized network resource provided by the network controller of the IHS.
Trobough discloses [col. 12, lines 1-20] virtual channels/resources at the link/protocol layer and availability reporting of virtualized NIC resources is within the disclosed DFx validation and observation of virtualization constructs.
As per claim 12: The IHS of claim 1, wherein the operational status information for hardware components of the IHS further comprises buffered video outputs reported by a GPU implemented by an SoC of the IHS and wherein the one or more stress tests further comprise load the GPU to replicate the buffered video outputs reported by the GPU.
Trobough discloses [col. 6, lines 58-67] predicting any stress event that may exist on the resources that could potentially cause the CPU to incur a stall condition. The method determines whether the predicted stress can be reduced by adjustment of core stall management mechanism. The stress test is the adjustment/replication of the core stall mechanism itself, which supports causality from storage delay to GPU buffering (Fig. 23-25; ODLA/DFx across CPU-PCH-storage-graphics).
As per claim 13: The IHS of claim 12, wherein the stress event is replicated and root cause is determined to have been delay in response by a hard drive that is a source of data output by the GPU.
Trobough discloses [col. 6, lines 58-67] predicting any stress event that may exist on the resources that could potentially cause the CPU to incur a stall condition. The method determines whether the predicted stress can be reduced by adjustment of core stall management mechanism. The stress test is the adjustment/replication of the core stall mechanism itself, which supports causality from storage delay to GPU buffering (Fig. 23-25; ODLA/DFx across CPU-PCH-storage-graphics).
As per claim 14: The IHS of claim 1, wherein the one or more stress tests are conducted upon a determination that the detected stress event ended.
Trobough discloses [Fig. 24; col. 34] scheduling tests and replays after initial events to analyze causality, which matches the post-event testing.
As per claim 15: The IHS of claim 14, wherein the one or more stress tests are conducted upon determination that the IHS is idle.
Ho discloses [0003] most modern processor cores can operate in different power-saving states, also termed as low power or idle states. Furthermore, Trobough discloses [col. 5, lines 44-54; col. 19, lines 38-60] scheduling and executing tests via firmware/EC during idle/low power states with separate power planes.
As per claim 16: The IHS of claim 1, wherein the one or more stress tests are conducted by an embedded controller of the IHS while the IHS is in a low power mode.
Trobough discloses [Fig. 9 and 23; col. 19 and 33] embedded controller operates over a sideband bus, capturing signals in low power states. The EC driven diagnostics with sideband access and explicit low-power state signal capture meets EC in low-power testing.
As per claims 17-19: Although claims 17-19 are directed towards a method claim, they are rejected under the same rationale as the system claims 1, 14, and 15, respectively and are obvious variants of claims 1, 14, and 15 above.
As per claim 20: Although claim 20 is directed towards a device claim, it is rejected under the same rationale as the system claim 1 and is an obvious variant of claim 1 above.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The following prior art made of record and not relied upon is cited to establish the level of skill in the applicant’s art and those arts considered reasonably pertinent to applicant’s disclosure. See MPEP 707.05(c).
· US 9,929,922 B2 – Gross discloses gathering telemetry data while testing a computer system. The system generates a load profile to gather telemetry data during multiple successive executions of the test script on the computer system.
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 JIGAR P PATEL whose telephone number is (571)270-5067. The examiner can normally be reached on Monday to Friday 10AM-6PM.
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, Ashish Thomas, can be reached on 571-272-0631. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/JIGAR P PATEL/Primary Examiner, Art Unit 2114
Prosecution Insights