DETAILED ACTION
1. This Office Action is taken in response to Applicants’ application 19/056,784 filed on 2/19/2025.
Claims 1-8 are pending for consideration.
2. Examiner’s Note
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
(2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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.
3. Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US Patent Application Publication 2020/0409734, hereinafter Sahita), and in view of Sukhomilnov et al. (US Patent Application Publication 2017/0286310, hereinafter Sukhomilnov).
As to claim 1, Sahita teaches 1. A confidential computing (CC) apparatus [as shown in figures 1-4, and 13; Implementations describe a computing system that implements a plurality of virtual machines inside a trust domain (TD), enabled via a secure arbitration mode (SEAM) of the processor. A processor includes one or more registers to store a SEAM range of memory, a TD key identifier of a TD private encryption key. The processor is capable of initializing a trust domain resource manager (TDRM) to manage the TD, and a virtual machine monitor within the TD to manage the plurality of virtual machines therein. The processor is further capable of exclusively associating a plurality of memory pages with the TD, wherein the plurality of memory pages associated with the TD is encrypted with a TD private encryption key inaccessible to the TDRM. The processor is further capable of using the SEAM range of memory, inaccessible to the TDRM, to provide isolation between the TDRM and the plurality of virtual machines (abstract); ... In some cases, a TD may wish to protect the confidentiality of the data transmitted to devices, for example, the data stored on a hard drive. Since the data stored to shared memory may be accessible to all software, the TD software may first encrypt such data using a specific device key, such as a disk encryption key, before storing the data into memory using the shared key ID ... (¶ 0054)], comprising:
a CPU, to run a hypervisor that hosts one or more Trusted Virtual Machines (TVMs) [as shown in figure 1A, where the server/CPU includes a TD-VMM (146), which is the corresponding hypervisor, and a plurality of Virtual Machines VM1 (145A) and VM2 (145B); The processor is capable of initializing a trust domain resource manager (TDRM) to manage the TD, and a virtual machine monitor within the TD to manage the plurality of virtual machines therein ... (abstract); The processor 112 may execute a virtual machine monitor (VMM) 140, which may be extended with a TD resource manager (TDRM) 142. The VMM 140 may control one or more legacy virtual machines, such as VM1 145A and VM2 145B. The legacy VMs may be executed outside the TDX (e.g., without a support from the SEAM), as schematically shown in FIG. 1 ... Implementations describe a computing system that implements a plurality of virtual machines inside a trust domain (TD), enabled via a secure arbitration mode (SEAM) of the processor. A processor includes one or more registers to store a SEAM range of memory, a TD key identifier of a TD private encryption key. The TDs 150A-B may be trust domains without nested virtualization, namely each TD 150 may support one client device 102. The virtualization server 110 may support a different type of a TD, such as TD3 150C, that is capable of supporting multiple virtual machines, e.g., TD-VM1 155A and TD-VM2 155B. The TD3 150C may include the trusted hypervisor TD-VMM 146 for management of TD-VMs ... (¶ 0042-0044); Sukhomilnov also teaches this limitation – as shown in figure 4, where there are multiple Virtual machines VM(1)-VM(N) (404, 406, 408), and a hypervisor/VMM (418)], wherein the CC apparatus provides inter-TVM isolation and hardware isolation between the one or more TVMs and the hypervisor [... The processor is further capable of using the SEAM range of memory, inaccessible to the TDRM, to provide isolation between the TDRM and the plurality of virtual machines (abstract); ... Secure operation of both the trusted TD-VMM and the untrusted host VMM is facilitated through a secure arbitration mode (SEAM) of the processor. The SEAM may utilize a special SEAM memory range whose isolation from the host VMM may be hardware-enabled. The SEAM memory range may host secure extended page tables for management of memory assigned to a trust domain (TD) (¶ 0029); In some implementations, a virtual machine monitor (in the following description referred simply as “VMM”) that is separate from the host VMM may be executed inside a TD (in the following description referred as “TD-VMM”). The TD-VMM may instantiate a plurality of virtual machines (in the following description, TD-VMs). Each or some of the TD-VMs may support guest operating systems (OS) to facilitate execution of client software. Once the VMM has exclusively associated a plurality of memory pages with the TD, the TD-VMM may own assignment of some of those memory pages to various TD-VMs, to isolate the TD-VMs and also protect the TD-VMM itself ... On the other hand, the VMM may be outside the trusted computing base of the TD meaning the TD-VMM cannot rely on VMM to enforce isolation of the TD's logical processor state and management of its memory (¶ 0037); ... In other implementations, each TD-VM 155 may use its own gSEPT 166 and the TD-VMM 146 may forbid other TD-VMs access this gSEPT. Accordingly, the TD-VMM 146 may effectively provide isolation between different TD-VMs ... (¶ 0058)]; and
a network device coupled to the CPU and to an external memory [network interface, figure 1A, 104; figure 13 shows the processing device (1302) which runs the hypervisor, the network device (1308), and external memory/storage (1304, 1306, 1318); Sukhomilnov also teaches this limitation – a network device as shown in figure 4, 106, which includes a network function management module (320), and a main memory management module (330); Referring now to FIG. 4, in another illustrative embodiment, the network computing device 106 establishes an environment 400 during operation ... Further, each of the virtual functions 410 also shares one or more physical resources on the NIC 216, such as an external network port, memory, etc., with the physical functions of the NIC 216 (¶ 0054); ... in a cache block of the cache memory that is presently mapped to a corresponding memory region of a main memory of the network computing device externally coupled to the processor ... (¶ 0103)], for providing network communication to the CC apparatus [... The computing system 100 may further include a network interface 104 ... (¶ 0041); The computing system 1300 may further include a network interface device 1308 communicably coupled to a network 1320 ... (¶ 0162); Sukhomilnov also teaches this limitation – a network device as shown in figure 4, 106, which includes a network function management module (320), and a main memory management module (330); Referring now to FIG. 4, in another illustrative embodiment, the network computing device 106 establishes an environment 400 during operation ... Further, each of the virtual functions 410 also shares one or more physical resources on the NIC 216, such as an external network port, memory, etc., with the physical functions of the NIC 216 (¶ 0054)], wherein the CPU is further to run a Device TVM (DTVM) [as shown in figure 1A, where the VMM(140)/TDRM(142) is the corresponding DTVM; ... The processor is capable of initializing a trust domain resource manager (TDRM) to manage the TD, and a virtual machine monitor within the TD to manage the plurality of virtual machines therein. The processor is further capable of exclusively associating a plurality of memory pages with the TD, wherein the plurality of memory pages associated with the TD is encrypted with a TD private encryption key inaccessible to the TDRM. The processor is further capable of using the SEAM range of memory, inaccessible to the TDRM, to provide isolation between the TDRM and the plurality of virtual machines (abstract); Sukhomilnov also teaches this limitation – as shown in figure 4, where one of the multiple VMs (404, 406, 408) may serve as a DVTM] including: an interface to the network device [as shown in figure 13, where the processing device (1302) is interfaced with the networking device (1308); Sukhomilnov also teaches this limitation – as shown in figure 4]; and
a hypervisor interface which presents the DTVM to the hypervisor as a TVM, in a manner that the CC provides inter-TVM isolation and hardware isolation between the DTVM and the one or more TVMs and the hypervisor, as if the DTVM is a TVM [Sahita teaches inter-VTM isolation and hardware isolation between the DTVM and the one or more TVMs and the hypervisor -- ... The processor is further capable of using the SEAM range of memory, inaccessible to the TDRM, to provide isolation between the TDRM and the plurality of virtual machines (abstract); ... Secure operation of both the trusted TD-VMM and the untrusted host VMM is facilitated through a secure arbitration mode (SEAM) of the processor. The SEAM may utilize a special SEAM memory range whose isolation from the host VMM may be hardware-enabled. The SEAM memory range may host secure extended page tables for management of memory assigned to a trust domain (TD) (¶ 0029); In some implementations, a virtual machine monitor (in the following description referred simply as “VMM”) that is separate from the host VMM may be executed inside a TD (in the following description referred as “TD-VMM”). The TD-VMM may instantiate a plurality of virtual machines (in the following description, TD-VMs). Each or some of the TD-VMs may support guest operating systems (OS) to facilitate execution of client software. Once the VMM has exclusively associated a plurality of memory pages with the TD, the TD-VMM may own assignment of some of those memory pages to various TD-VMs, to isolate the TD-VMs and also protect the TD-VMM itself ... On the other hand, the VMM may be outside the trusted computing base of the TD meaning the TD-VMM cannot rely on VMM to enforce isolation of the TD's logical processor state and management of its memory (¶ 0037); ... In other implementations, each TD-VM 155 may use its own gSEPT 166 and the TD-VMM 146 may forbid other TD-VMs access this gSEPT. Accordingly, the TD-VMM 146 may effectively provide isolation between different TD-VMs ... (¶ 0058);
Sukhomilnov teaches presenting the DTVM to the hypervisor as a TVM, so that the hypervisor views the DVTM as if it is a VTM -- as shown in figure 4, where one of the multiple VMs (404, 406, 408) may serve as a DVTM; Referring now to FIG. 4, in another illustrative embodiment, the network computing device 106 establishes an environment 400 during operation. The illustrative environment 400 includes a plurality of VMs 402 executed on the network computing device 106, each of which is communicatively coupled to one of a plurality of virtual functions 410 of the NIC 216. In use, the NIC 216 is divided into set of independent virtual functions 410, with each independent virtual functions 410 having its own configuration (e.g., PCI configuration space, media access control (MAC) address, settings, etc.), which may be assigned exclusively to VMs (e.g., the VMs 402) or used by native applications. Further, each of the virtual functions 410 also shares one or more physical resources on the NIC 216, such as an external network port, memory, etc., with the physical functions of the NIC 216 ... (¶ 0054-0055)], wherein the DTVM is to:
receive from the hypervisor allocations of memory space in the external memory for the network device [figure 13 shows the processing device (1302) which runs the hypervisor, the network device (1308), and external memory/storage (1304, 1306, 1318); memory allocations as shown in figures 3A, 3B, 4A, and 4B; In various implementations, the processor 112 includes one or more processor cores 114 and a micro-architectural physical address metadata table (PAMT) 120. The PAMT may be used by the processor 112 to store attributes of physical memory pages, such as allocations of physical memory pages to the TD1, TD2, and TD3 ... (¶ 0045); FIG. 5A illustrates an example method 500 that implements virtual machines inside a trust domain (TD), in the SEAM-enabled TD-VMX architecture ... The processing logic may also initialize a trust domain resource manager (TDRM) to manage the TD, including allocation of resources, such as physical memory, to the TD. The TDRM may manage additional TDs. Some of these additional TDs may not support virtualization whereas other TDs may also support a plurality of TD-VMs. To ensure secure execution of applications inside the TDs, the TDRM may not be included in the trusted computing base of the TDs ... For example, the TDRM may allocate one or more host memory pages to store a primary (or secondary) virtual machine control structure (VMSC) to store the state of the virtual processor of the TD-VMM (or one of the TD-VMs), but may not have access to it ... (¶ 0097-0099); Interconnect 1211 provides communication channels to the other components, such as a Subscriber Identity Module (SIM) 1230 to interface with a SIM card, a boot ROM 1235 to hold boot code for execution by cores 1206 and 1207 to initialize and boot SoC 1200, a SDRAM controller 1240 to interface with external memory (e.g. DRAM 1260) ... (¶ 0157); Sukhomilnov also teaches this limitation – a network device as shown in figure 4, 106, which includes a network function management module (320), and a main memory management module (330); Referring now to FIG. 4, in another illustrative embodiment, the network computing device 106 establishes an environment 400 during operation ... Further, each of the virtual functions 410 also shares one or more physical resources on the NIC 216, such as an external network port, memory, etc., with the physical functions of the NIC 216 (¶ 0054)]; and
allocate the memory space in the external memory to the network device, in response to the hypervisor allocations [figure 13 shows the processing device (1302) which runs the hypervisor, the network device (1308), and external memory/storage (1304, 1306, 1318); memory allocations as shown in figures 3A, 3B, 4A, and 4B; In various implementations, the processor 112 includes one or more processor cores 114 and a micro-architectural physical address metadata table (PAMT) 120. The PAMT may be used by the processor 112 to store attributes of physical memory pages, such as allocations of physical memory pages to the TD1, TD2, and TD3 ... (¶ 0045); FIG. 5A illustrates an example method 500 that implements virtual machines inside a trust domain (TD), in the SEAM-enabled TD-VMX architecture ... The processing logic may also initialize a trust domain resource manager (TDRM) to manage the TD, including allocation of resources, such as physical memory, to the TD. The TDRM may manage additional TDs. Some of these additional TDs may not support virtualization whereas other TDs may also support a plurality of TD-VMs. To ensure secure execution of applications inside the TDs, the TDRM may not be included in the trusted computing base of the TDs ... For example, the TDRM may allocate one or more host memory pages to store a primary (or secondary) virtual machine control structure (VMSC) to store the state of the virtual processor of the TD-VMM (or one of the TD-VMs), but may not have access to it ... (¶ 0097-0099); Sukhomilnov also teaches this limitation – a network device as shown in figure 4, 106, which includes a network function management module (320), and a main memory management module (330); Referring now to FIG. 4, in another illustrative embodiment, the network computing device 106 establishes an environment 400 during operation ... Further, each of the virtual functions 410 also shares one or more physical resources on the NIC 216, such as an external network port, memory, etc., with the physical functions of the NIC 216 (¶ 0054)].
Regarding claim 1, Sahita teaches a VTRM serving as a DVTM [as shown in figure 1A, where the VMM(140)/TDRM(142) is the corresponding DTVM; ... The processor is capable of initializing a trust domain resource manager (TDRM) to manage the TD, and a virtual machine monitor within the TD to manage the plurality of virtual machines therein. The processor is further capable of exclusively associating a plurality of memory pages with the TD, wherein the plurality of memory pages associated with the TD is encrypted with a TD private encryption key inaccessible to the TDRM. The processor is further capable of using the SEAM range of memory, inaccessible to the TDRM, to provide isolation between the TDRM and the plurality of virtual machines (abstract)], but does not expressively teach presenting the DTVM to the hypervisor as a TVM, so that the hypervisor views the DVTM as if it is a VTM.
However, Sukhomilnov specifically teaches presenting the DTVM to the hypervisor as a TVM, so that the hypervisor views the DVTM as if it is a VTM [as shown in figure 4, where one of the multiple VMs (404, 406, 408) may serve as a DVTM; Referring now to FIG. 4, in another illustrative embodiment, the network computing device 106 establishes an environment 400 during operation. The illustrative environment 400 includes a plurality of VMs 402 executed on the network computing device 106, each of which is communicatively coupled to one of a plurality of virtual functions 410 of the NIC 216. In use, the NIC 216 is divided into set of independent virtual functions 410, with each independent virtual functions 410 having its own configuration (e.g., PCI configuration space, media access control (MAC) address, settings, etc.), which may be assigned exclusively to VMs (e.g., the VMs 402) or used by native applications. Further, each of the virtual functions 410 also shares one or more physical resources on the NIC 216, such as an external network port, memory, etc., with the physical functions of the NIC 216 ... (¶ 0054-0055)].
Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to present the DTVM to the hypervisor as a TVM, so that the hypervisor views the DVTM as if it is a VTM, as specifically demonstrated by Sukhomilnov, and to incorporate it into the existing scheme disclosed by Sahita, because Sukhomilnov teaches doing so provides an effective mechanism for managing data transmission traffic for the network device [... Each of the virtual functions 410 are managed by the NIC 216 and data traffic transmitted therebetween is managed by the network function management module 320 of FIG. 3, described in detail above. It should be appreciated that two or more of the virtual functions 410 are configured to exchange communications via a shared memory (not shown) ... (¶ 0055)].
As to claim 2, Sahita in view of Sukhomilnov teaches The CC apparatus according to claim 1, wherein the CPU is to attest the DTVM when the network device accesses the external memory [Sahita – as shown in figure 3B, where the accessing target is determined to be either a shared page or a private page, and handled accordingly; FIG. 3B is a block diagram illustrating memory transactions inside a trust domain with accesses to shared or private memory pages, according to one implementation (¶ 0008); In some implementations, a virtual machine monitor (in the following description referred simply as “VMM”) that is separate from the host VMM may be executed inside a TD (in the following description referred as “TD-VMM”). The TD-VMM may instantiate a plurality of virtual machines (in the following description, TD-VMs). Each or some of the TD-VMs may support guest operating systems (OS) to facilitate execution of client software. Once the VMM has exclusively associated a plurality of memory pages with the TD, the TD-VMM may own assignment of some of those memory pages to various TD-VMs, to isolate the TD-VMs and also protect the TD-VMM itself. For example, the TD-VMM may control assignment of guest physical addresses (GPAs) to different TD-VMs ... (¶ 0037); FIG. 3B is a block diagram 350 illustrating memory transactions inside a trust domain with accesses to shared or private memory pages, according to one implementation. Shown is the TD3 150C that may access a GPA and send that GPA to the memory management unit (MMU) 124 ... (¶ 0084-0086)].
As to claim 3, Sahita in view of Sukhomilnov teaches The CC apparatus according to claim 1, wherein the interface to the network device interfaces to a device software running on the CPU, which interfaces to the network device [Sahita -- figure 13 shows the processing device (1302) which runs the hypervisor, the network device (1308), and external memory/storage (1304, 1306, 1318); FIG. 13 illustrates a diagrammatic representation of a machine in the example form of a computing system 1300 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client device in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment ... (¶ 0159); Sukhomilnov -- Accordingly, the network function management module 320 is further configured to manage each of the virtual function drivers associated with the respective VMs of each VNF, as well as manage the communications therebetween. In other words, the network function management module 320 is configured to direct the flow of data to the appropriate network functions and between the appropriate network functions. For example, the network function management module 320 is configured to determine an intended destination (e.g., a VM) for which data is to be directed (i.e., based on an access request) and direct the data to an interface of the intended destination (i.e., a virtual function of the VM) ... (¶ 0040-0042)].
As to claim 4, Sahita in view of Sukhomilnov teaches The CC apparatus according to claim 1, further including at least one additional network device coupled to the CPU and wherein the DTVM additionally supports the at least one additional network device [Sahita -- network interface, figure 1A, 104; figure 13 shows the processing device (1302) which runs the hypervisor, the network device (1308), and external memory/storage (1304, 1306, 1318); ... The computing system 100 may further include a network interface 104 and shared hardware devices 160A and 160B ... (¶ 0041); The core 790 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 790 may be a special-purpose core, such as, for example, a network or communication core, compression engine, graphics core, or the like (¶ 0124); The computing system 1300 may further include a network interface device 1308 communicably coupled to a network 1320 ... (¶ 0162); Sukhomilnov -- The network function management module 320, which may be embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof as discussed above, is configured to manage the physical and virtual functions of the NIC and associated VMs and/or applications of the network computing device 106 ... (¶ 0039-0040)].
As to claim 5, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details.
As to claim 6, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 7, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details.
As to claim 8, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to “As to claim 4” presented earlier in this Office Action for details.
Conclusion
4. Claims 1-8 are rejected as explained above.
5. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached on 571-272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SHENG JEN TSAI/Primary Examiner, Art Unit 2139
Prosecution Insights