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 .
DETAILED ACTION
This Office Action is in response to the Amendment filed on 04/06/2026.
In the instant Amendment, claims 1, 8-9, 11, 18 and 20 have been amended; claims 6 and 16 have been cancelled. Claims 1, 11 and 20 are independent claims. Claims 1-5, 7-15 and 17-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
The rejection of claim 11-19 under 35 U.S.C. 112(b), withdrawn as the claims have been amended.
Applicants’ arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
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 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 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-5, 7-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Montero (US 2024/0168910) and in view of Bhatia (US 2024/0211350).
Regarding claim 1, Montero discloses a method of operation of a baseboard management controller (BMC) (Montero abstract and par. 0049; Systems and methods for loading firmware onto an embedded controller (EC) integrated into a heterogenous computing platform. EC 109 (sometimes referred to as a Baseboard Management Controller or “BMC”) handles certain IHS operations not ordinarily handled by host processor(s) 101), comprising:
determining to reboot a hardware component, wherein a firmware image for the hardware component is stored in a non-volatile memory of the hardware component, and wherein the BMC controls power sequencing of the hardware component (Montero par. 0053-0054, 0060 and 0111-0112; EC 109 calculate a hash value based on the configuration of a hardware and/or software component coupled to IHS 100. For instance, EC 109 may calculate a hash value based on all firmware and other code or settings stored in an onboard memory of a hardware component. EC 109 validate the integrity of hardware and software components installed in IHS 100. In some implementations, the latest system-wide firmware installation package received by platform 200 may be installed at every boot of IHS 100. An EC with access to an internal SoC fabric, whether in a fully internal, partially internal/external, or fully external implementation (e.g., via eSPI). These systems and methods may also provide voltage segregation factor and power sequencing, as well as various possible architectural variations on GPIO handling. See also par. 0005 and 0050);
reading, by the BMC, the firmware image of the hardware component from the non- volatile memory of the hardware component (Montero par. 0122; EC 109A/B receives EC firmware instructions, configuration settings, or tables 706A-N from PCIe devices 705A-N. At 804, EC 109A/B cryptographically verifies the integrity or authenticity of EC firmware instructions, configuration settings, or tables 706A-N. For example, each of PCIe devices 705A-N may be provisioned with its own digital certificate);
verifying, by the BMC using a public key of a public-private key pair, the firmware image of the hardware component to determine integrity and authenticity of the firmware image prior to the hardware component being powered on or reset, wherein the public key is stored in a BMC firmware image (Montero par. 0111 and 0115; EC 109A/B (as well as devices 401L-N) may be operational before host processor(s) 101, devices 401A-K, and/or host OS 300 are up and running . EC 109A/B may validate the PCIe-acquired EC firmware via using asymmetric cryptography (e.g., Elliptic Curve Cryptography or “ECC”), such that the firmware is signed with a private key on the build server and verified by IHS 100 with a matching public key on EC 109A/B (e.g., stored in its boot ROM firmware). Validating the EC firmware cryptographically before running it, as the very first device in platform 200A/B to run at the system level, alleviates potential security problems and enables EC 109A/B to act as the root of trust for IHS 100. See also claim 19, par. 0049 and 0123); and
allowing, by the BMC, the hardware component to boot from the firmware image in response to the firmware image passing the verification, wherein the firmware image is loaded from the non-volatile memory into a volatile memory of the hardware component and executed by the hardware component (Montero par. 0092, 0125 and 0114; In other embodiments, any given one of devices 401A-N may be rebooted or reset independently of the other devices to perform a local installation, update, or modification of that device's firmware services without having to reboot the entire heterogenous computing platform 200 and/or IHS 100. Additionally, or alternatively, one or more of devices 401A-N may have its firmware service at least partially installed or updated without rebooting or resetting the device . At 805, in response to a successful validation, verification, or authentication, EC 109A/B stores EC firmware instructions, configuration settings, or tables 706A-N in EC RAM 701 to be used during the current boot of IHS 100, in the next boot of IHS 100, and/or as part of rebootless firmware updates. Otherwise, EC 109A/B may reject EC firmware instructions, configuration settings, or tables 706A-N. In some cases, integrated EC 109A/B may have PCIe access tunneling through SOC 200C and into PCIe SSD or NVMe storage drives and it may retrieve EC firmware from those storage drives. Other PCIe access models may load the EC firmware image from a trusted network connection and/or from the cloud or Internet. As such, new PCIe connectivity and resources can provide alternatives to the otherwise conventional process of loading EC firmware from a flash device (e.g., SPI flash)).
Montero teaches wherein allowing, by the BMC, the hardware component to boot from the firmware image in response to the firmware image passing the verification from the non-volatile memory into a volatile memory of the hardware component and execute the firmware image (Montero par. 0114 and 0125). However, Montero does not explicitly disclose allowing, by the BMC, the hardware component to be powered on or reset and to boot from the firmware image in response to the firmware image passing the verification, wherein the firmware image is loaded from the non-volatile memory into a volatile memory of the hardware component and executed by the hardware component.
However, in an analogous art, Bhatia discloses allowing, by the BMC, the hardware component to be powered on or reset and to boot from the firmware image in response to the firmware image passing the verification, wherein the firmware image is loaded from the non-volatile memory into a volatile memory of the hardware component and executed by the hardware component (Bhatia par. 0026-0027 and 0046; The initialization component 192, among other things, performs hardware initialization during the booting process (power-on startup). After the hardware initialization is performed, the initialization component 192 can read a bootstrap loader from a predetermined location from a boot device of the storage device(s) 185, usually a hard disk of the storage device(s) 185, into the host memory 184, and passes control to the bootstrap loader. The bootstrap loader then loads an OS 194 into the host memory 184. When the data of the active initialization component image 191 are valid, the BMC 102 starts the timer 127-2 and the booting process of the host computer 180 with the active initialization component image 191 as an input. Accordingly, the host CPU 182 loads the active initialization component image 191 and executes the initialization component 192 from that image. See also par. 0025 and 0045).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the teachings of Bhatia with the method and system of Montero, wherein allowing, by the BMC, the hardware component to be powered on or reset and to boot from the firmware image in response to the firmware image passing the verification to provide users with a means for * (Bhatia).
Regarding claim 2, Montero and Bhatia disclose the method of claim 1,
Montero further discloses further comprising: preventing, by the BMC, the hardware component from booting from the firmware image in response to the firmware image failing the verification (Montero par. 0125; At 805, in response to a successful validation, verification, or authentication, EC 109A/B stores EC firmware instructions, configuration settings, or tables 706A-N in EC RAM 701 to be used during the current boot of IHS 100, in the next boot of IHS 100, and/or as part of rebootless firmware updates).
Regarding claim 3, Montero and Bhatia the method of claim 1,
Montero further discloses wherein the verifying the firmware image comprises: calculating a hash value of the firmware image; inputting the hash value and a digital signature stored with the firmware image into a signature verification algorithm; and receiving an output of the signature verification algorithm that indicates validity of the digital signature (Montero par. 0053-0054 and 0060; EC 109 calculate a hash value based on the configuration of a hardware and/or software component coupled to IHS 100. For instance, EC 109 may calculate a hash value based on all firmware and other code or settings stored in an onboard memory of a hardware component).
Regarding claim 4, Montero and Bhatia disclose the method of claim 3,
Montero further discloses wherein the digital signature comprises an Elliptic Curve Digital Signature Algorithm (ECDSA) signature generated by signing the hash value using a private key of the public-private key pair (Montero par. 0115; EC 109A/B may validate the PCIe-acquired EC firmware via using asymmetric cryptography (e.g., Elliptic Curve Cryptography or “ECC”), such that the firmware is signed with a private key on the build server and verified by IHS 100 with a matching public key on EC 109A/B (e.g., stored in its boot ROM firmware)).
Regarding claim 5, Montero and Bhatia disclose the method of claim 1,
Montero further discloses wherein the verifying the firmware image comprises: verifying integrity of a manifest table within the firmware image by calculating a hash of the manifest table and comparing the calculated hash to a stored hash value in the firmware image (Montero par. 0053-0054 and 0060; EC 109 calculate a hash value based on the configuration of a hardware and/or software component coupled to IHS 100. For instance, EC 109 may calculate a hash value based on all firmware and other code or settings stored in an onboard memory of a hardware component).
Regarding claim 7, Montero and Bhatia disclose the method of claim 1,
Montero further discloses wherein the hardware component is one of: a network interface card (NIC), a redundant array of independent disks (RAID) controller, a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), a graphics processing unit (GPU), or a Peripheral Component Interconnect Express (PCIe) switch (Montero abstract; A heterogeneous computing platform having a Reduced Instruction Set Computer (RISC) processor and a Peripheral Component Interconnect Express (PCIe) controller coupled thereto).
Regarding claim 8, Montero and Bhatia disclose the method of claim 1,
Montero further discloses the method further comprising: powering on the hardware component by the BMC after that the firmware image passes the verification (Montero par. 0111; In response to a power-on or reset event. As a result, EC 109A/B (as well as devices 401L-N) may be operational before host processor(s) 101, devices 401A-K, and/or host OS 300 are up and running).
Regarding claim 9, Montero and Bhatia disclose the method of claim 1,
Montero further discloses wherein the public key comprises an Elliptic Curve (EC) public key, and wherein the BMC firmware image stores X and Y components representing coordinates of the public key on an elliptic curve (Montero par. 0115; EC 109A/B may validate the PCIe-acquired EC firmware via using asymmetric cryptography (e.g., Elliptic Curve Cryptography or “ECC”)).
Regarding claim 10, Montero and Bhatia disclose the method of claim 1,
Montero further discloses wherein the verifying the firmware image comprises: verifying an initial boot block (IBB) of the firmware image using the public key, wherein the IBB comprises a first section of the firmware image; and allowing the hardware component to load and execute the IBB to verify remaining sections of the firmware image (Montero par. 0115; EC 109A/B (e.g., stored in its boot ROM firmware). Validating the EC firmware cryptographically before running it, as the very first device in platform 200A/B to run at the system level, alleviates potential security problems and enables EC 109A/B to act as the root of trust for IHS 100).
Regarding claims 11-15 and 17-19; claims 11-15 and 17-19 are directed to a baseboard management controller associated with the method claimed in claims 1-5 and 7-9 respectively. Claims 11-15 and 17-19 are similar in scope to claims 1-5 and 7-9 respectively, and are therefore rejected under similar rationale.
Regarding claim 20; claim 20 is directed to a non-transitory computer readable medium associated with the method claimed in claim 1. Claim 20 is similar in scope to claim 1, and is therefore rejected under similar rationale.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, FARID HOMAYOUNMEHR can be reached at 571-272-3739. 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.
/SANCHIT K SARKER/Primary Examiner, Art Unit 2495
Prosecution Insights