DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-24 are presented for examination.
This office action is in response to the Amendment/Remarks and IDS on 4/3/26. Applicant’s arguments have been fully considered but were not found to be persuasive.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 9, and 17 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 11, and 21, respectively, of copending Application No. 18/149055 (reference application) in view of Shanbhogue et al. (US 2019/0228145 A1) (hereinafter Shanbhogue1).
Although the claims at issue are not identical, they are not patentably distinct from each other because every limitation in instant claim 1 is disclosed and anticipated in claim 1 of Application No. 18/149055, as shown in the below table:
Instant Application
Copending Application No. 18/149055
PNG
media_image1.png
534
890
media_image1.png
Greyscale
PNG
media_image2.png
510
856
media_image2.png
Greyscale
Specifically, claim 1 of Copending Application No. 18/149055 discloses:
An apparatus comprising (line 1):
a hardware processor core comprising a trust domain manager to manage one or more hardware isolated virtual machines as a respective trust domain with a region of protected memory (lines 2-4); and
input/output memory management unit (IOMMU) circuitry coupled between the hardware processor core and an input/output device, wherein the IOMMU circuitry is to, for a request from the input/output device for a direct memory access of a protected memory of a trust domain (lines 5-9),
allow the direct memory access in response to a field in the request being set to indicate the input/output device is in a trusted computing base of the trust domain (lines 10-13).
Claim 1 of Application No. 18/149055 does not explicitly disclose the IOMMU circuitry comprises a first set of registers for an invalidation queue that is accessible by a virtual machine monitor of the one or more hardware isolated virtual machines, and a second set of registers for a trusted invalidation queue that is accessible by the trust domain manager and not by the virtual machine monitor of the one or more hardware isolated virtual machines.
However, Shanbhogue1 teaches the IOMMU circuitry comprises a first set of registers (VT-d register address space 400) (Fig. 4) for an invalidation queue that is accessible by a virtual machine monitor of the one or more hardware isolated virtual machines (Standard - VMM-controlled), and a second set of registers (Trusted- SEAM-controlled; Trusted Vtd Register Set or address space 401 includes Trusted Invalidation Queue Pointers) ([0065]; Fig. 4) for a trusted invalidation queue that is accessible by the trust domain manager (accessible only to SEAM modules and protected from VMM access) ([0065]) and not by the virtual machine monitor (protected from VMM access) ([0065]) of the one or more hardware isolated virtual machine. It would have been obvious to one of ordinary skill in the art before the effective date of the application to modify claim 1 of Application No. 18/149055 to incorporate the IOMMU circuitry comprises a first set of registers for an invalidation queue that is accessible by a virtual machine monitor of the one or more hardware isolated virtual machines, and a second set of registers for a trusted invalidation queue that is accessible by the trust domain manager and not by the virtual machine monitor of the one or more hardware isolated virtual machines, as taught in Shanbhogue1. The suggestion/motivation for doing so would have been to provide the predicted result of having the ability to improve security by protecting against malicious VMMs ([0043]; [0061]).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
As to instant independent claims 9 and 17, every limitation is disclosed and anticipated in claims 11 and 21, respectively, of Application No. 18/149055, similarly to the rejection of instant claim 1.
Claims 2-8, 10-16, and 18-24 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 11, and 21, respectively, of copending Application No. 18/149055 (reference application) in view of Shanbhogue et al. (US 2019/0228145 A1) (hereinafter Shanbhogue1) and further in view of Shanbhogue et al. (US 2020/0310972 A1) (hereinafter Shanbhogue2).
As to instant dependent claim 2-8, 10-16, and 18-24, the limitations are not disclosed in claims 1, 11, and 21 of the reference application. However, the limitations are found to be obvious to one of ordinary skill in the art in view of the prior art rejections made below.
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-5, 7-13, and 15-21, and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Shanbhogue et al. (US 2019/0228145 A1) (hereinafter Shanbhogue1) in view of Shanbhogue et al. (US 2020/0310972 A1) (hereinafter Shanbhogue2).
Shanbhogue1 and Shanbhogue2 were cited in a previous PTO-892.
As to claim 1, Shanbhogue1 teaches an apparatus comprising:
a hardware processor core (Processor 104, Core 210) comprising a trust domain manager (SEAM Circuitry 124, Secure Arbitration Mode (SEAM) module 320 in Trust Domain Extensions (TDX), etc.) to manage one or more hardware isolated virtual machines (secure VMs (e.g., TD) as a respective trust domain (TD1 234, TD2 236, Trusted Domain 312 and 316, etc.) with a region of protected memory (reserved region of memory which is protected using a range register (e.g., SEAMRR) such that this memory cannot be read or written by any software outside the SEAM module or any devices ) ([0059]; [0039]-[0040]; [0051]; [0068]-[0069]; Figs. 1-5); and
input/output memory management unit (IOMMU) circuitry (IOMMU 128) coupled between the hardware processor core and an input/output device (Device 118 or 120), wherein the IOMMU circuitry comprises a first set of registers (VT-d register address space 400) (Fig. 4) for an invalidation queue that is accessible by a virtual machine monitor of the one or more hardware isolated virtual machines (Standard - VMM-controlled), and a second set of registers (Trusted- SEAM-controlled; Trusted Vtd Register Set or address space 401 includes Trusted Invalidation Queue Pointers) ([0065]; Fig. 4) for a trusted invalidation queue that is accessible by the trust domain manager (accessible only to SEAM modules and protected from VMM access) ([0065]) and not by the virtual machine monitor (protected from VMM access) ([0065]) of the one or more hardware isolated virtual machines, and the IOMMU circuitry is to, for a request from the input/output device for a direct memory access (DMA requests) of a protected (integrity-protected) memory of a trust domain (secure register space such as trusted VTD register space, etc.), allow the direct memory access in response to a field in the request being set to indicate the input/output device is in a trusted computing base (TCB) of the trust domain ([0034]; [0038]-[0040]; [0046]; [0068]-[0069]; [0078]; Figs. 1-5).
Shanbhogue1 does not explicitly use the term “trust domain manager.” However, one of ordinary skill in the art would reasonably be able to interpret the SEAM module as the claimed trust domain manager because it acts as a trust broker between TDs and the VMM ([0041]), configures trusted device contexts in the IOMMU ([0042]-[0044]), and prevents confused deputy attacks ([0043]-[0045]).
Nonetheless, Shanbhogue2 is introduced to more explicitly and further make the connection of the SEAM module being a trust domain manager as the secondary reference teaches a SEAM module 137 to be a trust arbiter between TDRM and the TDs 150A, 150B, 150C, etc. It manages resource assignments and enforces security policies for TDs (Abstract; [0034]-[0035]; [0039]; [0042]; [0053]; [0066]-[0067]; [0101]-[0102]; Figs 1-8).
It would have been obvious to one of ordinary skill in the art before the effective date of the application to combine the teachings of Shanbhogue1 and Shanbhogue2 as they are complementary references, wherein Shanbhogue1 teaches the foundational role of the SEAM module in managing TDs and securing IOMMU interactions, while Shanbhogue2 builds on this by explicitly associating the SEAM module with resource management and trust arbitration, which is functionally equivalent to the claimed trust domain manager under the broadest reasonable interpretation. The suggestion/motivation for the combination would have been to provide the predicted result of improving trust arbitration and secure resource allocation for trust domains.
As to claim 2, Shanbhogue1 teaches wherein the field in the request is a set of one or more bits in a prefix according to a Peripheral Component Interconnect Express (PCIe) standard ([0034]; [0174]; [0184]; [0079]; Figs 1-5).
As to claim 3, Shanbhogue1 teaches wherein, in response to the field in the request being set, the IOMMU circuitry is to generate an indication that a physical address of the protected memory of the trust domain is allowed to have a private key of the trust domain (TD private key) ([0041]; [0079]-[0081]; [0084]; [0095]; [0145]; [0164]).
As to claim 4, Shanbhogue2 teaches wherein, in response to the field in the request being set, the IOMMU circuitry is to generate an indication that a physical address of the protected memory of the trust domain is allowed to have a shared key (shared encryption key) of the trust domain and a virtual machine monitor (“shared” is meant to refer to a key accessible to the VMM 140; a TD can use a shared key ID to communicate with the VMM or other VMs or devices) of the one or more hardware isolated virtual machines ([0059]-[0061]).
As to claim 5, Shanbhogue1 (requests include fields (e.g., PASIDs) used by the IOMMU to verify the validity of a device) (Abstract; [0041]-[0045]; [0058]; [0078]-[0079]) in view of Shanbhogue2 (the SEAM module 137 ensures protection from tampering (e.g., by the VMM or other non-SEAM agent) of the memory mapping performed by the secure EPT 805. The SEAM module 137 specifies these to hardware as part of the VM entry to the TD using the following two new fields in the TD VMCS: (1) the secure EPT pointer 804; and (2) the TD-HKID 806) [0102]) teaches wherein, in response to the field in the request being set, the IOMMU circuitry is to access a trusted data structure of virtual address to physical address mappings managed by the trust domain manager and not by a virtual machine monitor of the one or more hardware isolated virtual machines.
As to claim 7, Shanbhogue1 teaches wherein the trust domain manager, and not a virtual machine monitor of the one or more hardware isolated virtual machines, is permitted to cause an indication of invalidation of one or more blocks of the protected memory of the trust domain to be stored in a trusted invalidation queue (invalidation queue and invalidation queue pointers) ([0065]; [0071]; [0075]).
As to claim 8, Shanbhogue1 teaches wherein the IOMMU circuitry comprises a root table pointer register that is accessible by the virtual machine monitor of the one or more hardware isolated virtual machines (VMM may programs the IOMMU registers such as Root Table Pointer (e.g., using PCIe segment information)) ([0071]), and a trusted root table pointer register (trusted VTd Register Set 401, trusted root pointer 402, etc.) that is accessible by the trust domain manager (SEAM module) and not by a virtual machine monitor of the one or more hardware isolated virtual machines (in one embodiment of a TDX trust model, these registers are to be protected from VMM access and only be accessible to the SEAM module) ([0065]; [0072]) (Figs 1-5).
As to claim 9, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 10, it is rejected for the same reasons as stated in the rejection of claim 2.
As to claim 11, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 12, it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 13, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 15, it is rejected for the same reasons as stated in the rejection of claim 7.
As to claim 16, it is rejected for the same reasons as stated in the rejection of claim 8.
As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 18, it is rejected for the same reasons as stated in the rejection of claim 2.
As to claim 19, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 20, it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 21, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 23, it is rejected for the same reasons as stated in the rejection of claim 7.
As to claim 24, it is rejected for the same reasons as stated in the rejection of claim 8.
Allowable Subject Matter
Claims 6, 14, and 22 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant argues that the amendment to claims 1 (and similarly, claims 9 and 17) and 8 (and similarly claims 16 and 24) overcome the current prior art rejections.
In response, as to claim 1, it was found that Shanbhogue1 teaches the IOMMU circuitry comprises a first set of registers (VT-d register address space 400) (Fig. 4) for an invalidation queue that is accessible by a virtual machine monitor of the one or more hardware isolated virtual machines (Standard - VMM-controlled), and a second set of registers (Trusted- SEAM-controlled; Trusted Vtd Register Set or address space 401 includes Trusted Invalidation Queue Pointers) ([0065]; Fig. 4) for a trusted invalidation queue that is accessible by the trust domain manager (accessible only to SEAM modules and protected from VMM access) ([0065]) and not by the virtual machine monitor of the one or more hardware isolated virtual machines.
In response to the newly amended limitations of claim 8, Shanbhogue1 teaches the apparatus of claim 1, wherein the IOMMU circuitry comprises a root table pointer register that is accessible by the virtual machine monitor of the one or more hardware isolated virtual machines (VMM may programs the IOMMU registers such as Root Table Pointer (e.g., using PCIe segment information)) ([0071]).
Therefore, the newly amended limitations of claims 1 (and similarly, claims 9 and 17) and 8 (and similarly claims 16 and 24) do not overcome the current prior art rejections and were not found to be allowable over prior art.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
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, Bradley Teets can be reached at 571-272-3338. 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.
/KENNETH TANG/Primary Examiner, Art Unit 2197
Prosecution Insights