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 3/19/2026 has been entered.
Response to Amendment
This is in response to the amendments filed on 3/19/2026. Claims 1, 11, 12, and 16 have been amended. Claims 1-20 are currently pending and have been considered below.
Response to Arguments
Applicant's arguments filed 3/19/2026 have been fully considered but they are not persuasive. On pages 9 and 10 of Remarks, Applicant contends that Savage, Khatri, Stewart, and/or Pan does not teach or suggest, “based on an address of the one or more addresses specified by the factory-provisioned firmware certificate, retrieve firmware that resolves the identified firmware discrepancy” and “the factory-provisioned factory certificate specifies … factory-provisioned firmware” and “one or more addresses where the factory-provisioned firmware may be retrieved”. The examiner respectfully disagrees. As was previously cited, Pan discloses receiving a factory-provisioned certificate (see Pan, ¶0004; ¶0078; ¶0080) that includes at least one address to retrieve factory-provisioned firmware (see Pan, ¶0131) and where the factory-provisioned firmware is specified by the certificate for use for the hardware terminal (see Pan, ¶0131 which discloses a version of the firmware to retrieve as part of the URL). Pan continues to disclose at ¶0132 that a further URL can be provided to account for an update in the firmware for the hardware terminal.
Therefore, given the above and further citations to Pan in the rejection below, the examiner asserts that Pan fully teaches and suggests “based on an address of the one or more addresses specified by the factory-provisioned firmware certificate, retrieve firmware that resolves the identified firmware discrepancy”, “the factory-provisioned factory certificate specifies … factory-provisioned firmware”, and “one or more addresses where the factory-provisioned firmware may be retrieved”, and thus the rejection is sustained.
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.
Claim(s) 1-3, 6, 10-14, and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Savage” (US 2023/0130694) in view of “Khatri” (US 2023/0011005) in view of “Stewart” (US 2025/0077675) in further view of “Pan” (US 2022/0417039).
Regarding Claim 1:
Savage teaches:
An IHS (Information Handling System) (Fig. 2) comprising:
one or more processors (Fig. 2, element 205);
one or more memory devices coupled to the processors, the memory devices storing computer-readable instructions that, upon execution by the processors, cause a validation process of the IHS (Fig. 2, element 210) to:
validate detected hardware of the IHS as factory-installed hardware based on an inventory specified in a … certificate stored by the IHS (Fig. 6, step 665; ¶0090, “At block 665, the inventory certificate validation process continues the comparison of the detected hardware components of the initialized IHS against the identities of the hardware components that are included in the signed inventory certificate, and in particular against the signed inventory of the factory installed hardware components that is included in the signed inventory certificate”);
validate firmware detected for operation by factory-installed hardware as factory-provisioned firmware based on an inventory specified in a factory-provisioned firmware certificate stored by the IHS (Fig. 6, step 667; ¶0017, “FIG. 6 is a flowchart describing certain steps of an additional method, according to some embodiments, for validating the firmware used by various hardware components of the IHS corresponds to a fixed firmware profile for the IHS”); and
when the detected firmware is not validated based on the factory-provisioned firmware certificate (¶0095, “In scenarios where the collected firmware information does not match the firmware information specified in the inventory certificate, at 680, the validation process may signal a validation failure, and in particular, a failure to validate the use of the fixed firmware profile specified in the inventory certificate”):
identify a firmware discrepancy causing a validation failure and halt booting of the IHS until the identified firmware discrepancy is resolved (¶0095, “In response to a firmware validation failure, some embodiments may prevent any further booting of the IHS. In such instances, the IHS remains inoperable until the firmware in use by the IHS is reverted to the firmware of the fixed firmware profile that is specified in the inventory certificate”);
…
Savage does not disclose:
validate detected hardware of the IHS as factory-installed hardware based on an inventory specified in a factory-provisioned inventory certificate stored by the IHS, wherein the factory-provisioned firmware certificate specifies:
the factory-provisioned firmware specified for use with factory-installed hardware of the IHS; and
one or more addresses where the factor-provisioned firmware may be retrieved; and
…
based on an address of the one or more addresses specified by the factory-provisioned firmware certificate, retrieve firmware that resolves the identified firmware discrepancy; and
based on resolving the identified firmware discrepancy, continue booting of the IHS.
Khatri teaches:
validate detected hardware of the IHS as factory-installed hardware based on an inventory specified in a factory-provisioned inventory certificate stored by the IHS (¶0062, “At 760, the generated certificate, referred to herein as an owner certificate, is returned to the security chip, where it is stored according to instructions provided in the owner boot code being run by the security chip. As described in additional detail with regard to FIG. 8A, the stored owner certificate may be retrieved and used to validate the authenticity of the motherboard as being the same motherboard installed during manufacture of the IHS …”; ¶0068, “Whereas the CSR for the owner certificate is submitted to the factory provisioning HSM…”) … ;
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Savage’s firmware validation system by enhancing Savage’s validation process to incorporate hardware validation based on a factory-provisioned certificate, as taught by Khatri, in order to ensure hardware of the system is not modified in an unauthorized manner.
The motivation is to enhance a validation process at an Information Handling System (IHS) by providing a manner to confirm hardware components within the IHS correspond to a factory-provisioned certificate. This provides the IHS with the ability to detect whether the hardware components were improperly modified during delivery to a user, and thus preventing the IHS from utilizing hardware components which may be unauthorized (Khatri, Abstract).
Savage in view of Khatri does not disclose:
… wherein the factory-provisioned firmware certificate specifies:
the factory-provisioned firmware specified for use with factory-installed hardware of the IHS; and
one or more addresses where the factor-provisioned firmware may be retrieved; and
…
based on an address of the one or more addresses specified by the factory-provisioned firmware certificate, retrieve firmware that resolves the identified firmware discrepancy; and
based on resolving the identified firmware discrepancy, continue booting of the IHS.
Stewart teaches:
… retrieve firmware that resolves the identified firmware discrepancy (Fig. 3, step 312; ¶0037, “The embedded controller 206 may recover the firmware 212 by, for instance, automatically replacing the firmware 212 with a version of the firmware 212 that is secure/trusted (e.g., has been authenticated using a firmware signature)…”; ¶0041, “In response to a determination at block 310 that the firmware update 218 associated with the firmware 212 is stored in the memory 208 of the embedded controller 206, at block 312, the processor 202 may cause the BIOS 204 to automatically replace the firmware 212 with the firmware update 218”); and
based on resolving the identified firmware discrepancy, continue booting of the IHS (¶0041, “In addition, following replacement of the firmware 212 with the firmware update 218, at block 308, the processor 202 may execute the BIOS 204 to allow the hardware component 210 to startup and/or connect to the bus 216”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Savage in view of Khatri’s firmware validation system by enhancing Savage in view of Khatri’s system to replace unsecure firmware with firmware corresponding to a validated signature, as taught by Stewart, in order to prevent unsecure firmware from operating on the system.
The motivation is to increase the security of an Information Handling System (IHS) by replacing insecure firmware of hardware components with validated firmware, thus reducing the risk of exploits and/or malicious activity which could affect the IHS (Stewart, ¶0014; ¶0015).
Savage in view of Khatri in further view of Stewart does not disclose:
… wherein the factory-provisioned firmware certificate specifies:
the factory-provisioned firmware specified for use with factory-installed hardware of the IHS; and
one or more addresses where the factor-provisioned firmware may be retrieved; and
…
based on an address of the one or more addresses specified by the factory-provisioned firmware certificate, retrieve firmware that resolves the identified firmware discrepancy; and
Pan teaches:
… wherein the factory-provisioned firmware certificate specifies (¶0004, “Currently, a manufacturer of a terminal device usually stores a MUD file on a MUD file server. Before the terminal device is delivered from a factory, the manufacturer writes, into a certificate of the terminal device, a MUD uniform resource locator (URL) that corresponds to the MUD file on the MUD file server”):
the factory-provisioned firmware specified for use with factory-installed hardware of the IHS (¶0131, “When accessing a network for the first time, the terminal device 11 sends the certificate to the MUD controller 30. After verifying the certificate successfully, the MUD controller 30 obtains the MUD URL 0 “https://www.huawei.com/mud/router/firmware_version_1234/os_version_4321.json” from the certificate”; i.e., the certificate contains at least an initial firmware version for use with the factory-provided terminal); and
one or more addresses where the factor-provisioned firmware may be retrieved (¶0131, “When accessing a network for the first time, the terminal device 11 sends the certificate to the MUD controller 30. After verifying the certificate successfully, the MUD controller 30 obtains the MUD URL 0 “https://www.huawei.com/mud/router/firmware_version_1234/os_version_4321.json” from the certificate”; i.e., the certificate comprises an initial URL on where to retrieve firmware for the factory-provided terminal); and
…
based on an address of the one or more addresses specified by the factory-provisioned firmware certificate (¶0078, “… because the certificate of the terminal device is digitally signed by the manufacturer at delivery, the MUD controller may determine, by verifying the certificate, that the certificate is valid and content in the certificate is not tampered with. In this way, it can be ensured that the MUD URL carried in the certificate is valid, and security of the manner of obtaining the MUD file is ensured to some extent”), retrieve firmware that resolves the identified firmware discrepancy (¶0080, “When the terminal device is currently updated, the terminal device sends a new second MUD URL to the MUD controller. If the second MUD URL and the trusted first MUD URL meet a matching condition, it represents that the second MUD URL is valid. Therefore, the MUD controller may obtain a new second MUD file based on the second MUD URL”; ¶0131 & ¶0132 further depicts the MUD URL, located in a certificate, to be used to update a terminal device’s firmware); and
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Savage in view of Khatri in further view of Stewart’s firmware validation system by enhancing Savage in view of Khatri in further view of Stewart’s method of updating firmware to utilize a URL address within a certificate, including a version number corresponding to the firmware, as taught by Pan, in order to retrieve validated firmware from a validated server.
The motivation is to ensure that correctly versioned firmware is retrieved in a trusted and validated manner by incorporating a URL to retrieve the firmware into a certificate, thus allowing the system to utilize the certificate to self-validate the URL (Pan, ¶0082).
Regarding Claim 2:
The IHS of claim 1, wherein Savage in view of Khatri in view of Stewart in further view of Pan further teaches booting of the IHS is halted by a remote access controller of the IHS (Savage, ¶0093, “As indicated at 572 of FIG. 5, the inventory validation process 510 may be configured to query … remote access controller 525 … in order to collect and/or identify the firmware and firmware settings of the IHS that are included in the fixed firmware profile of the IHS”; ¶0095, “In scenarios where the collected firmware information does not match the firmware information specified in the inventory certificate, at 680, the validation process may signal a validation failure, and in particular, a failure to validate the use of the fixed firmware profile specified in the inventory certificate … In response to a firmware validation failure, some embodiments may prevent any further booting of the IHS”).
Regarding Claim 3:
The IHS of claim 2, wherein Savage in view of Khatri in view of Stewart in further view of Pan further teaches the remote access controller disables hardware components that operate the firmware causing the firmware discrepancy (Stewart, ¶0013, “In some examples, the BIOS (or the embedded controller) may determine that the firmware is inauthentic in response to the firmware signature associated with the firmware being absent from the memory of the embedded controller … In some examples, the BIOS may disable the hardware component or prevent connection of the hardware component…”).
The motivation to reject claim 3 by applying Stewart to the combination of Savage and Khatri is the same motivation applied for Pan under the rejection of claim 1 above.
Regarding Claim 6:
The IHS of claim 1, wherein Savage in view of Khatri in view of Stewart in further view of Pan further teaches the factory-provisioned inventory certificate and the factory-provisioned firmware certificate are stored to a persistent memory of the IHS during factory-provisioning of the IHS (Savage, ¶0007, “IHSs (Information Handling Systems) may include: a plurality of hardware components; a persistent memory, wherein during factory provisioning of the IHS an inventory certificate is uploaded to the persistent memory…”; ¶0083, “At block 625 and as indicated at 540, the inventory certificate validation process 510 retrieves the signed inventory certificate from the remote access controller 525 or from a persistent memory of the IHS. As described above, the factory provisioning process may include uploading the signed inventory certificate to the remote access controller or to a persistent memory of the IHS and includes an inventory of the factory-installed hardware and of the factory-provisioned firmware that conforms with a fixed firmware profile of the IHS”).
Regarding Claim 10:
The IHS of claim 2, wherein Savage in view of Khatri in view of Stewart in further view of Pan teaches the remote access controller retrieve, based on a URL specified by the factory-provisioned firmware certificate, the firmware that resolves the identified firmware discrepancy (Pan, ¶0080, “When the terminal device is currently updated, the terminal device sends a new second MUD URL to the MUD controller. If the second MUD URL and the trusted first MUD URL meet a matching condition, it represents that the second MUD URL is valid. Therefore, the MUD controller may obtain a new second MUD file based on the second MUD URL”).
The motivation to reject claim 10 by applying Pan to the combination of Savage, Khatri, and Stewart is the same motivation applied for Pan under the rejection of claim 1 above.
Regarding Claims 11-14:
System claims 11-14 correspond to respective method claims 1, 10, 2, and 3, and contain no further limitations. Therefore claims 11-14 are rejected by applying the same rationale used to reject claims 1, 10, 2, and 3 above, respectively.
Regarding Claims 16-19:
Storage device claims 16-19 correspond to respective method claims 1, 10, 2, and 3, and contain no further limitations. Therefore claims 16-19 are rejected by applying the same rationale used to reject claims 1, 10, 2, and 3 above, respectively.
Claim(s) 4 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Savage” (US 2023/0130694) in view of “Khatri” (US 2023/0011005) in view of “Stewart” (US 2025/0077675) in view of “Pan” (US 2022/0417039) in further view of “Ramaiah” (US 2023/0306141).
Regarding Claim 4:
Savage in view of Khatri in view of Stewart in further view of Pan teaches:
The IHS of claim 2, …
Savage in view of Khatri in view of Stewart in further view of Pan does not disclose:
… wherein the validation process is configured to block generation of delta certificates without validation of the detected firmware based on the factory-provisioned firmware certificate.
Ramaiah teaches:
… wherein the validation process is configured to block generation of delta certificates without validation of the detected firmware based on the factory-provisioned firmware certificate (¶0014; ¶0179, “Ledger 1002 may also associate anomalies/blacklisted entries against a delta inventory certificate for a particular device”; ¶0180, “… a request for the creation of a delta inventory certificate by a given IHS may be checked against ledger 1002. If ledger 1002 indicates that a device being inserted into the given IHS has been inserted and not yet removed from another IHS, the request for delta inventory certificate creation may be denied or flagged”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Savage in view of Khatri in view of Stewart in further view of Pan’s firmware validation system by enhancing Savage in view of Khatri in view of Khatri in further view of Pan’s validation process to deny delta certificates from being created based on failed verification of a hardware component, as taught by Ramaiah, in order to ensure the hardware component is not coupled to another system.
The motivation is to prevent fraudulent components from operating within an Information Handling System (IHS) by first verifying that the hardware component is not coupled to another IHS prior to creating a respective delta certificate for that hardware component to operate.
Regarding Claim 5:
The IHS of claim 4, wherein Savage in view of Khatri in view of Stewart in view of Pan in further view of Ramaiah further teaches the generation of delta certificates is blocked by the remote access controller of the IHS (Ramaiah, ¶0171, “Such a verification policy may be received from remote validation service 906, and it may specifically apply to or exempt certain components, types of components, IHS communication ports, and/or user behaviors, from triggering delta inventory certificate generation”).
The motivation to apply Ramaiah to the combination of Savage, Khatri, Stewart, and Pan for the rejection of claim 5 is the same motivation applied in the rejection of claim 4 above.
Claim(s) 7-9, 15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Savage” (US 2023/0130694) in view of “Khatri” (US 2023/0011005) in view of “Stewart” (US 2025/0077675) in view of “Pan” (US 2022/0417039) in further view of “Edwards” (US 2022/0043914).
Regarding Claim 7:
Savage in view of Khatri in view of Stewart in further view of Pan teaches:
The IHS of claim 1, …
Savage in view of Khatri in view of Stewart in further view of Pan does not disclose:
… wherein the detected hardware is validated based on device identity certificates presented by the detected hardware.
Edwards teaches:
… wherein the detected hardware is validated based on device identity certificates presented by the detected hardware (¶0079, “Authenticating the hardware architecture may include establishing that the hardware of the components 214 is from known and trusted manufacturers. Establishing that the hardware is from known and trusted manufacturers may include validating the certificate chain of the components 214”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Savage in view of Khatri in view of Stewart in further view of Pan’s firmware validation system by enhancing Savage in view of Khatri in view of Stewart in further view of Pan’s validation process to include verifying hardware components based on their respective certificates, as taught by Edwards, in order to provide an efficient manner in verifying multiple components.
The motivation is to provide efficient validation of a plurality of hardware components by receiving a chain of certificates corresponding to the plurality of hardware components and using the certificates to provide validation results for the plurality of hardware components. This enables an Information Handling System (IHS) to provide validation for complex components in addition to simple components, thus preventing misuse of any component coupled to the IHS (Edwards, ¶0001, “Even simple components, such as fans and sensors, if compromised, can cause damage to a compute node through overheating or fire. Hence, identifying compromised components may be useful for preventing the components' misuse”).
Regarding Claim 8:
The IHS of claim 7, wherein Savage in view of Khatri in view of Stewart in view of Pan in further view of Edwards further teaches the factory-provisioned firmware certificate is validated based on the device identity certificates (Edwards, ¶0080, “At block 904, the node group manager 204 may authenticate the firmware 216 of each of the components 214 of the node group 202. Authenticating the firmware 216 may include comparing the measurements in the firmware measurement certificates 218 for the components 214…”).
The motivation to apply Edwards to the combination of Savage, Khatri, Stewart, and Pan for the rejection of claim 8 is the same motivation applied in the rejection of claim 7 above.
Regarding Claim 9:
The IHS of claim 8, wherein Savage in view of Khatri in view of Stewart in view of Pan in further view of Edwards further teaches the factory-provisioned firmware certificate cannot be successfully validated without all of the device identity certificates (Edwards, ¶0048, “At block 510, an initiator, such as the initiator 402, may authenticate the firmware measurement certificate 300 generated at block 506. The authentication may be performed as described with respect to FIG. 3. If the authentication fails, the method 500 may end”).
The motivation to apply Edwards to the combination of Savage, Khatri, Stewart, and Pan the rejection of claim 9 is the same motivation applied in the rejection of claim 7 above.
Regarding Claims 15 and 20:
Method claim 15 and storage device claim 20 each correspond to IHS claim 7, and contain no further limitations. Therefore claims 15 and 20 are each rejected by applying the same rationale used to reject claim 7 above.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B POTRATZ whose telephone number is (571)270-5329. The examiner can normally be reached on M-F 10 A.M. - 6 P.M. CST.
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, William Korzuch can be reached on 571-272-7589. 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 http://pair-direct.uspto.gov. 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.
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491
Prosecution Insights