DETAILED ACTION
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 01/20/2026 has been entered. Claims 1-20 have been examined.
Response to Arguments
Applicant’s arguments, see Remarks – Page 7, filed on 12/22/2025, with respect to the rejection of claim 7 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Gehler.
Applicant argument #1
Applicant argues that Chandrasekaran does not teach the validating take place while every host processor is in low power state – See Remarks – Page 7.
Examiner Response to Applicant’s argument # 1
The examiner is respectfully disagrees. Chandrasekaran’s invention teaches that once the MCU blocks have been staged, MCU activation is initiated and each security unit validates the corresponding set of MCU blocks stored in its local staging memory. This may involve comparing the MCU blocks stored in the local memory with an MCU manifest or other relevant data provided via the mailbox. If all MCU blocks are validated, then, the MCU blocks are copied to the corresponding IP blocks of the SoC. For example, the security units may copy the MCU blocks from local staging SRAMs to patch memories used for microcode updates to corresponding IP blocks (See Abstract, ¶0190, ¶0220 – ¶0221).
Chandrasekaran further teaches that when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store it encrypted with integrity protection in the reserved area in the system memory. In certain embodiments, low power state exit code (e.g., restoration code) (e.g., implementing the TC6/TC7 exit restoration) causes the loading (e.g., copying) of the encrypted version of the extended patch content from the system memory, decrypting it, and storing (e.g., if authenticated) of the decrypted extended patch content back into the context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 SRAM). (¶0081, ¶0105, ¶ 0107).
Therefore, Based on the broadest reasonable interpretation of the claim language, the examiner interprets validating take place while every host processor is in low power state as equivalent to validating MCUs while processor is in TC6/TC7 low power state.
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.
Claims 1-4,10,13 are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran et al. Publication No. US 2025/0005159 A1 (Chandrasekaran hereinafter) in view of Hsu et al. Publication No. US 2009/0094414 A1 ( Hsu hereinafter) further in view of Yin et al. CN 115794173 B ( Yin hereinafter)
Regarding claim 1,
Chandrasekaran teaches an Information Handling System (HIS) (Fig.1), comprising:
a heterogeneous computing platform; and an Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into the heterogeneous computing platform, wherein the OOB MCU is configured to receive a firmware update command (Abstract, Fig.29, ¶0186, ¶0223 - Alternatively, or additionally, microcode updates may be performed by an external management controller such as a Baseboard Management Controller (BMC). In this implementation, the MCU blocks are provided to the BMC through an out-of-band (OOB) interface - ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged),
validate, using a crypto device, a firmware payload associated with the firmware update command; and cause the validated firmware payload to be installed on a memory of the target device while the host processor is in the low-power state. ( ¶0190 - To reduce the service blackout time during microcode updates, embodiments of the invention split the microcode update int two phases: (1) MCU staging and (2) MCU activation. In the first phase, MCU staging, components of the unified microcode are validated and copied from linear memory address space into an internal processor memory ( e.g., an SRAM memory such as a cache). – ¶ 0223 - The BMC communicates to the SoC through an off-package interface such as a Platform Environment Control Interface, and stage the microcode in the SoC SRAM(s). Once staged, the SoC performs the microcode authentication as previously described. If authenticated, the BMC instructs the SoC to activate the firmware ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction. A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction ). A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232, ¶0188 ).
Chandrasekaran teaches a host processor of the heterogeneous computing platform is in a low power state (Fig.6, ¶0080- ¶0081, ¶0099, ¶0107 )
However, Chandrasekaran does not explicitly teach receive a firmware update command subsequent to a host processor is in low power state.
Hsu teaches
receive a firmware update command subsequent to a host processor is in low power state (¶0015 - The optical disc drive 100 of this embodiment has a normal operation mode and a firmware update mode. When the optical disc drive 100 is under the normal operation mode, the memory update controller 142 is in an idle state. Through the data bus 141, the processor 144 accesses the firmware stored in the firmware memory 130. The processor 144 controls ordinary operations of the optical disc drive 100 by executing the firmware stored in the firmware memory 130. When a firmware update is required, the processor 144 controls the optical disc drive 100 to fetch an update firmware, e.g. from the optical disc 102, and store the update firmware into the buffer memory 120 in the same manner as if the update firmware is ordinary information. The update firmware can also be stored in the buffer memory 120 with a specific format, such as a table of content (TOC) format. After the update firmware is retrieved and stored into the buffer memory 120, the optical disc drive 100 enters the firmware update mode. Under the firmware update mode, the processor 144 is in an idle state; the memory update controller 142 becomes a dedicated hardware for updating the firmware. Without utilizing the processor 144 to execute an update routine code, the memory update controller 142 fetches the update firmware from the buffer memory 120 (e.g., through the decoder 146), and updates the firmware memory 130).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Hsu. The motivation for doing so is to allow system to fetch the update firmware from the buffer memory and stores the update firmware into the firmware memory without the processor executing an update routine code ( Hsu – Abstract).
Yin teaches
wherein the firmware update command indicates a target device (Abstract, Claim 1 wherein the firmware upgrade instruction includes firmware version information, and the firmware upgrade for the solid state disk according to the firmware upgrade instruction includes: and carrying out firmware upgrading on the solid state disk by adopting the firmware version information).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran in view of Hsu to include the teachings of Yin. The motivation for doing so is to allow system to perform power-down processing, control each unit in the solid state disk to be switched to a standby state so as to ensure data consistency before and after upgrading ( Yin – Abstract).
Regarding claim 2,
Chandrasekaran further teaches
wherein the heterogeneous computing platform comprises: a System-On-Chip (SoC), a Field-Programmable Gate Array (FPGA), or an Application-Specific Integrated Circuit (ASIC) (Fig.30, ¶0182, ¶ 226 - The output information may be applied to one or more output devices, in known fashion. For purposes of this application, a processing system includes any system that has a processor, such as, for example, general purpose computing device, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor (e.g., a system-on-chip or SoC).
Regarding claim 3,
Chandrasekaran further teaches
wherein the heterogeneous computing platform comprises a Reduced Instruction Set Computer (RISC) processor and a plurality of devices coupled to an interconnect (¶ 0124 - The core 1390 may be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 1390 may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like – ¶ 0044 - Depicted processor 104 is a multicore processor including core circuitry 112 having a plurality of cores 110_0 to ll0_N, where N is any integer. In another embodiment,
processor only includes a single core. Cores 110_0 to ll0_N may be coupled to each other via interconnect 116 or other electrical coupling. Each core may include the components discussed herein, for example, as shown in FIG. 2 or 3. Depicted processor 104 includes non-core circuitry 114 separate from (e.g., outside of) the core circuitry 112. Non-core circuitry 114 may include any combination of shared cache 118 (e.g., static random-access memory . interface 122 ( e.g., to provide a coupling to various components that are not part of processor 104), such as, but not limited to, peripheral devices, mass storage, etc.).
Regarding claim 4,
Chandrasekaran further teaches
wherein the plurality of devices comprises at least one of: a Graphical Processing Unit (GPU), an audio Digital Signal Processor (aDSP), a sensor hub, a Neural Processing Unit (NPU), a Tensor Processing Unit (TPU), a Neural Network Processor (NNP), an Intelligence Processing Unit (IPU), an Image Signal Processor (ISP), or a Video Processing Unit (VPU) (¶ 0124 - As yet another option, the core 1390 may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like).
Regarding claim 10,
Chandrasekaran teaches
wherein the target device, the OOB MCU is configured to transmit the validated firmware payload to the target device via a [..] bandwidth bus controller while the host processor is in the low-power state (¶ 00216 - Once the security units 2904A-C verify that each manifest is identical to the staged images, it copies/installs the IP images from the staging SRAMs 2905A-C to the local IP blocks ( e.g., storing the staged portions of the MCU into corresponding microcode patch memories as described above - – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232 ).
However, Chandrasekaran does not explicitly teach
wherein the target device comprises a Peripheral Component Interconnect (PCI) or Universal Serial Bus (USB) device and the bus is high bandwidth bus controller
Yin teaches
wherein the target device comprises a Peripheral Component Interconnect (PCI) or Universal Serial Bus (USB) device (Page 5 - In particular, the serial communication unit may be PCIe (Peripheral Component Interconnect Express, high speed serial computer expansion bus) and the internal process interaction unit may include an IPC internal information interaction network),
the bus controller is a high-bandwidth bus controller (Page 6 - In particular, the serial communication unit may be PCIe (Peripheral Component Interconnect Express, high speed serial computer expansion bus) and the internal process interaction unit may include an IPC internal information interaction network. The PCIe is used as a hardware unit interface for interacting with the Host, and can support setting of Pause (Pause) and Normal modes, where the Pause mode and the Normal mode are two modes supported by PCIe, and can be set by control through firmware, and in Normal working condition, the PCIe interaction mode is the Normal mode, all instructions from Host can be received at this time, when firmware upgrading is needed, the PCIe interaction mode can be set to the Pause mode after an upgrade instruction is received, no instruction is acquired from the Host before the firmware upgrading is completed, only instructions in the solid state disk are processed, and when the firmware upgrading is completed, that is, after the firmware is switched from the old version firmware to the new version firmware, the PCIe interaction mode can be reset to the Normal mode, so that the instructions from the Host can be continuously accepted and processed).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Yin. The motivation for doing so is to allow system to use the PCI in order to improve performance in graphics , and enabling easy upgrades.
Regarding claim 13,
Chandrasekaran teaches
wherein the target device comprises the OOB MCU, and wherein to cause the validated firmware payload to be installed, the OOB MCU is configured to install the validated firmware payload upon an [..] memory while the host processor is in the low-power state( ¶0190 - To reduce the service blackout time during microcode updates, embodiments of the invention split the microcode update int two phases: (1) MCU staging and (2) MCU activation (blocking). In the first phase, MCU staging, components of the unified microcode are validated and copied from linear memory address space into an internal processor memory ( e.g., an SRAM memory such as a cache). – ¶ 0223 - The BMC communicates to the SoC through an off-package interface such as a Platform Environment Control Interface, and stage the microcode in the SoC SRAM(s). Once staged, the SoC performs the microcode authentication as previously described. If authenticated, the BMC instructs the SoC to activate the firmware ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange (DOE) mailbox interface. the DOE mailbox interface is exposed by an out-of-band management services module (OOBMSM), a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction. A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction such as WRMSR 79h). A mailbox session is established allowing an SoC manifest from the microcode 2903 to be provided to the security processor – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232 ).
However, Chandrasekaran does not explicitly teach the memory is integrated flash memory.
Hsu teaches
the MCU is configured to install the firmware payload upon an integrated flash memory (¶ 0019 – For example, consider that the firmware memory 130 is a flash memory. In this example, there exist multiple methods to update the firmware stored in the firmware memory 130. One is to update the firmware memory 130 in a byte-by-byte manner, and the other is to update the firmware
memory 130 in a page-by-page manner -See ¶ 0013)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Hsu. The motivation for doing so is to allow system to use flash memory due to its fast data access and low power consumption.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Varma et al. Patent No. US 11,295,052 B1 ( Varma hereinafter).
Regarding claim 5,
Chandrasekaran does not explicitly teach
wherein the interconnect comprises at least one of: an Advanced Microcontroller Bus Architecture (AMBA) bus, a Quick Path Interconnect (QPI) bus, or a Hyper Transport (HT) bus.
However, Varma teaches
interconnect comprises at least one of: an Advanced Microcontroller Bus Architecture (AMBA) bus, a Quick Path Interconnect (QPI) bus, or a Hyper Transport (HT) bus ( Col.5 Lines 35-40 - As an example, a control register read of the GPU 160 by the CPU 125 is initiated as a System C transaction, reach an AMBA transactor (XTOR) in the transaction interface 155 as a target, and get converted to AMBA bus signal protocol by the AMBA XTOR block as master with the GPU 160 as slave, and transmitted through the AMBA bus 170 to the GPU 160) .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Varma. The motivation for doing so is to allow system to reduce SoC development costs and timescales.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Fiebrich et al. Publication No. US 2022/0006318 A1 (Fiebrich hereinafter)
Regarding claim 6,
Chandrasekaran teaches the power state comprises ACPI ( ¶0045, ¶0119). However, Chandrasekaran does not explicitly teach
wherein the low-power state comprises an Advanced Configuration and Power Interface (ACPI) G3 state.
Fiebrich teaches
low-power state comprises an Advanced Configuration and Power Interface (ACPI) G3 state (¶0015 - the IHS 100 may be put into extremely low power consumption states. From these states, the controller 122 and/or the IHS 100 may be quickly awakened by general purpose events, such as, interrupts, the clock, the keyboard, a modem, and/or a variety of other events. When a notebook-type IHS 100 is powered off, with only battery power inserted, (e.g., not plugged in) the IHS 100 may be set to the ACPI G3 power state, which consumes almost no power, and thus maintains a long battery life. However, supporting the USB charging feature on an IHS 100 poses a problem of how to wake from ACPI G3 state to ACPI S5 state to allow charging of the peripheral device battery and how to best manage the power states to maximize battery life. It should be understood that any state change may be utilized with the present disclosure).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Fiebrich. The motivation for doing so is to allow system to consumes almost no power, and thus maintains a long battery life.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Gehler et al. “Intel® Converged Security and Management Engine (Intel® CSME) Security” – Technical White Paper – October 2022 ( Gehler hereinafter)
Regarding claim 7,
Chandrasekaran does not explicitly teach
wherein the crypto device comprises at least one of: a Secure Processing Unit (SPU), or a crypto offload engine.
However, Gehler teaches
crypto device comprises at least one of:, a Secure Processing Unit (SPU), or a crypto offload engine (Page 11 - OCS (Offload and Cryptography Subsystem) is a Cryptography-HW accelerator with DMA (Direct-Memory-Access) engine and Secure-Key-Storage (SKS) Hardware – Page 8 - Intel® CSME role is essential in the platform silicon initialization and platform boot. It is responsible for: Authentication and loading of FW into HW engines (aka IPs) integrated within the main CPU and PCH - DRM (Digital-Right Management) and Intel® Active Management Technology (Intel® AMT), which requires hardware level security to be available when the host is not responding or is powered down).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Gehler. The motivation for doing so is to allow system to ensure that firmware use keys without knowing their plaintext value (Gehler – Page 11).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Pillilli et al. Publication No. US 2021/0224061 A1 (Pillilli hereinafter)
Regarding claim 8,
Chandrasekaran does not explicitly teach
wherein to validate the firmware payload, the OOB MCU or the crypto device is configured to select a public cryptographic key associated with the target device or a vendor of the target device
However, Pillilli teaches
wherein to validate the firmware payload, the OOB MCU or the crypto device is configured to select a public cryptographic key associated with the target device or a vendor of the target device ( ¶ 0036 - MC 220 can write the patch into flash memory 230. At (3), PRoT 210 can verify the patch by performing network and source verifications. For example, a hash can be performed on the patch to determine if the hash generates an expected value. Verification can include determining if certificate associated with the patch or a calculation matches an expected certificate or value. The certificate can be compatible with X.509 or other standards such as Simple Product Key Infrastructure (SPKI) or Pretty Good Privacy (PGP). An X.509 certificate can include a digital certificate that uses X.509 public key infrastructure (PKI) standard to verify that a public key belongs to a user. If authentication fails (not shown), however, the patch can be rejected and an administrator alerted to take action and identify potentially malicious behavior to access a firmware or to update certificates used for authentication – ¶ 0010 - The PRoT can perform vendor specific authentication of the firmware image ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Pillilli. The motivation for doing so is to allow system to use encryption scheme to enhance security.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Sarangdhar et al. Publication No. US 2015/0277930 A1 (Sarangdhar hereinafter)
Regarding claim 9,
Chandrasekaran teaches OOB MCU ( ¶ 0223 ). However, Chandrasekaran does not explicitly teach
MCU is configured to wake up the crypto device while the host processor is in the low-power state
Sarangdhar teaches
MCU is configured to wake up the crypto device while the host processor is in the low-power state (Fig.5, ¶ 0074 - the system can trigger a sleep or power-down state for the controller, 626. The system can also generate a wake up event for the controller, 502 (from process 500), which will cause the controller to seek for firmware and provision the firmware when no valid firmware is found – ¶ 0041 - CSME 230 represents a manageability engine. A manageability engine is one type of hardware platform controller. In one embodiment, CSME 230 can be a converged security and manageability engine, which includes logic to perform operations related to both security on hardware platform system 200 as well as management of access to resources on the hardware platform. For purposes of system 200, CSME 230 determines that the hardware platform whether the hardware platform includes valid or functional firmware on nonvolatile storage device 240. In one embodiment, CSME 230 accesses external interface 250 to obtain firmware if the hardware platform lacks functional firmware. In one embodiment, storage 240 stores a primary firmware image and one or more backup firmware images. Thus, CSME 230 can first determine whether storage 240 includes a functional or operational primary firmware image. If there is no functional primary firmware image, - ¶ 0046 - CSME 310 is or includes a processor device or controller device. CSME 310 includes ROM code (not specifically shown in system 300) that initiates operation 310 is powered up or wakes from a low power state).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Sarangdhar. The motivation for doing so is to allow system to provision new firmware (Sarangdhar– ¶0074).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Olarig et al. Publication No. US 2018/0101376 A1 ( Olarig hereinafter)
Regarding claim 11,
Chandrasekaran further teaches
wherein the target device comprises an Inter-Integrated Circuit (I2C) or Improved I2C (I3C) device (¶ 0223 - wherein the target device comprises an Inter-Integrated Circuit (I2C) or Improved I2C (I3C) device, and wherein to cause the validated firmware payload to be installed, the OOB MCU is configured to transmit the validated firmware payload to the target device via a low-bandwidth bus controller while the host processor is in the low-power state), and
wherein to cause the validated firmware payload to be installed, the OOB MCU is configured to transmit the validated firmware payload to the target device via a [..] bandwidth bus controller while the host processor is in the low-power state(¶ 00216 - Once the security units 2904A-C verify that each manifest is identical to the staged images, it copies/installs the IP images from the staging SRAMs 2905A-C to the local IP blocks ( e.g., storing the staged portions of the MCU into corresponding microcode patch memories as described above – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232 ).
However, Chandrasekaran does not explicitly teach
transmit the validated firmware payload to the target device via a low bandwidth bus controller
Olarig teaches
transmit the validated firmware payload to the target device via a low bandwidth bus controller (¶ 0006 – The system downtime may be further prolonged when the SSD firmware upgrade is performed across a low-speed bus such as an NVMe management interface bus – ¶ 0025 - the BMC can receive various commands from a host, either local or remote, and execute the received commands via an out-of-band control plane via the NVMe management interface bus. Examples of such commands operable over NVMe management interface bus include, but are not limited to, discovering, monitoring, and upgrading a firmware upgrade on the attached NVMeoF devices. The BMC validates the firmware image downloaded to the target NVMeoF device(s) and performs a reset of the NVMeoF device(s) to activate the new firmware – See ¶ 0039).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Olarig. The motivation for doing so is to allow system to use the low bandwidth buses due to their cost-effectiveness and simplicity, making it suitable for applications where high data throughput isn't critical.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Yin further in view of Olarig further in view of Frid et al. Publication No. US 2004/0030877 A1 ( Frid hereinafter)
Regarding claim 12,
Chandrasekaran teaches
wherein the target device comprises an Inter-Integrated Circuit (I2C) or Improved I2C (I3C) device (¶ 0223 - wherein the target device comprises an Inter-Integrated Circuit (I2C) or Improved I2C (I3C) device, and wherein to cause the validated firmware payload to be installed, the OOB MCU is configured to transmit the validated firmware payload to the target device via a low-bandwidth bus controller while the host processor is in the low-power state. , and
wherein to cause the validated firmware payload to be installed, the OOB MCU is configured to transmit the validated firmware payload, via [..] bandwidth bus controller, [..] to the target device while the host processor is in the low-power state (¶ 00216 - Once the security units 2904A-C verify that each manifest is identical to the staged images, it copies/installs the IP images from the staging SRAMs 2905A-C to the local IP blocks ( e.g., storing the staged portions of the MCU into corresponding microcode patch memories as described above - – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232 ).
However, Chandrasekaran does not explicitly teach
transmit the validated firmware payload, via a low-bandwidth bus controller, to an Embedded Controller (EC) coupled to the target device
Olarig teaches
transmit the validated firmware payload to the target device via a low bandwidth bus controller (¶ 0006 – The system downtime may be further prolonged when the SSD firmware upgrade is performed across a low-speed bus such as an NVMe management interface bus – ¶ 0025 - the BMC can receive various commands from a host, either local or remote, and execute the received commands via an out-of-band control plane via the NVMe management interface bus. Examples of such commands operable over NVMe management interface bus include, but are not limited to, discovering, monitoring, and upgrading a firmware upgrade on the attached NVMeoF devices. The BMC validates the firmware image downloaded to the target NVMeoF device(s) and performs a reset of the NVMeoF device(s) to activate the new firmware – See ¶ 0039).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Olarig. The motivation for doing so is to allow system to use the low bandwidth buses due to their cost-effectiveness and simplicity, making it suitable for applications where high data throughput isn't critical.
Frid teaches
transmit the validated firmware payload, via a bandwidth bus controller, to an Embedded Controller (EC) coupled to the target device ( ¶ 0022- An embedded controller firmware image as well as a firmware update algorithm or procedure are provided 31 as part of the BIOS. The computer system 10 is booted 32. During booting, or start-up, the system BIOS reads 33 firmware identification data from the embedded controller and compares it with corresponding data in the firmware image that is part of the BIOS. This firmware identification data may be a fixed firmware validation signature the system BIOS makes a decision 34 (see also FIG. 3) as to whether embedded controller firmware 26 should be updated. [0023] If a Yes decision 342 is made, the system BIOS carries out 35 or runs 35 the update algorithm or procedure which copies the new firmware image from the system BIOS stored in the critical nonvolatile storage device 12 into the embedded controller firmware storage device 24).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Frid. The motivation for doing so is to allow system to update (flash) embedded controller firmware in production level computers under end-user operating system control (Abstract, Frid).
Claim 14 are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu in view of Yin further in view of Li et al. Publication No. US 2022/0261235 A1 ( Li hereinafter)
Regarding claim 14,
Chandrasekaran teaches
wherein the target device comprises [..] memory, and wherein to cause the validated firmware payload to be installed, the OOB MCU is configured to transmit the validated firmware payload to the target device [..] while the host processor is in the low-power state¶0190 - To reduce the service blackout time during microcode updates, embodiments of the invention split the microcode update int two phases: (1) MCU staging and (2) MCU activation (blocking). In the first phase, MCU staging, components of the unified microcode are validated and copied from linear memory address space into an internal processor memory ( e.g., an SRAM memory such as a cache). – ¶ 0223 - The BMC communicates to the SoC through an off-package interface such as a Platform Environment Control Interface, and stage the microcode in the SoC SRAM(s). Once staged, the SoC performs the microcode authentication as previously described. If authenticated, the BMC instructs the SoC to activate the firmware ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange (DOE) mailbox interface, the DOE mailbox interface is exposed by an OOBMSM, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox 2906 to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction. A mailbox session is established allowing an SoC manifest from the microcode 2903 to be provided to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction). A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232 ).
However, Chandrasekaran does not explicitly teach
wherein the target device comprises a flash memory, transmit the firmware payload to the target device via a flash arbitration circuit
Li teaches
wherein the target device comprises a flash memory and wherein to cause the firmware payload to be installed, MCU is configured to transmit the firmware payload to the target device via circuit (¶ 0037 – More specifically, when not receiving an update instruction, the MCU 11 operates in a normal mode, and the bus arbiter 12 reads the function return value RTN in the cache memory 162 via the first bus 161 for being replied to a function called by the MCU 11. [0038] After receiving the update instruction, the MCU 11 enters a void mode ( or called update mode). In the void mode, the bus arbiter 12 receives update data Data_upd from the MCU 11 and sends the update data Data_upd to the flash controller 161 via the second bus 142 (without passing the first bus 141) so as to update the first firmware in the flash memory 162 via the flash controller 161.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Li. The motivation for doing so is to allow system to use arbiter to ensure that only one device gains access to the flash at a time.
Claims 15,16,18,19 are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu
Regarding claim 15,
Chandrasekaran teaches an Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into a heterogeneous computing platform of an Information Handling System (IHS), the OOB MCU (Fig.1, Abstract, ¶0013), comprising:
a processing core distinct from any host processor of the heterogeneous computing platform; and a memory coupled to the processing core, the memory having program instructions stored thereon that, upon execution by the processing core, cause the OOB MCU to , receiving a command ofr a firmware update of a target device ( Abstract, Fig.29, ¶0186, ¶0223 - Alternatively, or additionally, microcode updates may be performed by an external management controller such as a Baseboard Management Controller (BMC). In this implementation, the MCU blocks are provided to the BMC through an out-of-band (OOB) interface - ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged),
validate a firmware payload associated with the command; and install the firmware payload on a memory coupled to the target device ( ¶0190 - To reduce the service blackout time during microcode updates, embodiments of the invention split the microcode update int two phases: (1) MCU staging and (2) MCU activation. In the first phase, MCU staging, components of the unified microcode are validated and copied from linear memory address space into an internal processor memory ( e.g., an SRAM memory such as a cache). – ¶ 0223 - The BMC communicates to the SoC through an off-package interface such as a Platform Environment Control Interface, and stage the microcode in the SoC SRAM(s). Once staged, the SoC performs the microcode authentication as previously described. If authenticated, the BMC instructs the SoC to activate the firmware ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction. A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction ). A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – See ¶0099, ¶0232, ¶0188 ).
Chandrasekaran does not explicitly teach receive a firmware update command of a target device subsequent to a processing core being in low power state
Hsu teaches
receive a firmware update command of a target device subsequent to a processing core being in low power state (Para 0015 - The optical disc drive 100 of this embodiment has a normal operation mode and a firmware update mode. When the optical disc drive 100 is under the normal operation mode, the memory update controller 142 is in an idle state. Through the data bus 141, the processor 144 accesses the firmware stored in the firmware memory 130. The processor 144 controls ordinary operations of the optical disc drive 100 by executing the firmware stored in the firmware memory 130. When a firmware update is required, the processor 144 controls the optical disc drive 100 to fetch an update firmware, e.g. from the optical disc 102, and store the update firmware into the buffer memory 120 in the same manner as if the update firmware is ordinary information. The update firmware can also be stored in the buffer memory 120 with a specific format, such as a table of content (TOC) format. After the update firmware is retrieved and stored into the buffer memory 120, the optical disc drive 100 enters the firmware update mode. Under the firmware update mode, the processor 144 is in an idle state; the memory update controller 142 becomes a dedicated hardware for updating the firmware. Without utilizing the processor 144 to execute an update routine code, the memory update controller 142 fetches the update firmware from the buffer memory 120 (e.g., through the decoder 146), and updates the firmware memory 130).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Hsu. The motivation for doing so is to allow system to fetch the update firmware from the buffer memory and stores the update firmware into the firmware memory without the processor executing an update routine code. ( Hsu – Abstract).
Regarding claim 16,
Chandrasekaran further teaches
wherein the program instructions, upon execution, further cause the OOB MCU to validate the firmware payload using a crypto device integrated into the heterogeneous computing platform and coupled to the OOB MCU via an interconnect ( ¶0190 - To reduce the service blackout time during microcode updates, embodiments of the invention split the microcode update int two phases: (1) MCU staging and (2) MCU activation. In the first phase, MCU staging, components of the unified microcode are validated and copied from linear memory address space into an internal processor memory ( e.g., an SRAM memory such as a cache). – ¶ 0223 - The BMC communicates to the SoC through an off-package interface such as a Platform Environment Control Interface, and stage the microcode in the SoC SRAM(s). Once staged, the SoC performs the microcode authentication as previously described. If authenticated, the BMC instructs the SoC to activate the firmware ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction. A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction ). A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232, ¶0188 ).
Regarding claim 18,
Chandrasekaran teaches a method, comprising: comprising:
receiving, at an Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into a heterogeneous computing platform having one or more host processors, a firmware update of a target device external to the heterogeneous computing platform Abstract, Fig.29, ¶0186, ¶0223 - Alternatively, or additionally, microcode updates may be performed by an external management controller such as a Baseboard Management Controller (BMC). In this implementation, the MCU blocks are provided to the BMC through an out-of-band (OOB) interface - ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged ),
validating, by the OOB MCU using a crypto device, a firmware payload associated with the OOB command; and causing the validated firmware payload to be installed on a memory associated with the target device( ¶0190 - To reduce the service blackout time during microcode updates, embodiments of the invention split the microcode update int two phases: (1) MCU staging and (2) MCU activation. In the first phase, MCU staging, components of the unified microcode are validated and copied from linear memory address space into an internal processor memory ( e.g., an SRAM memory such as a cache). – ¶ 0223 - The BMC communicates to the SoC through an off-package interface such as a Platform Environment Control Interface, and stage the microcode in the SoC SRAM(s). Once staged, the SoC performs the microcode authentication as previously described. If authenticated, the BMC instructs the SoC to activate the firmware ¶ 0210 - ¶0213 - software pushes the firmware update through a data object exchange mailbox interface . In the illustrated embodiment, the DOE mailbox interface is exposed by an out-of-band management services module, a hardware device which provides access to the capabilities. Within the SoC, the OOBMSM establishes a session with a mailbox to securely pass the microcode blocks to the security processor 2904. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction. A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor. After the entire SoC image is staged, the host software triggers an activation process ( e.g., executing a write MSR instruction ). A mailbox session is established allowing an SoC manifest from the microcode to be provided to the security processor – ¶ 0081 - one embodiment when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store is encrypted with integrity protection in the reserved area in the system memory – Se e¶0099, ¶0232, ¶0188 ).
Chandrasekaran teaches every host processor of the heterogeneous computing platform is in a low power state (Fig.6, ¶0080- ¶0081, ¶0099, ¶0107 )
However, Chandrasekaran does not explicitly teach receive a firmware update command subsequent to every host processor is in low power state
Hsu teaches
receive a firmware update command subsequent to every host processor is in low power state (Para 0015 - The optical disc drive 100 of this embodiment has a normal operation mode and a firmware update mode. When the optical disc drive 100 is under the normal operation mode, the memory update controller 142 is in an idle state. Through the data bus 141, the processor 144 accesses the firmware stored in the firmware memory 130. The processor 144 controls ordinary operations of the optical disc drive 100 by executing the firmware stored in the firmware memory 130. When a firmware update is required, the processor 144 controls the optical disc drive 100 to fetch an update firmware, e.g. from the optical disc 102, and store the update firmware into the buffer memory 120 in the same manner as if the update firmware is ordinary information. The update firmware can also be stored in the buffer memory 120 with a specific format, such as a table of content (TOC) format. After the update firmware is retrieved and stored into the buffer memory 120, the optical disc drive 100 enters the firmware update mode. Under the firmware update mode, the processor 144 is in an idle state; the memory update controller 142 becomes a dedicated hardware for updating the firmware. Without utilizing the processor 144 to execute an update routine code, the memory update controller 142 fetches the update firmware from the buffer memory 120 (e.g., through the decoder 146), and updates the firmware memory 130).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Hsu. The motivation for doing so is to allow system to fetch the update firmware from the buffer memory and stores the update firmware into the firmware memory without the processor executing an update routine code. ( Hsu – Abstract).
Regarding claim 19,
Chandrasekaran teaches
wherein the validating, and causing take place while every host processor of the heterogeneous computing platform is in a low-power state. ( Chandrasekaran - Abstract, ¶0190, ¶0220 – ¶0221once the MCU blocks have been staged, MCU activation is initiated and each security unit validates the corresponding set of MCU blocks stored in its local staging memory. This may involve comparing the MCU blocks stored in the local memory with an MCU manifest or other relevant data provided via the mailbox. If all MCU blocks are validated, then, the MCU blocks are copied to the corresponding IP blocks of the SoC. For example, the security units may copy the MCU blocks from local staging SRAMs to patch memories used for microcode updates to corresponding IP blocks- ¶0081, ¶0105, ¶ 0107 - when the second mode is enabled, at the patch load time, if the reserved area was allocated prior to the microcode patch load trigger operation, the load time microcode patch section will store the extended patch content (e.g., micro-operations) in the corresponding thread's context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 section of SRAM) and will also store it encrypted with integrity protection in the reserved area in the system memory. In certain embodiments, low power state exit code (e.g., restoration code) (e.g., implementing the TC6/TC7 exit restoration) causes the loading (e.g., copying) of the encrypted version of the extended patch content from the system memory, decrypting it, and storing (e.g., if authenticated) of the decrypted extended patch content back into the context information storage section (e.g., for TC6/TC7 low power states) of the cache (e.g., C6 SRAM).).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Pillilli.
Regarding claim 17,
Chandrasekaran teaches validating the firmware payload (¶0190, ¶ 0210 - ¶0213 , ¶ 0081,¶0232, ¶0188). However, Chandrasekaran does not explicitly teach
the crypto device is configured to select a public cryptographic key associated with the target device or a vendor of the target device.
However, Pillilli teaches
crypto device is configured to select a public cryptographic key associated with the target device or a vendor of the target device.( ¶ 0036 - MC 220 can write the patch into flash memory 230. At (3), PRoT 210 can verify the patch by performing network and source verifications. For example, a hash can be performed on the patch to determine if the hash generates an expected value. Verification can include determining if certificate associated with the patch or a calculation matches an expected certificate or value. The certificate can be compatible with X.509 or other standards such as Simple Product Key Infrastructure (SPKI) or Pretty Good Privacy (PGP). An X.509 certificate can include a digital certificate that uses X.509 public key infrastructure (PKI) standard to verify that a public key belongs to a user. If authentication fails (not shown), however, the patch can be rejected and an administrator alerted to take action and identify potentially malicious behavior to access a firmware or to update certificates used for authentication – ¶ 0010 - The PRoT can perform vendor specific authentication of the firmware image ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Pillilli. The motivation for doing so is to allow system to validate and authentical device firmware patching (Pillilli – ¶0036).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran in view of Hsu further in view of Baryudin et al. Publication No. US 20140215123 A1 ( Baryudin hereinafter)
Regarding claim 20,
Chandrasekaran teaches the OOB command is received within the packet (, ¶ 0210 - ¶0213 ). Chandrasekaran does not explicitly teach that the packet is opaque packet.
Baryudin teaches that the packet is an opaque packet (¶ 0016,[¶ 0022).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekaran to include the teachings of Baryudin. The motivation for doing so is to allow system to enhance security by obscuring data and allow for better resource management.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 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, Oscar A Louie can be reached on (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445