DETAILED ACTION
Claims 1-16 rejected under 35 USC § 103.
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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-12, and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Hara, U.S. PG-Publication No. 2020/0293676 A1, in view of Sahita et al., U.S. PG-Publication No. 2025/0139305 A1.
Claim 1
Hara discloses a method, comprising: responsive to detecting a workload requesting access to a host memory buffer (HMB) associated with a nonvolatile storage device of an information handling system, performing … authentication operations, including: … authenticating the HMB to the application. Hara discloses a “memory system that can enhance security when an HMB is used.” Hara, ¶ 25. The system 1 comprises a host device 2 (i.e., information handling system) with SSD 3 (i.e., nonvolatile storage device) interconnected vis “NVM Express (NVMe).” Id. at ¶¶ 28-32. SSD 3 includes a controller 4 supporting “a host memory buffer (HMB) function … conforming to the NVMe standard.” The HMB function enables controller 4 “to exclusively use at least a part of an allocated area in the host RAM 22 as a temporary storage area” (i.e., HMB associated with SSD of host). Id. at ¶¶ 36-39. When data is read out from HMB 221, a parity checker 113 uses a key value randomly generated by CPU 12 “to verify whether or not an error occurs in the read data” (i.e., authenticating the HMD to the application). Id. at ¶¶ 63-64; See Also ¶ 77 (key generation unit 124 adds parity to data cached in HMB “to generate a key value for verifying the data read from the HMB”). The SSD 3 uses a “key value 64 and the parity 75” to verify whether or not the protected data 70 read from the HMB 221 has an error such as corruption or falsification.” Id. at ¶ 115.
Hara does not expressly disclose performing mutual authentication operations, including: authenticating an application corresponding to the workload to the HMB; and authenticating the HMB to the application; and responsive to successful completion of the mutual authentication operations, establishing a secure communications tunnel enabling the workload to access at least a portion of the HMB securely.
Sahita discloses performing mutual authentication operations, including: authenticating an application corresponding to the workload to the HMB; and authenticating the HMB to the application; and responsive to successful completion of the mutual authentication operations, establishing a secure communications tunnel enabling the workload to access at least a portion of the HMB securely. Sahita discloses methods using hardware-isolated VMs referred to as “trust domains (TDs)” and establishing a “trust relationship” between an I/O device and a TD, wherein a trust domain manager creates “a secure communication session between the device and the trust domain manager.” Id. at ¶ 20. The method comprises a DSM 136 to “support authentication of I/O device(s) 106 identities and measurement reporting.” DSM 136 implements authentication logic 135 to “facilitate establishment of a secure session .. .via a link operated according to the PCIe specification,” wherein an I/O device that includes DSM 136 has “an ability to implement mutual authentication in a confidential computing environment.” Id. at ¶¶ 35-36. I/O device 106 may include a memory or storage device that may include non-volatile types of memory (e.g., an HMB). See Id. at ¶ 56.
Figure 3 illustrates methos 300 “associated with activity in an authentication channel for mutual authentication” describing a first connection “between host 202 and I/O device 106.” At 3.2, TD 204 “uses other SPDM specification commands/requests to identify/authenticate I/O device 106” including “GET_Certificate” commands to get a device identify I/O device 104 and “KEY_EXCHANGE” to request to start a secure session creation with I/O device 106” (Step 3.2 → authenticating the HMB to the application). At 3., authentication logic of I/O device 105 “places a request to TPA TS 204 for mutual authentication.” Id. at ¶¶ 57-59. At step 3.7 TPA TD 204 “generates a TPA certificate with TD report” and at step 3.8 “sends the RPA certificate to I/O device 106.” At step 3.9 “attestation logic 137 of the I/O device 106 may verify the TPA certificate” in order to authenticate TPS TD 204 “and thus establishes a secure SPDM session or connection with TPS TD 204 and/or trust domain manager 101, e.g., through secured link 104A” (i.e., establish a secure communications tunnel). Id. at ¶¶ 60-67.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the host memory buffer authentication method of Hara to incorporate the mutual authentication of a host and I/O device taught by Sahita. One of ordinary skill in the art would be motivated to integrate the mutual authentication of a host and I/O device into Hara, with a reasonable expectation of success, in order to improve information security by maintaining “security (e.g., confidentiality) of information for a virtual machine from the VMM and/or other virtual machines,” thereby enhancing “a cloud-service provider’s … ability to provide managed cloud services without exposing tenant data to adversaries.” See Sahita, ¶¶ 16-17.
Claim 2
Sahita discloses prior to detecting the workload requesting access to the HMB, performing startup operations. In one embodiment, the SPDM communication work to establish a communication session is “performed by a secure startup service module (S3M)” of the processor, wherein the secure startup service module “includes SPDM capability and stack/device attestation capability.” Sahita, ¶ 23. The S3M 138 “may be used during platform boot” to send messages “to other I/O device(s) 106” to collect the measurement.” Id. at ¶ 40.
Sahita discloses launching the application in a trusted execution environment configured to perform a measured boot of the application to generate an application measurement; and generating, by the application, a first public/private key pair including a first public key and a first private key. In embodiments a “Trusted Execution Environment (TEE) security manager (TSM)” is used “to create a secure communication session between the device and the trust domain manager” will authenticate the device an collect device measurements. Herein, an endpoints “measurement” is “the process of calculating a cryptographic hash value of a piece of firmware/software or configuration data and tying the cryptographic hash value with the endpoints identity through a use of digital signatures.” Id. at ¶¶ 20-21; 43. At 3.4, TPA TD 204 generates an ephemeral key pair intended for the establishment of the secure connection. At 3.5, TPA TD 204 asks for a TD_REPORT “that includes a hash of an ephemeral public key associated with the generated ephemeral key pair” used to “help I/O device 106 to verify the ephemeral key” (ephemeral key pair → first public/private key pair). Id. at ¶¶ 60-61.
Sahita discloses launching the HMB in the trusted execution environment configured to perform a measured boot of the HMB to generate an HMB measurement; and generating, by the HMB, a second public/private key pair including a second public key and a second private key. At step 3.9 “attestation logic 137 of the I/O device 106 may verify the TPA certificate” and authentication logic 135 of I/O device van “verify a digital signature in an SPDM message,” in order to authenticate TPS TD 204 “and thus establishes a secure SPDM session or connection with TPS TD 204 and/or trust domain manager 101, e.g., through secured link 104A.” Id. at ¶¶ 65-66. The authentication logic 135 or attestation logic 137 may also verify the TPA certificate by checking a digital signature of the TPA certificate (e.g., using the hash of the ephemeral public key).” (TPA certificate and public key → second public/private key pair). Id. at ¶ 76.
Claim 3
Sahita discloses wherein authenticating the application includes: storing the application measurement and the first public key in a first register; and sending the application measurement and the first public key to a mutual validation orchestrator configured to: verify the application measurement; and generate an application identity certificate by endorsing the application measurement and the first public key in the first register. The S3M 138 facilitates establishment of a separate secure session “to enable an I/O device that includes DSM 136 to have an ability to implement mutual authentication in a confidential computing environment.” The S3M 138 comprises authentication logic 133 and attestation logic 139 “arranged to work with .. .features of DSM 136 at I/O device 106 … to facilitate implementation of mutual authentication” (S3M 138 → mutual validation orchestrator). Sahita, ¶¶ 36-37. The S3M 138 sends messages “to collect the measurement” during hardware initialization startup. Id. at ¶ 40. The attestation logic of the I/O device uses “attestation logic and/or features of the S3M as a trust agent … to verify a TD REPORT that was included in a TPA certificate received by the I/O device as described for scheme 300 at 3.9” (TPA certificate → application identity certificate). Id. at ¶¶ 68-69. After the I/O device 106 “accepts the TPA certificate, authentication logic 135 of I/O device 106 can verify a digital signature in an SPDM message to authenticate TPA TD 204 … and thus establishes a secure SPDM session … through secured link 104A (digital signature in SPDM message → first public key in first register). Id. at ¶ 66.
Claim 4
Sahita discloses wherein authenticating the HMB includes: storing the HMB measurement and the second public key in a second register; and sending the HMB measurement and the second public key to the mutual validation orchestrator, the mutual validation orchestrator being further configured to: verify the HMB measurement; and generate an HMB identity certificate by endorsing the HMB measurement and the second public key in the second register. Sahita discloses wherein the trusted domain establishes “ a trusted connection via a secured link … with an I/O device such as I/O device 106 according to the SPDM specification.” One type of local attestation utilizes a secured link “as an attestation channel to have I/O device 106 verify host 202 in cooperation with logic and/or features of S3M 138.” Sahita, ¶¶ 54-55. At step 4.5 in Figure 4, attestation logic 139 of S3M 138 verifies the TD_REPORT to issue a “local attestation ISA to host 202, to check an integrity of a message authentication code (MAC) in the TD-REPORT.” The local attestation “may be a mode-specific register (MSR) write … where an MSR at host 202 stored or holds the TD-REPORT” (TD-REPORT → HMBG identity certificate). Id. at ¶ 74. Further, The TD_REPORT “includes a hash of an ephemeral public key associated with the generated ephemeral key pair,” and content of values may include “evidence of a platform configuration in a platform configuration register (PCR), audit logs, or key properties of TDM 101” (i.e., first public key in the first register). Id. at ¶ 61.
Claim 6
Hara discloses wherein the nonvolatile storage device comprises a solid state drive (SSD). Hara discloses a “memory system that can enhance security when an HMB is used.” Hara, ¶ 25. The system 1 comprises a host device 2 (i.e., information handling system) with SSD 3 (i.e., nonvolatile storage device) interconnected vis “NVM Express (NVMe).” Id. at ¶¶ 28-32. SSD 3 includes a controller 4 supporting “a host memory buffer (HMB) function … conforming to the NVMe standard.” The HMB function enables controller 4 “to exclusively use at least a part of an allocated area in the host RAM 22 as a temporary storage area” (i.e., HMB associated with SSD of host). Id. at ¶¶ 36-39.
Claim 7
Hara discloses wherein the SSD comprises a nonvolatile memory express (NVMe) SSD. Hara discloses a “memory system that can enhance security when an HMB is used.” Hara, ¶ 25. The system 1 comprises a host device 2 (i.e., information handling system) with SSD 3 (i.e., nonvolatile storage device) interconnected vis “NVM Express (NVMe).” Id. at ¶¶ 28-32. SSD 3 includes a controller 4 supporting “a host memory buffer (HMB) function … conforming to the NVMe standard.” The HMB function enables controller 4 “to exclusively use at least a part of an allocated area in the host RAM 22 as a temporary storage area” (i.e., HMB associated with SSD of host). Id. at ¶¶ 36-39.
Claim 8
Sahita discloses wherein the application comprises an application selected from: an operating system (OS) application, a virtual machine (VM) application, a hypervisor application, a container application, and a firmware application. Sahita discloses that the method is for maintaining security … of information for a virtual machine from the VMM and/or other virtual machine(s),” wherein a “hardware processor and its ISA … implement TDs (e.g., trusted VMs) to enhance a cloud-service provider’s (CSP_ ability to provide managed cloud services without exposing tenant data to adversaries.” (i.e., applications are VM applications). Sahita, ¶¶ 16-17.
Claims 9-12 and 14-16
Claims 9-12 and 14-16 are rejected utilizing the aforementioned rationale for Claims 1-4 and 6-8; the claims are directed to a system performing the method.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Hara, U.S. PG-Publication No. 2020/0293676 A1, in view of Sahita et al., U.S. PG-Publication No. 2025/0139305 A1, further in view of Thibadeau, U.S. PG-Publication No. 2007/0250710 A1.
Claim 5
Thibadeau discloses wherein the application identity certificate and the HMB identity certificate each comprise an identity certificate selected from: a Secure Production Identity Framework for Everyone (SPIFFE) verifiable identity document (SVID), an 802.1AR identity certificate, and an x509 certificate. Thibadeau discloses a messaging system with a plurality of credentials and authorities, wherein each authority “associates at least one of a plurality of protocol operations with at least one of the plurality of credentials,” including “authentication, key exchange, and/or key agreement operations.” Thibadeau, ¶ 8. The method enables a host and a peripherals to communicate via an “Authority” that “associates a corresponding Credential with a respective Authentication Operation,” including “a certificate chain providing acceptability of a particular public key or a requirement that a certificate he otherwise checked for certain validity conditions.” Id. at ¶¶ 24-27. Identify certificate data includes data in “X.509 as defined by the certificate’s requirements.” Id. at ¶¶ 65, 76, 77 (Tables 2, 5, 6). The certificate data “is used for data validating a public key.” Id. at ¶ 66.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the host memory buffer authentication method of Hara-Sahita to incorporate certificates from an authority validating public keys as taught by Thibadeau. One of ordinary skill in the art would be motivated to integrate certificates from an authority validating public keys into Hara-Sahita, with a reasonable expectation of success, in order to “provide increased versatility and extensibility to many different secure … messaging protocols and which do not require intelligent mechanisms at both channel ends to negotiate a selected protocol.” See Thibadeau, ¶ 6.
Claim 13
Claim 13 is rejected utilizing the aforementioned rationale for Claim 5; the claim is directed to a system performing the method.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 10-6 ET.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 June 27, 2026
Prosecution Insights