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 on 7/28/25. 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). 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
344
861
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).
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-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 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 the 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 6, 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 (VMM-managed TCB 202 or VMM enforced access controls instead of control to SEAM-managed TCB with TDX access control 204, etc.) (Abstract; [0069]; Figs 2, 3, 4, 9) teaches wherein, in response to the field in the request not being set, the IOMMU circuitry is to access a data structure of virtual address to physical address mappings managed by the virtual machine monitor and not access the trusted data structure of virtual address to physical address mappings managed by the trust domain manager.
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 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 14, it is rejected for the same reasons as stated in the rejection of claim 6.
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 22, it is rejected for the same reasons as stated in the rejection of claim 6.
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.
Response to Arguments
Applicant argues that it is not clear from the office action how Shanbhogue1 teaches to “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.”
In response, Shanbhogue1 shows extensive teaching of this limitation as pointed out by the Examiner. One example that clearly illustrates this is in Fig. 3 below:
PNG
media_image3.png
389
769
media_image3.png
Greyscale
In Fig. 3 of Shanbhogue1, Trusted DMA 330 is the direct memory access path, Trusted TLP 334 provides the request packet containing the field (unique IOMMU ID 324/attestation) that is sent to Trusted Device 304, and Trusted Authentication and Provisioning 336 checks that field to determine (via authentication phase) whether the device belongs to the trusted computing base. Together, these elements show that direct memory access to protected memory is allowed only in response to a trusted field in the request being set. Thus, Shanbhogue1 teaches the limitations of claim 1. In addition, Applicant does not provide any arguments against the cited references, and therefore, Applicant’s arguments were not found to be persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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 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