DETAILED ACTION
Response to Amendment
Applicant’s amendment, filed 02/05/26, for application number 18/544,999 has been received and entered into record. Claims 1, 9, and 18 have been amended. Therefore, Claims 1-20 are presented for examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 9 is objected to because of the following informalities:
Claim 9, line 5 recites, “accessing, buy by the operating system executing on the device,” (emphasis added) and should instead read, “accessing, by the operating system executing on the device,” to correct the typographical error. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 6, 7, 9-11, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Jacquin et al., US 2021/0073003 A1, in view of Tahan, US 2009/0150899 A1, and further in view of Dasari et al., US 2010/0125731 A1.
Regarding Claim 1, Jacquin discloses a network device [device 100, which can be a switch, a router, server, etc., Fig. 1; par 26], comprising:
a processor [processing element 120],
a Trusted Platform Module (TPM) including a plurality of Platform Configuration Registers (PCRs) [TPM is a security co-processor 110; PCRs reside inside a security component such as a security co-processor or trusted platform module, par 22, line 1; par 17];
a non-transitory computer readable medium, comprising instructions for an operating system adapted to execute on the processor [device 100 includes one or more firmware engine. A firmware engine can be implemented using instructions executable by a processor and/or logic. In some examples, the firmware engine can be implemented as platform firmware. Platform firmware may include an interface such as a basic input/output system (BIOS) or unified extensible firmware interface (UEFI) to allow it to be interfaced with. The platform firmware can be located at an address space where the processing element 120 (e.g., CPU) for the device 100 boots; the platform firmware may represent the operating system of the device 100; the processing element 120 can be configured to execute instructions stored on a memory device 130, par 28, ll. 1-10; 15-17; par 36], wherein the operating system is adapted to provide a TPM interface for receiving a request for TPM data and specifying one or more PCRs, and wherein, in response to receiving the request [a processing element or bus device performing the actions described can have a bus to communicate with the security co-processor 110 (i.e. the processor interacts with TPM through an interface, par 36], the operating system is adapted to:
access the TPM at the network device to obtain a TPM quote from the TPM;
process the TPM quote to determine a value for each of the one or more specified PCRs; and
return a response to the request though the TPM interface wherein the response comprises TPM data including an identification of each the one or more specified PCRs and the value corresponding to each of the one or more specified PCRs [the verifier initiates the challenge of the platform by providing an attestation request to the platform, and a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18].
However, Jacquin does not explicitly teach the operating system executing on the processor of the network device; processing the TPM quote to extra a value for each of the one or more PCRs specified in the request from the TPM quote; and identifying the specified PCRs and the value correspond to each of the PCRs extracted from the TPM quote.
In the analogous art of secure booting, Tahan teaches the operating system executing on the processor of the network device [embodiments of the present invention may be practiced with various computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like, par 49]; processing the TPM quote to extra a value for each of the one or more PCRs specified in the request from the TPM quote [in 602, the trust-determinant component sends an attestation reply to the trust-dependent component, returning the requested PCRs and relevant measurement log entries, par 34]; and identifying the specified PCRs in the received request and the extracted value correspond to each of the PCRs extracted from the TPM quote [In 801, a trust-dependent component's TPM receives a command for an operation that requires one or more PCRs, where some of the required PCRs are trust-dependent on PCRs in a trust-determinant component's TPM to process. Such commands include an attestation request, seal request, or unseal request. Then, in 802, the PCR resolution process is started for each required PCR that is trust-dependent on PCRs in the trust-determinant component's TPM. For each such required PCR, the values in the PCRs in the trust-determinant component's TPM on which the required PCR is trust-dependent are retrieved over a secure communications path between the trust-determinant TPM and the trust-dependent TPM, Fig. 7, 8; par 37].
It would have been obvious to one of ordinary skill in the art, having the teachings of Jacquin and Tahan before him before the effective filing date of the claimed invention, to incorporate extracting values for each of the PCRs specified in the TPM quote to accurately define and resolve trust dependencies in TPM operations [Tahan, par 7].
However, while Jacquin discloses returning a response to the request though the TPM interface of the operating system executing on the network device [the verifier initiates the challenge of the platform by providing an attestation request to the platform, and a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18], the combination of Jacquin and Tahan do not explicitly teach accessing, by the operating system executing on the network device, the TPM at the network device to obtain a TPM quote from the TPM at the operating system; process, by the operating system on the network device, the TPM quote obtained by the operating system from the TPM to extract a value; and return, by the operating system executing on the network device a response.
In the analogous art of utilizing trusted platform modules for system security, Dasari teaches accessing, by the operating system executing on the network device, the TPM at the network device to obtain a TPM quote from the TPM at the operating system; process, by the operating system on the network device, the TPM quote obtained by the operating system from the TPM to extract a value [after a successful merge, applications 34 and/or operating system 36 may access the TPM 24. Optionally, the operating system may utilize the TPM device drivers 37. The operating system, obtains information about TPM status using the advanced configuration and power interface (ACPI) 39, as necessary. For example, the operating system and/or applications may use ACPI to obtain information about the TPM device, such as TPM address and TPM status; that is, the operating system is accessing the TPM and obtaining information about the TPM status (extracting value of TPM), par 32]. While Dasari does not explicitly teach the step of returning, by the operating system executing on the network device, a response to the request through the TPM interface, Dasari teaches the operating system directly interacting with the TPM [after a successful merge, applications 34 and/or operating system 36 may access the TPM 24, par 32], and thus would be reasonable to combine with a disclosure such as that of Jacquin in performing a similar task of returning a response.
It would have been obvious to one of ordinary skill in the art, having the teachings of Jacquin, Tahan, and Dasari before him before the effective filing date of the claimed invention, to incorporate system resource and control, including TPM management, to the operating system as taught by Dasari, into the device as disclosed by Jacquin and Tahan, to allow for simplified management of a single merged node that maintains the trust intended for individual nodes having a single trusted platform module [Dasari, par 46].
Regarding Claim 6, Jacquin, Tahan, and Dasari disclose the network device of Claim 1. Jacquin further discloses wherein the TPM data includes a version of TPM implemented on the network device [a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18].
Regarding Claim 7, Jacquin, Tahan, and Dasari disclose the network device of Claim 1. Jacquin further discloses wherein the TPM data includes data from the obtained TPM quote [a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18].
Regarding Claim 9, Jacquin discloses a method [using device 100, Fig. 1]. The remainder of Claim 9 repeats the same limitations as recited in Claim 1, and is rejected accordingly.
Regarding Claim 10, Jacquin, Tahan, and Dasari disclose the method of Claim 9. Jacquin further discloses receiving a measured boot status command through the interface; and returning an enablement status through the interface in response to the measured boot status command [request instructions 230 requesting platform integrity measurement from device 100 at step 420, which requests proof from secure co-processor (i.e. TPM) at step 422, and proceeds through steps 426, 428, and 430 to provide enablement, Fig. 4].
Regarding Claim 11, Jacquin, Tahan, and Dasari disclose the method of Claim 10. Jacquin further discloses retrieving the enablement status from a configuration store residing in the TPM [Requesting secure integrity proof from secure co-processor (i.e. TPM) at step 422, and signing integrity measurement proof using DevID key at step 424; DevID is stored in the security co-processor (TPM), Fig. 4; par 58, ll. 7-8].
Regarding Claim 15, Jacquin, Tahan, and Dasari disclose the method of Claim 9. Jacquin further discloses wherein the TPM data includes a version of TPM implemented in association with the TPM [a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18].
Regarding Claim 16, Jacquin, Tahan, and Dasari disclose the method of Claim 9. Jacquin further discloses wherein the TPM data includes TPM quote data from the TPM quote [a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18].
Regarding Claim 17, Jacquin, Tahan, and Dasari disclose the method of Claim 9. Jacquin further discloses wherein the TPM data includes key data associated with the TPM of the device [a security component of the platform responds to the attestation request with an authenticated digest of the measurement hashes. In this context, an “authenticated digest” refers to a set of measurements of the platform, which are signed by a security component of the platform. A TPM quote (also called a “FOR quote” herein), containing PCR values, is an example of an authenticated digest, par 18].
Regarding Claim 18, Jacquin discloses a non-transitory computer readable medium [memory device 130, Fig. 1]. The remainder of Claim 18 repeats the same limitations as recited in Claim 1, and is rejected accordingly.
Regarding Claim 19, Jacquin, Tahan, and Dasari disclose the non-transitory computer readable medium of claim 18. Jacquin further discloses wherein the TPM interface is adapted to allow specification of a nonce and the TPM quote is obtained based on the specified nonce [the attestation request can contain a nonce; the authenticated digest that is provided by the secure component of the platform contains the nonce from the attestation request (to verify that the authenticated digest was generated after the attestation request containing the nonce) and the measurement hashes (e.g., the platform's PCR content), par 19].
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Jacquin, Tahan, and Dasari, and further in view of Martinez et al., US 2017/0010875 A1.
Regarding Claim 2, Jacquin, Tahan, and Dasari disclose the network device of Claim 1. However, the combination of references does not explicitly teach wherein the TPM interface is a command line interface and the request is a tpm pcr command.
In the analogous art of boot integrity, Martinez teaches wherein the TPM interface is a command line interface and the request is a tpm pcr command [a user can execute a verification program or a command-line command that extracts PCR0 measurement 220 from executable 200 and, optionally, compares the extracted PCR0 value with the value generated by TPM 120 that is stored at PCR 122, par 23].
It would have been obvious to one of ordinary skill in the art, having the teachings of Jacquin, Tahan, Dasari, and Martinez before him before the effective filing date of the claimed invention, to incorporate the command line interface as taught by Martinez, into the device as disclosed by Jacquin, Tahan, and Dasari, to allow for user input and provide boot integrity across various types of information handling systems [Martinez, par 2].
Claims 3, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jacquin, Tahan, Dasari, and Martinez, and further in view of Thoresen et al., US 2020/0301764 A1.
Regarding Claim 3, Jacquin, Tahan, Dasari, and Martinez disclose the network device of Claim 2. However, the combination of references does not explicitly teach wherein the TPM data is returned in a human readable format.
In the analogous art of operating system and computer resource management, Thoresen teaches wherein the data is returned in a human readable format [translating configuration values into human-readable configuration files, par 72].
It would have been obvious to one of ordinary skill in the art, having the teachings of Jacquin, Tahan, Dasari, Martinez, and Thoresen before him before the effective filing date of the claimed invention, to incorporate the human-readable files as taught by Thoresen, into the device as disclosed by Jacquin, Tahan, Dasari, and Martinez, to improve ease of the user.
Regarding Claim 14, Jacquin, Tahan, and Dasari disclose the method of Claim 9. Claim 14 repeats the same limitations as presented in Claims 3 as one of the alternative limitations, and is rejected accordingly.
Regarding Claim 20, Jacquin, Tahan, and Dasari disclose the non-transitory computer readable medium of Claim 18. Claim 20 repeats the same limitations as presented in Claims 3 as one of the alternative limitations, and is rejected accordingly.
Claims 4, 5, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Jacquin, Tahan, and Dasari.
Regarding Claim 4, Jacquin, Tahan, and Dasari disclose the network device of Claim 1. However, the combination of references does not explicitly teach wherein the TPM interface is an Application Programming Interface (API).
Examiner notes, however, devices which operate “on basically the same principle and in the same manner” where the differences, in addition to being well-known, “solve no stated problem and would be an obvious matter of design choice within the skill of the art” are obvious variations of one another and thus not patentably distinct. See In re Kuhle, 188 USPQ 7 (CCPA 1975). As such, the TPM interface being an API appears to simply be a design choice, and performs the same interface function regardless.
Regarding Claim 5, Jacquin, Tahan, and Dasari disclose the network device of Claim 4. However, the combination of references does not explicitly teach wherein the TPM data is in a machine readable format.
Examiner notes, however, devices which operate “on basically the same principle and in the same manner” where the differences, in addition to being well-known, “solve no stated problem and would be an obvious matter of design choice within the skill of the art” are obvious variations of one another and thus not patentably distinct. See In re Kuhle, 188 USPQ 7 (CCPA 1975). As such, the format of the instructions appears to simply be a design choice, and is capable of being executed regardless.
Regarding Claim 12, Jacquin, Tahan, and Dasari disclose the method of Claim 11. However, the combination of references does not explicitly teach wherein the configuration store is in reserved memory on the TPM.
Examiner notes, however, devices which operate “on basically the same principle and in the same manner” where the differences, in addition to being well-known, “solve no stated problem and would be an obvious matter of design choice within the skill of the art” are obvious variations of one another and thus not patentably distinct. See In re Kuhle, 188 USPQ 7 (CCPA 1975). As such, the storage location of the configuration appears to simply be a design choice, and performs the same function regardless.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Jacquin, Tahan, and Dasari, and further in view of Narayanan et al., US 2017/0075699 A1.
Regarding Claim 8, Jacquin, Tahan, and Dasari disclose the network device of Claim 1. However, the combination of references does not explicitly teach wherein the TPM data includes AIK certificate data associated with the TPM of the network device.
In the analogous art of hardware authentication, Narayanan teaches TPM data includes AIK certificate data associated with the TPM of the network device [the trusted platform module 306 may include an encrypted trusted platform module certificate 611 (“AIK certificate (OEM private key {TPM public key})”) that may be generated at the instruction of the OEM and utilized to verify that the trusted platform module 306 is authentic, par 33, ll. 20-25].
It would have been obvious to one of ordinary skill in the art, having the teachings of Jacquin, Tahan, Dasari, and Narayanan before him before the effective filing date of the claimed invention, to incorporate the AIK certificate data as taught by Narayanan, into the device as disclosed by Jacquin, Tahan, and Dasari, to provide an additional method of authentication to ensure safe system operation [Narayanan, par 3].
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Jacquin, Tahan, and Dasari, and further in view of Amundsen et al., US 2022/0342657 A1.
Regarding Claim 13, Jacquin, Tahan, and Dasari disclose the method of Claim 12. However, the combination of references does not explicitly teach wherein reserved memory is writable only from a bootloader and is readable from an operating system of the device.
In the analogous art of secure booting, Amundsen teaches wherein reserved memory is writable only from a bootloader and is readable from an operating system of the device [a bootloader is typically installed in a region of memory to which access is restricted (e.g. write-restricted), so that the bootloader itself cannot be accidentally or maliciously modified or overwritten; the microcontroller may comprise hardware protection circuitry configured to prevent the first and second second-stage bootloader regions from being written to by software executed from the application region (and/or from the update working region). Software in the application region and/or update working region may be executed by the processor in a non-secure state. However, the hardware protection circuitry may allow writing to the first and second second-stage bootloader regions by software stored in the first and second second-stage bootloader regions (i.e. bootloader is in a secure region, and may write in the secure region), par 4; par 43].
It would have been obvious to one of ordinary skill in the art, having the teachings of Jacquin, Tahan, Dasari, and Amundsen before him before the effective filing date of the claimed invention, to incorporate the restricted writing as taught by Amundsen, into the device as disclosed by Jacquin, Tahan, and Dasari, to provide secure booting and firmware updating [Amundsen, par 6, 7].
Response to Arguments
Applicant’s arguments filed 02/05/26 have been considered but are moot due to the new rejection based on the references cited above.
Conclusion
Applicant is reminded that in amending a response to a rejection of claims, the patentable novelty must be clearly shown in view of the state of the art disclosed by the references cited and the objections made. Applicant must also show how the amendments avoid such references and objections. See 37 CFR §1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL J YEN whose telephone number is (571)270-5047. The examiner can normally be reached M-F 8-5 PT.
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, Andrew J Jung can be reached at (571) 270-3779. 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.
/Paul Yen/Primary Examiner, Art Unit 2175