DETAILED ACTION
Status of Claims
Claims 1 – 19 are pending.
Claims 1, 7, and 13 are independent.
Claims 11 and 17 have been amended.
Claim 19 is new.
This office action is Non-Final.
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 .
Response to Arguments
Applicant’s arguments, see Remarks, filed 07 April 2026, with respect to the rejection(s) of claims 1 - 18 under 35 U.S.C. 102(a)(2) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. 103 as being unpatentable over Hiremath et al. (US Patent Application Publication No. 2024/0220367 A1, “ Hiremath”), in view of Chaiken et al. (US Patent Application Publication No. 2020/0159302 A1, hereinafter “Chaiken”). The detailed rejection is provided hereinbelow.
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 1 -19 are rejected under 35 U.S.C. 103 as being unpatentable over Hiremath et al. (US Patent Application Publication No. 2024/0220367 A1, “ Hiremath”), in view of Chaiken et al. (US Patent Application Publication No. 2020/0159302 A1, hereinafter “Chaiken”).
As per claim 1, Hiremath teaches an information handling system [fig. 6, computer system 600, 0085] comprising:
at least one processor [fig. 6, processor 610, 0088];
a memory [fig.6, memories 602 and 606, 0085];
a Basic Input/Output System (BIOS) [fig. 6, BIOS 618, 0088 ]; and
a … [[ device ]] [BMC, 0091, 0092];
wherein the … [[device]] is configured to:
collect information regarding a boot process of the information handling system [fig.7, 0100: “…If BIOS failure occurs 710 and the consecutive BIOS failure counter has been incremented 712 by one, the method 700 may include determining 714, e.g., the processor determining, whether the consecutive BIOS failure counter is less than a BIOS threshold. The threshold may reflect a maximum number of times that the BIOS POST process may be attempted before the active BIOS is deemed to be broken or otherwise non-functional such that BIOS recovery should be performed. …”, 0106: “…
In the process 800 of FIG. 8, BIOS recovery is automatically triggered by the BMC on consecutive OS load timeouts. In general, the method 800 can track consecutive OS initialization failures and trigger a BIOS recovery procedure when a defined failure threshold is breached.…”, 0105: “…The method 800 may be executed by a BMC …”];
determine, based on the collected information, that a boot loop event [max number of retries has been reached, 0100] has occurred; and
apply a remediation to the information handling system to prevent the boot loop event from recurring [0077 – 0078, 0103: “…the BIOS recovery procedure can be implemented in accordance with atypical BIOS recovery procedure, as will be appreciated by those skilled in the art. In general, the BIOS recovery procedure can copy a backup BIOS image (e.g., the golden BIOS image 630 of FIG. 6,etc.) to the active BIOS image (e.g., the primary BIOS image 616 of FIG. 6, etc.) such that the next boot attempt will use the backup BIOS image (now the active BIOS image) to allow for successful a BIOS POST process…”].
However, Hiremath does not explicitly teach that the device is an embedded controller.
Chaiken is cited to teach an information handling systems (IHSs) and methods are to automatically detect and recover from boot failures, such as no power failures and no POST failures, without suffering the information loss that typically occurs in conventional recovery methods. In particularly, an embedded controller (EC) configured to execute embedded controller firmware during the boot process to detect a no power failure or a no POST failure, and reset or remove power from the system RTC if a no power failure or a no POST failure is detected.
Both Chaiken and Hiremath are directed to IHS software and hardware components and related methods for recovering from boot failures.
As per claim 1, Chaiken further teaches … [the] embedded controller [embedded controller 150 determines boot failure and provides either removes power or a reset of the real time clock to fix the failure, 0055-0056: “…In step 350, EC 150 waits for boot firmware 142 to send a “Host Up” message indicating that the boot was successful. If the “Host Up” message is received within a predetermined timeout (NO branch of step 360), EC 150 continues with its normal runtime behavior (in step 370). However, if a “Host Up” message is not received within the predetermined timeout (YES branch of step 360), EC 150 increments the POST attempt count (in step 380) and determines if the POST attempt count exceeds a maximum count (in step 390). Comparing the POST attempt count to the maximum count allows the boot firmware to attempt POST multiple times (e.g., 2, 3, 4, or 5) before the EC detects a no POST failure… If the POST attempt count does not exceed the maximum count (NO branch of step 290), EC 150 power cycles the system (in step 220) to restart the boot process. When the POST attempt count exceeds the maximum count (YES branch of step 290), the EC resets the POST attempt count to zero (in step 400), sets a no POST flag (in step 410) and either resets system RTC 160 or removes power from the RTC (in step 250). In one example implementation, EC 150 may reset system RTC 160 by using an EC GPIO signal (e.g., RTC_RESET #) to pull RTCRST # on PCH 120 low for a short delay, before restoring it back to high to reset the system RTC. In another example implementation, EC 150 may remove power from the RTC by disconnecting the RTC battery 170 power from the RTC for a predetermined amount of time (e.g., 100 ms)…”].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chaiken and Hiremath, as Chaiken’s embedded controller can manage functions that frees up the BMC, running more efficient.
As per claim 2, Hiremath teaches the information handling system of claim 1, wherein the BIOS is a Unified Extensible Firmware Interface (UEFI) BIOS [0074: UEFI].
As pe claim 3, Hiremath teaches the information handling system of claim 1, wherein the boot loop event is associated with execution of a phase of the BIOS [0075: “… an error that occurs during the boot process …”].
As pe claim 4, Hiremath The information handling system of claim 1, wherein the boot loop event is associated with execution of an operating system (OS) of the information handling system [0075: “… an error that occurs during running of the OS, an error that occurs during upgrading or as a result of upgrading an OS…”].
As per claim 5, Hiremath teaches the information handling system of claim 1, wherein the embedded controller is further configured to:
transmit, to a cloud-based system, information regarding the boot loop event; and
receive, from the cloud-based system, information regarding the remediation [0091: “…In response to the BIOS recovery procedure being automatically triggered, a notification maybe automatically generated and transmitted to an operations facility and/or an operations manager responsible for maintaining the computer system to provide notification of the boot failure. The BIOS that failed to boot successfully may thus be assessed and repaired as needed, remotely and/or locally …”, 0134: subject matter can be implemented on one or more application servers].
As per claim 6, Hiremath and Chaiken teach the information handling system of claim 1, wherein the boot loop event comprises: an automatic shutdown event, and an automatic restart event triggered by a watchdog timer [Hiremath, 0077: “…This timer can be used for BIOS, OS, and OEM applications. The timer can be configured to automatically generate selected actions when it expires. Accordingly, in some implementations of the current subject matter, an action automatically generated when the watchdog timer expires can include BIOS recovery.”; Chaiken, 0055- 0056: timeout].
As per claim 19, Chaiken teaches the information handling system of claim 1, wherein:
the information regarding the boot process comprises system context information that
indicates a system power state and a boot phase at a time of a failure associated with the boot
loop event [POST attempt count, 0055 - 0056];
the embedded controller is further configured to detect, based on the system context
information, one or more symptoms associated with the with the boot loop event [POST attempt count exceeds threshold, 0055-0056]; and
the remediation is selected based on the one or more symptoms [remediations, 0056].
As per claims 7 - 12, it is directed to a method to implement on the apparatus forth in claims 1 - 6. Hiremath, in view of Chaiken, teaches the claimed apparatus. Therefore, Hiremath, in view of Chaiken teaches the method to implement the claimed steps.
As per claims 13 - 18, it is directed to an article of manufacture to implement on the apparatus forth in claims 1 - 6. Hiremath, in view of Chaiken teaches the claimed apparatus. Therefore, Hiremath, in view of Chaiken, teaches the article of manufacture to implement the claimed steps.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERRELL S JOHNSON whose telephone number is (571)270-3485. The examiner can normally be reached 10AM-7PM EST M-F.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/TERRELL S JOHNSON/ Primary Examiner, Art Unit 2176
Prosecution Insights