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
Claims 1-20 are pending and being considered.
Claims 1-3, 7, 8 and 16-19 have been amended.
The new titled submitted on 07/02/2026 have been accepted.
Response to 101
The 101 is withdrawn based on applicant’s amendments.
Response to 102/103
Applicant’s arguments filed on 07/02/2026 have been fully considered and are persuasive but are moot in view of new grounds of rejection. The arguments do not apply to the current art being used.
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-13 and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Young et al (hereinafter Young) (US 20220207145) in view of Reddy et al (hereinafter Reddy) (US 20230342446).
Regarding claim 1 Young teaches a non-transitory machine-readable storage medium comprising instructions that upon execution cause a controller of a computer system to: (Young on [0006-0008] teaches computer-readable instruction stored in memory causes controller of computer);
during a startup of the computer system, perform a validation of components in a chain of trust of the computer system and a validation of a manifest certificate for the computer system (Young on [0048, 0060 and 0070] teaches in IHS embodiments that include a TPM, a pre-boot process implemented by the TPM may utilize its cryptographic capabilities to calculate hash values that are based on software and/or firmware instructions utilized by certain core components of IHS, such as the BIOS and boot loader of IHS 200. These calculated hash values may then be compared against reference hash values that were previously stored in a secure non-volatile memory of the IHS, such as during factory provisioning of IHS 200. In this manner, a TPM may establish a root of trust that includes core components of IHS 200 that are validated as operating using instructions that originate from a trusted source. See Fig 3 block 365 and text on [0067 and 0072] teaches validation of the signed inventory certificate by the remote access controller, the remote access controller decrypts the signature included by the remote access controller in the CSR and confirms that the inventory information included in the signed inventory certificate matches the inventory information that was submitted in the certificate signing request, thus validating the integrity of the generation of the signed inventory certificate);
based on the validations of the components and the manifest certificate, obtain information of a hardware or program component of the computer system; include the information of the hardware or program component in an update manifest certificate (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. i.e., include obtained information in the updated certificate);
obtain a signed version of the update manifest certificate containing the information of the hardware or program component (Young on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. The updated inventory certificate may be re-signed);
and store the signed version of the update manifest certificate in a storage repository for establishing a trustworthiness of the computer system (Young on [0091] teaches the updated inventory certificate includes an updated inventory, the inventory certificate is still cryptographically bound to the root of trust of the HIS. See on [0099] teaches this inventory certificate updated with user-authorized components may be used in future hardware validations by the validation process. See on [0050 and 0081] teaches storing the signed certificate).
Although Young teaches certificate containing identity information of TPM, but fails to explicitly teach add, to the update manifest certificate, information of an endorsement key (EK) bound to a security processor of the computer system, the EK being a cryptographic anchor of the computer system and providing an indication that the update manifest certificate is bound to the security processor;
obtain a signed version of the update manifest certificate containing the information of the hardware or program component and the information of the EK, however Reddy from analogous art teaches
add, to the update manifest certificate, information of an endorsement key (EK) bound to a security processor of the computer system, the EK being a cryptographic anchor of the computer system and providing an indication that the update manifest certificate is bound to the security processor;
obtain a signed version of the update manifest certificate containing the information of the hardware or program component and the information of the EK (Reddy on [0011, 0030 and 0064-0065] teaches the information of a platform certificate, which binds the platform certificate to a specific security processor may be in the form of a reference to a digital certificate called an “endorsement key certificate” or “EK certificate,” herein. The EK certificate may contain data that represents identifying attributes of a specific security processor, such as attributes representing a manufacturer of the security processor, a model of the security processor, a version of the security processor, a serial number of the security processor, a unique identifier of the security processor. Further teaches Verifying the platform certificate includes the management controller determining whether a signature of the platform certificate is valid. The platform certificate includes data representing an endorsement key certificate reference and data representing a reference inventory for the machine. Verifying the platform certificate includes the management controller determining whether a signature of an endorsement key certificate is valid. The endorsement key certificate corresponds to a trusted platform module (TPM) that has an access restricted to the management controller. Verifying the platform certificate includes the management controller, responsive to determining that the signature of the platform certificate is valid and determining that the signature of the endorsement key certificate is valid, determining whether endorsement key certificate reference corresponds to the endorsement key certificate).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Reddy into the teaching of Young by having certificate containing endorsement key bound to the security processor. One would be motivated to do so in order to identify attributes of specific security processor and authenticate the security processor based on endorsement key (Reddy [0011-0014]).
Regarding claim 2 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the information of the hardware or program component included in the update manifest certificate comprises information of plural hardware or program components (Young on [0006] teaches information regarding plurality of hardware components).
Regarding claim 3 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the information of the hardware or program component included in the update manifest certificate includes information of an updated hardware or program component as updated by a system update enterprise after the computer system left a facility of a source of the computer system (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches Upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component).
Regarding claim 4 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the controller comprises a hardware root of trust to initiate the validation of the components in the chain of trust (Young on [0048-0049 and 0052] teaches a TPM may establish a root of trust that includes core components of IHS 200 that are validated as operating using instructions that originate from a trusted source).
Regarding claim 5 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the components in the chain of trust comprises a component inventory module of system firmware of the computer system, and wherein the component inventory module after validation is to collect the information of the hardware or program component to include in the update manifest certificate (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches Upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component).
Regarding claim 6 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the components in the chain of trust comprise machine-readable instructions of the controller (Young on [0006] teaches wherein the plurality of hardware components comprise: one or more processors; and one or more memory devices coupled to the processors, the memory devices storing computer-readable instructions).
Regarding claim 7 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the update manifest certificate comprises a reference to the manifest certificate created by a source of the computer system, the manifest certificate including information of components of the computer system as shipped by the source, the reference providing a linkage between the update manifest certificate and the manifest certificate (Young on [0065-0067, 0081-0083 and 0091-0092] teaches the copy may be saved to a data store utilized in providing ongoing support of the IHS once the IHS has been shipped and has been deployed by a customer. As described below with regard to FIG. 7, using this stored copy of the signed inventory certificate, a trusted entity providing ongoing support of IHS may validate that an inventory of installed hardware reported by the IHS matches the factory installed hardware of the IHS. In addition, the trusted entity may utilize the stored inventory certificate to provide the IHS with a new or updated inventory certificate that reflects replacement and/or new hardware that was supplied for installation in the IHS. Using the inventory certificate that includes updated inventory information, an administrator may confirm that a hardware update corresponds to a genuine component that was supplied by the trusted entity).
Regarding claim 8 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the EK is unique to the security processor (Reddy on [0011-0012] teaches the information of a platform certificate, which binds the platform certificate to a specific security processor may be in the form of a reference to a digital certificate called an “endorsement key certificate” or “EK certificate,” herein. The EK certificate may contain data that represents identifying attributes of a specific security processor, such as attributes representing a manufacturer of the security processor, a model of the security processor, a version of the security processor, a serial number of the security processor, a unique identifier of the security processor. The private part (called the “private EK” herein) of the EK is stored inside the security processor, is unique to that security processor).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Reddy into the teaching of Young by having certificate containing endorsement key bound to the security processor. One would be motivated to do so in order to identify attributes of specific security processor and authenticate the security processor based on endorsement key (Reddy [0011-0014]).
Regarding claim 9 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the instructions upon execution cause the controller to: halt a boot process of the computer system based on a determination that the information of the hardware or program component is available (Young on [0090 and 0097] teaches booting of the IHS maybe halted and the user of the IHS may be notified of the non-validated hardware component, such that the user may be prompted to proceed while utilizing a non-validated component or to disable the component until it can be validated as a genuine components that was supplied by a trusted entity).
Regarding claim 10 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the instructions upon execution cause the controller to: validate the hardware or program component, wherein the obtaining of the information of the hardware or program component is responsive to validating the hardware or program component (Young on [0097] teaches the validation process 815 compares the detected hardware components of the IHS against the hardware inventory provided within the inventory certificate maintained by the IHS. Based on this comparison, at 855, discrepancies between the detected hardware and the genuine hardware from the inventory certificate are identified. As indicated in FIG. 8, a notification of any such discrepancies is provided to the user 805. Also as indicated in FIG. 8, the validation process 815 may halt further booting of the IHS in response to the detected discrepancies and in particular may prevent booting of the operating system of the IHS. In some embodiments, the validation process 815 may be implemented via operations of a remote access controller that may operate while collecting data from managed components via out-of-band connections such that all or some of the managed components may remain in low power states while further booting is being halted. The validation process 815 may determine whether to halt further booting of the IHS based on the user's 805 boot configuration settings that were retrieved at 835).
Regarding claim 11 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the instructions upon execution cause the controller to: sign, using a private key, the update manifest certificate to obtain the signed version of the update manifest certificate (Young on [0052 and 0062-0064] teaches private key for signing certificate information).
Regarding claim 12 the combination of Young and Reddy teaches all the limitations of claim 11 above, Young further teaches wherein the instructions upon execution cause the controller to: generate a key pair comprising the private key and a public key corresponding to the private key (Young on [0061-0064] teaches private key of public-private key pair for signing certificate information).
Regarding claim 13 the combination of Young and Reddy teaches all the limitations of claim 1 above, Young further teaches wherein the instructions upon execution cause the controller to: send, in a secure communication session, the update manifest certificate to a management system to sign the update manifest certificate; and receive, in the secure communication session, the signed version of the update manifest certificate from the management system (Young on [0091] teaches retrieving the certificate, signing the update certificate and transmitting the signed certificate).
Regarding claim 16 Young teaches a computer system comprising: (Young on [0019] teaches computer system);
a security processor (Young on [0038-0039] teaches security processor);
a management controller comprising a hardware processor, the management controller to: during a startup of the computer system, perform a validation of components in a chain of trust of the computer system, and a validation of a manifest certificate for the computer system (Young on [0048, 0060 and 0070] teaches in IHS embodiments that include a TPM, a pre-boot process implemented by the TPM may utilize its cryptographic capabilities to calculate hash values that are based on software and/or firmware instructions utilized by certain core components of IHS, such as the BIOS and boot loader of IHS 200. These calculated hash values may then be compared against reference hash values that were previously stored in a secure non-volatile memory of the IHS, such as during factory provisioning of IHS 200. In this manner, a TPM may establish a root of trust that includes core components of IHS 200 that are validated as operating using instructions that originate from a trusted source. See Fig 3 block 365 and text on [0067 and 0072] teaches validation of the signed inventory certificate by the remote access controller, the remote access controller decrypts the signature included by the remote access controller in the CSR and confirms that the inventory information included in the signed inventory certificate matches the inventory information that was submitted in the certificate signing request, thus validating the integrity of the generation of the signed inventory certificate);
based on the validations of the components and the manifest certificate, obtain information of a hardware or program component of the computer system (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. i.e., include obtained information in the updated certificate);
the hardware or program component updated by a system update enterprise different from a source of the computer system (Young on [0019-0024] teaches hardware configuration may result from chassis 100 being factory assembled to include components specified by a customer that has contracted for manufacture and delivery of chassis 100. Upon delivery and deployment of an IHS, an IHS may be modified by replacing various hardware components of the IHS or by installing new hardware components to the IHS. As described in additional detail below, chassis 100 may include capabilities that allow a user to delay booting of an IHS installed in chassis 100 until validating that the detected hardware components of chassis 100 are either factory installed hardware components or are hardware components supplied for installation in the chassis 100 by a trusted entity. i.e., software of hardware updated by customer or trusted entity different from manufacturer as source of the computer system);
include the information of the hardware or program component in an update manifest certificate (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. i.e., include obtained information in the updated certificate);
obtain a signed version of the update manifest certificate containing the information of the hardware or program component (Young on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. The updated inventory certificate may be re-signed);
and store the signed version of the update manifest certificate in a storage repository for establishing a trustworthiness of the computer system (Young on [0091] teaches the updated inventory certificate includes an updated inventory, the inventory certificate is still cryptographically bound to the root of trust of the HIS. See on [0099] teaches this inventory certificate updated with user-authorized components may be used in future hardware validations by the validation process. See on [0050 and 0081] teaches storing the signed certificate).
Although Young teaches certificate containing identity information of TPM, but fails to explicitly teach add, to the update manifest certificate, information of an endorsement key (EK) bound to a security processor of the computer system, the EK being a cryptographic anchor of the computer system and providing an indication that the update manifest certificate is bound to the security processor;
obtain a signed version of the update manifest certificate containing the information of the hardware or program component and the information of the EK, however Reddy from analogous art teaches
add, to the update manifest certificate, information of an endorsement key (EK) bound to a security processor of the computer system, the EK being a cryptographic anchor of the computer system and providing an indication that the update manifest certificate is bound to the security processor;
obtain a signed version of the update manifest certificate containing the information of the hardware or program component and the information of the EK (Reddy on [0011, 0030 and 0064-0065] teaches the information of a platform certificate, which binds the platform certificate to a specific security processor may be in the form of a reference to a digital certificate called an “endorsement key certificate” or “EK certificate,” herein. The EK certificate may contain data that represents identifying attributes of a specific security processor, such as attributes representing a manufacturer of the security processor, a model of the security processor, a version of the security processor, a serial number of the security processor, a unique identifier of the security processor. Further teaches Verifying the platform certificate includes the management controller determining whether a signature of the platform certificate is valid. The platform certificate includes data representing an endorsement key certificate reference and data representing a reference inventory for the machine. Verifying the platform certificate includes the management controller determining whether a signature of an endorsement key certificate is valid. The endorsement key certificate corresponds to a trusted platform module (TPM) that has an access restricted to the management controller. Verifying the platform certificate includes the management controller, responsive to determining that the signature of the platform certificate is valid and determining that the signature of the endorsement key certificate is valid, determining whether endorsement key certificate reference corresponds to the endorsement key certificate).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Reddy into the teaching of Young by having certificate containing endorsement key bound to the security processor. One would be motivated to do so in order to identify attributes of specific security processor and authenticate the security processor based on endorsement key (Reddy [0011-0014]).
Regarding claim 17 the combination of Young and Reddy teaches all the limitations of claim 16 above, Young further teaches wherein the update manifest certificate comprises a reference to the manifest certificate created by a source of the computer system, the manifest certificate including information of components of the computer system as shipped by the source, the reference providing a linkage between the update manifest certificate and the manifest certificate (Young on [0065-0067, 0081-0083 and 0091-0092] teaches the copy may be saved to a data store utilized in providing ongoing support of the IHS once the IHS has been shipped and has been deployed by a customer. As described below with regard to FIG. 7, using this stored copy of the signed inventory certificate, a trusted entity providing ongoing support of IHS may validate that an inventory of installed hardware reported by the IHS matches the factory installed hardware of the IHS. In addition, the trusted entity may utilize the stored inventory certificate to provide the IHS with a new or updated inventory certificate that reflects replacement and/or new hardware that was supplied for installation in the IHS. Using the inventory certificate that includes updated inventory information, an administrator may confirm that a hardware update corresponds to a genuine component that was supplied by the trusted entity).
Regarding claim 18 the combination of Young and Reddy teaches all the limitations of claim 16 above, Young further teaches wherein the EK is unique to the security processor (Reddy on [0011-0012] teaches the information of a platform certificate, which binds the platform certificate to a specific security processor may be in the form of a reference to a digital certificate called an “endorsement key certificate” or “EK certificate,” herein. The EK certificate may contain data that represents identifying attributes of a specific security processor, such as attributes representing a manufacturer of the security processor, a model of the security processor, a version of the security processor, a serial number of the security processor, a unique identifier of the security processor. The private part (called the “private EK” herein) of the EK is stored inside the security processor, is unique to that security processor).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Reddy into the teaching of Young by having certificate containing endorsement key bound to the security processor. One would be motivated to do so in order to identify attributes of specific security processor and authenticate the security processor based on endorsement key (Reddy [0011-0014]).
Regarding claim 19 Young teaches a method comprising: (Young on [0004] teaches methods for validating secure assembly and delivery of an IHS);
receiving, at a management controller of a computer system, a request to generate an update manifest certificate to include information of an updated hardware or program component (Young on [0061-0065] teaches the generation of an inventory certificate for a newly assembled IHS, at 325, may be initiated via a request from the factory provisioning application 305 to the remote access controller 310 of the HIS and to provide the IHS with a new or updated inventory certificate that reflects replacement and/or new hardware that was supplied for installation in the IHS. Using the inventory certificate that includes updated inventory information, an administrator may confirm that a hardware update corresponds to a genuine component that was supplied by the trusted entity. See on [0050] teaches the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components installed by a customer are the same hardware components that were supplied to the customer. See on [0091-0092] teaches upon receipt of the updated inventory certificate, at block 770, the IHS may initiate a validation process, such as described above, in order to compare the detected hardware inventory of the IHS against the inventory reported in the updated inventory certificate. If the detected hardware inventory of the IHS matches the inventory reported in the updated inventory certificate, the customer may be assured that the installed hardware component is a genuine component that was supplied by a trusted entity and further booting of the IHS may be resumed. However, if the new or replacement hardware component installed in the IHS is not identified in the inventory of the updated inventory certificate, the validation process may notify the user that the IHS may be operating with a compromised component that was not supplied by a trusted entity);
based on the request, validating, by the management controller, components in a chain of trust of the computer system, and validating a base manifest certificate for the computer system (Young on [0048, 0060 and 0070] teaches in IHS embodiments that include a TPM, a pre-boot process implemented by the TPM may utilize its cryptographic capabilities to calculate hash values that are based on software and/or firmware instructions utilized by certain core components of IHS, such as the BIOS and boot loader of IHS 200. These calculated hash values may then be compared against reference hash values that were previously stored in a secure non-volatile memory of the IHS, such as during factory provisioning of IHS 200. In this manner, a TPM may establish a root of trust that includes core components of IHS 200 that are validated as operating using instructions that originate from a trusted source. See Fig 3 block 365 and text on [0067 and 0072] teaches validation of the signed inventory certificate by the remote access controller, the remote access controller decrypts the signature included by the remote access controller in the CSR and confirms that the inventory information included in the signed inventory certificate matches the inventory information that was submitted in the certificate signing request, thus validating the integrity of the generation of the signed inventory certificate);
based on the validations of the components and the base manifest certificate, obtaining, by the management controller, information of the hardware or program component (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. i.e., include obtained information in the updated certificate);
including, by the management controller, the information of the hardware or program component in the update manifest certificate (Young on [0050] teaches a customer may validate that the detected hardware components of IHS 200 are the same hardware components that were installed at the factory during manufacture of IHS 200. Also as described below, in response to replacement of one or more hardware components of IHS 200 or to the addition of new hardware components to IHS 200, the remote access controller 255 may be configured to receive a new signed inventory certificate or an updated signed inventory certificate that may be used to validate that the hardware components. See on [0063 and 0065] teaches inventory certificate may be updated or replaced in response to replacement of one or more hardware components of the IHS, or in response to additional hardware components being installed in the IHS. See on [0087] teaches the validation service proceeds to generate a new signed inventory certificate that specifies the updated hardware inventory that was reported in the CSR. In some embodiments, the new signed inventory certificate that is generated by the validation service may be signed by a factory certificate authority that utilizes a hardware security module. See on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. i.e., include obtained information in the updated certificate);
obtaining a signed version of the update manifest certificate containing the information of the hardware or program component (Young on [0091] teaches upon a new/replacement hardware component being supplied for installation in an IHS, at block 780, a remote validation service retrieves the signed inventory certificate stored, at block 715, during factory provisioning of the IHS. At block 785, the validation service updates the inventory certificate of the IHS to include the identity of the supplied hardware component. The updated inventory certificate may be re-signed);
and storing, by the management controller, the signed version of the update manifest certificate in a storage repository for establishing a trustworthiness of the computer system (Young on [0091] teaches the updated inventory certificate includes an updated inventory, the inventory certificate is still cryptographically bound to the root of trust of the HIS. See on [0099] teaches this inventory certificate updated with user-authorized components may be used in future hardware validations by the validation process. See on [0050 and 0081] teaches storing the signed certificate).
Although Young teaches certificate containing identity information of TPM, but fails to explicitly teach adding, to the update manifest certificate, information of an endorsement key (EK) bound to a security processor of the computer system, the EK being a cryptographic anchor of the computer system and providing an indication that the update manifest certificate is bound to the security processor;
obtaining a signed version of the update manifest certificate containing the information of the hardware or program component and the information of the EK, however Reddy from analogous art teaches
adding, to the update manifest certificate, information of an endorsement key (EK) bound to a security processor of the computer system, the EK being a cryptographic anchor of the computer system and providing an indication that the update manifest certificate is bound to the security processor;
obtaining a signed version of the update manifest certificate containing the information of the hardware or program component and the information of the EK (Reddy on [0011, 0030 and 0064-0065] teaches the information of a platform certificate, which binds the platform certificate to a specific security processor may be in the form of a reference to a digital certificate called an “endorsement key certificate” or “EK certificate,” herein. The EK certificate may contain data that represents identifying attributes of a specific security processor, such as attributes representing a manufacturer of the security processor, a model of the security processor, a version of the security processor, a serial number of the security processor, a unique identifier of the security processor. Further teaches Verifying the platform certificate includes the management controller determining whether a signature of the platform certificate is valid. The platform certificate includes data representing an endorsement key certificate reference and data representing a reference inventory for the machine. Verifying the platform certificate includes the management controller determining whether a signature of an endorsement key certificate is valid. The endorsement key certificate corresponds to a trusted platform module (TPM) that has an access restricted to the management controller. Verifying the platform certificate includes the management controller, responsive to determining that the signature of the platform certificate is valid and determining that the signature of the endorsement key certificate is valid, determining whether endorsement key certificate reference corresponds to the endorsement key certificate).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Reddy into the teaching of Young by having certificate containing endorsement key bound to the security processor. One would be motivated to do so in order to identify attributes of specific security processor and authenticate the security processor based on endorsement key (Reddy [0011-0014]).
Claims 14-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Young et al (hereinafter Young) (US 20220207145) in view of Reddy et al (hereinafter Reddy) (US 20230342446) and further in view of Kwon et al (hereinafter Kwon) (US 20260032003).
Regarding claim 14 the combination of Young and Reddy teaches all the limitations of claim 1 above, the combination fails to explicitly teach wherein the update manifest certificate comprises a delta platform certificate, however Kwon from analogous art teaches wherein the update manifest certificate comprises a delta platform certificate (Kwon on [0027] teaches a “platform certificate” may be categorized as “base,” “delta,” or “rebase.” Specifically, a “base platform certificate” may be independent and comprehensive, containing all the assertions made by its issuer for a particular platform without referencing any other platform certificate. A “delta platform certificate” may cover specific changes to the platform that are not covered by the existing certificate and must reference a previously issued base or delta platform certificate to provide a complete set of assertions. A “rebase platform certificate,” like a base platform certificate, may be self-contained and include all the issuer's assertions. However, it may also reference a prior platform certificate (base or delta) to ensure transparency regarding the platform's previous modifications).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kwon into the combined teaching of Young and Reddy by having certificate as delta and rebase certificate. One would be motivated to do so in order to tracks changes to the platform which are not covered by existing certificates and validate components of hardware using delta and rebase certificates (Kwon [0027]).
Regarding claim 15 the combination of Young and Reddy teaches all the limitations of claim 1 above, the combination fails to explicitly teach wherein the update manifest certificate comprises a rebase platform certificate, however Kwon from analogous art teaches wherein the update manifest certificate comprises a rebase platform certificate (Kwon on [0027] teaches a “platform certificate” may be categorized as “base,” “delta,” or “rebase.” Specifically, a “base platform certificate” may be independent and comprehensive, containing all the assertions made by its issuer for a particular platform without referencing any other platform certificate. A “delta platform certificate” may cover specific changes to the platform that are not covered by the existing certificate and must reference a previously issued base or delta platform certificate to provide a complete set of assertions. A “rebase platform certificate,” like a base platform certificate, may be self-contained and include all the issuer's assertions. However, it may also reference a prior platform certificate (base or delta) to ensure transparency regarding the platform's previous modifications).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kwon into the combined teaching of Young and Reddy by having certificate as delta and rebase certificate. One would be motivated to do so in order to tracks changes to the platform which are not covered by existing certificates and validate components of hardware using delta and rebase certificates (Kwon [0027]).
Regarding claim 20 the combination of Young and Reddy teaches all the limitations of claim 19 above, the combination fails to explicitly teach wherein the update manifest certificate comprises a delta platform certificate or a rebase platform certificate, however Kwon from analogous art teaches wherein the update manifest certificate comprises a delta platform certificate or a rebase platform certificate (Kwon on [0027] teaches a “platform certificate” may be categorized as “base,” “delta,” or “rebase.” Specifically, a “base platform certificate” may be independent and comprehensive, containing all the assertions made by its issuer for a particular platform without referencing any other platform certificate. A “delta platform certificate” may cover specific changes to the platform that are not covered by the existing certificate and must reference a previously issued base or delta platform certificate to provide a complete set of assertions. A “rebase platform certificate,” like a base platform certificate, may be self-contained and include all the issuer's assertions. However, it may also reference a prior platform certificate (base or delta) to ensure transparency regarding the platform's previous modifications).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kwon into the combined teaching of Young and Reddy by having certificate as delta and rebase certificate. One would be motivated to do so in order to tracks changes to the platform which are not covered by existing certificates and validate components of hardware using delta and rebase certificates (Kwon [0027]).
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 MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436
Prosecution Insights