DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following is a second non-final office action in response to communications received 01/15/2026. Claims 1-20 are pending and addressed below.
Response to Arguments
Applicant’s arguments filed 01/15/2026 have been fully considered but they are moot in view of new grounds of rejections.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 5-10, 13-18, 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Shanbhogue et al (EP 3720084) (from Applicant’s IDS).
As per claim 1, Shanbhogue discloses an apparatus comprising: a hardware processor core comprising a trust domain manager to manage one or more hardware (…see a processor (CPU)…includes additional security capability (e.g. Trust Domain extensions) to meet security objectives relating to Trusted domain…see par. 14-15) isolated virtual machines as a respective trust domain (…VT-d enables system software to create multiple DMA protection domains…each protection domain (e.g. trusted domain) is an isolated environment containing a subset of the host physical memory…a DMA protection domain may represent memory allocated to a virtual machine (VM)…see par. 26); a coupling between the hardware processor core and an input/output device (…the VT-d architecture enables system software to assign one or more I/O devices to a protection domain…see par. 26); a secure startup service circuit separate from the trust domain manager (…see a trusted intermediary, for example, SEAM module…see par. 16) to, in response to a request from the trust domain manager, generate a secure communication session between the trust domain manager and the input/output device (see par. 33).
As per claim 9, Shanbhogue discloses a method comprising: managing one or more hardware isolated virtual machines as a respective trust domain by a trust domain manager of a hardware processor core (…(…see a processor (CPU)…includes additional security capability (e.g. Trust Domain extensions) to meet security objectives relating to Trusted domain…see par. 14-15…VT-d enables system software to create multiple DMA protection domains…each protection domain (e.g. trusted domain) is an isolated environment containing a subset of the host physical memory…a DMA protection domain may represent memory allocated to a virtual machine (VM)…see par. 26; generating, by a secure startup service circuit separate from the trust domain manager (…see a trusted intermediary, for example, SEAM module…see par. 16), a secure communication session between the trust domain manager and an input/output device in response to a request from the trust domain manager; and communicating between the trust domain manager and the input/output device on the secure communication session (see par. 33).
As per claim 17, Shanbhogue discloses a system comprising: a hardware processor core comprising a trust domain manager to manage one or more hardware (…see a processor (CPU)…includes additional security capability (e.g. Trust Domain extensions) to meet security objectives relating to Trusted domain…see par. 14-15) isolated virtual machines as a respective trust domain (…VT-d enables system software to create multiple DMA protection domains…each protection domain (e.g. trusted domain) is an isolated environment containing a subset of the host physical memory…a DMA protection domain may represent memory allocated to a virtual machine (VM)…see par. 26); an input/output device coupled to the hardware processor core (…the VT-d architecture enables system software to assign one or more I/O devices to a protection domain…see par. 26); a secure startup service circuit separate from the trust domain manager (…see a trusted intermediary, for example, SEAM module…see par. 16) to, in response to a request from the trust domain manager, generate a secure communication session between the trust domain manager and the input/output device (see par. 33).
As per claims 2, 10, 18, Shanbhogue discloses wherein the secure startup service circuit is to generate the secure communication session between the trust domain manager and the input/output device without stalling the trust domain manager of the hardware processor core until the generation of the secure communication session is complete (see par. 35).
As per claims 5, 13, Shanbhogue discloses wherein the secure startup service circuit is to communicate with the input/output device to setup the secure communication session comprising a device certificate, and send the device certificate for the input/output device to the trust domain manager of the hardware processor core to generate the secure communication session between the trust domain manager and the input/output device (see par. 53).
As per claims 6, 14, Shanbhogue discloses wherein the secure startup service circuit is to communicate with the input/output device to setup the secure communication session comprising a session key, and send the session key to the trust domain manager of the hardware processor core to generate the secure communication session between the trust domain manager and the input/output device (see par. 33, 53).
As per claim 7, 15, Shanbhogue discloses wherein the secure startup service circuit is to communicate with the input/output device to setup the secure communication session comprising a session key and a device certificate, and send the session key and the device certificate for the input/output device to the trust domain manager of the hardware processor core to generate the secure communication session between the trust domain manager and the input/output device (see par. 33, 53).
As per claim 8, Shanbhogue discloses wherein the request from the trust domain manager is caused by a request from a hardware isolated virtual machine, as a trust domain, to access the input/output device by the secure communication session (see par. 16-17).
As per claim 16, Shanbhogue discloses further comprising sending a request from a hardware isolated virtual machine, as a trust domain, to access the input/output device by the secure communication session, wherein the request from the hardware isolated virtual machine causes the request to be sent from the trust domain manager to the secure startup service circuit (see par. 18).
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 3, 4, 11, 12, 19, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shanbhogue et al (EP 3720084) in view of Trivedi et al (Pub. No. US 2021/0110065).
As per claims 3, 11, 19, Shanbhogue does not explicitly wherein the secure communication session is according to a Security Protocol and Data Model (SPDM) standard. However Trivedi discloses wherein the secure communication session is according to a Security Protocol and Data Model (SPDM) standard (…the secure communication via attestation and key exchange in network environment may be provided in a variety of different scenarios…tenant attestation with direct upload…every PR upload utilizes a handshake and runtime context, long-term interoperable tools/protocols…the tenant may not be online to (re-) start their workload…security protocol and data model (SPDM)-based attestation and key exchange may be utilized…the SPDM specification provides message exchange, sequence diagrams, message formats, and other relevant semantics for authentication, firmware measurement, and certificate management…see par. 128). Therefore one ordinary skill in the art would have found it obvious before the effective filling date of the claimed invention to use Trivedi in Shanbhogue for including the above limitations because one ordinary skill in the art would recognize it would improve enabling secure communication via attestation…see Trivedi, par. 2-3.
As per claims 4, 12, 20, the combination of Shanbhogue and Trivedi discloses wherein the secure communication session is also according to a Device Interface Management Protocol (DIMP) standard (Trivedi: see par. 74-75). The motivation for claims 4, 12, 20 is the same motivation as in claims 3, 11, 19 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-form 892).
The following Patents and Papers are cited to further show the state of the art at the time of Applicant’s invention with respect to implementing a trusted execution environment.
Bosch et al (Pub. No. US 2012/0137117); “System and Method for Providing Secure Virtual Machines”;
-Teaches setting up secure virtual machines…booting the processor with a zone manage image…see par. 12-15.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHAZAL B SHEHNI whose telephone number is (571)270-7479. The examiner can normally be reached Mon-Fri 9am-5pm PCT.
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, Philip Chea can be reached at 5712723951. 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.
/GHAZAL B SHEHNI/Primary Examiner, Art Unit 2499