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 .
This Office Action is in response to Request for Continued Examination filed on 04 March, 2026 and Applicant Amendment and Arguments filed on 05 February, 2026.
Claims 21-40 are pending for examination. Claims 1-20 were cancelled
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05 February, 2026 has been entered.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,494,214 B2 in view of Traut (US. Pub. 2007/0050764 A1) and further in view of Joshi et al. (US Pub. 2018/0287883 A1), BHANDARI et al. (US Pub. 2019/0102212 A1), Sood et al. (US Pub. 2018/0114012 A1) and Baldwin et al. (US Pub. 2010/0082991 A1).
Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application are obvious over the claims of U. S. Patent No. 11,494,214. See MPEP 804.
The side-by-side comparison below of claim 21 of the instant application and claim 1 of U. S. Patent No. 11,494,214 clearly shows limitation by limitation matching between the two conflicting claims. The differences have been bolded
Instant Application
Patent 11,494,214 B2
21. A computer-implemented method, comprising:
obtaining, at a cloud computing environment via one or more programmatic interfaces, an indication of (a) a software container image to be utilized to perform a trusted computation using a software enclave at a server of the cloud computing environment, and (b) a memory requirement of the software enclave;
causing a first portion of memory of a virtual machine of a particular server of the cloud computing environment to be configured for private use by the software enclave,
wherein a size of the first portion of memory is based at least in part on the memory requirement, and
wherein after the first portion of memory of the particular server is configured for private use by the software enclave, data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave; and
causing the trusted computation to be performed using the first portion of memory and the software container image.
1. A system, comprising:
one or more computing devices of a virtualized computing service;
wherein the one or more computing devices include instructions that upon execution on or across one or more processors cause the one or more computing devices to:
launch a compute instance at a virtualization host, wherein a portion of memory of the virtualization host is allocated to the compute instance;
(Traut, Fig. 6, 605 Child Partition 2A, 606 Child partition 1B (as software enclave, second level of parent partition); Abstract, lines 1-2, Hierarchical virtualization is disclosed, where such virtualization can be accomplished with a multi-level mechanism; [0002] lines 1-3; [0059] lines 3-5, the hypervisor API library 806 exposes the hypervisor API to higher-level components, allowing them to call the hypervisor; [0063] lines 2-11, allows user-level components to create, delete, and manage partitions and specify partition-wide resources (as resource requirement) and quotas, defining scheduling and access control policies. For example, the creation of a new partition might be implemented by first making a hypercall to a module within the hypervisor (as the module receiving an indication via the hypervisor API for crating different partitions (multi-level partitions) with associated the resource requirement); [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure);
(Joshi, Fig. 1, Cloud computing environment, 14 computing device (as server); 36 container (as software enclave); [0002] lines 1-6, Distributed applications are computer applications implemented across multiple hosts. The hosts may be a group of computers, virtual machines, or containers...Examples include client-server architectures, in which a client computer cooperates with a server to provide functionality to a user; [0007] lines 1-6, obtaining, with one or more processors, a multi-container application, the multi-container application comprising: a composition file identifying a plurality of container images (as include software container image) configured to provide respective services of the multi-container application upon deployment and execution in a respective container of the multi-container application; [0047] lines 1-7, may provide operating-system-level virtualization to form multiple isolated user-space instances that appear to an application executing within the respective instances as if the respective instance is an independent computing device. In some embodiments, applications executing within one user-space instance may be prevented from accessing memory (as trusted computation) allocated to another user-space instance; also see [0050] and [0089]).
(BHANDARI, Fig. 3, Virtual machine 123 edit setting, 134 specify GPU requirements, video memory, RAM requirement; [0011] lines 3-4, cloud-based or on premise computing environments; [0027] lines 6-11, the administrator can specify CPU requirements, memory requirements, or other settings for a virtual machine which, if the resources are available in a host in a computing system 106, will be assigned to the host for execution; [0054] lines 1-5, identify a host having the requested video frame buffer memory which can be specified by administrator in the configuration of a virtual machine. For instance, the GVPM 140 can identify a GPU 121 of a host having an available video frame buffer memory that is equal to or greater than a required video frame buffer memory specified in the configuration of a virtual machine (as software enclave) (as causing a first portion of memory of a particular server of the cloud computing environment (i.e., a host of the cloud that having available memory resource) to be configured for use by the software enclave (i.e., used by the VM), wherein the size of the first portion of memory is based at least in part on the memory requirement); also see Fig. 9B).
segregate a first subset of the portion of memory for a first child isolated run-time environment of the compute instance, wherein direct network communications with any other endpoints outside the virtualization host are prohibited from the first child isolated run-time environment, and
(BHANDARI, Fig. 3, Virtual machine 123 edit setting, 134 specify GPU requirements, video memory, RAM requirement; [0054] lines 1-5, identify a host having the requested video frame buffer memory which can be specified by administrator in the configuration of a virtual machine. For instance, the GVPM 140 can identify a GPU 121 of a host having an available video frame buffer memory that is equal to or greater than a required video frame buffer memory specified in the configuration of a virtual machine)
wherein the first subset of the portion of memory is inaccessible from programs running outside the first child isolated run-time environment;
(Sood, Fig. 1, 112 physical memory, 110 protected region, Enclave (as first portion of memory); Fig. 6, 604 Trusted sensitive VNF (VM, container), 605 Trusted packet processing enclave (as virtual machine that comprises the software enclave); Fig. 17, 1700 NVFI platform, 604-1 Trusted sensitive VNF (VM, container) Trusted Domain 1, 604-2 Trusted sensitive VNF (VM, container) Trusted Domain 2, 604-3 Trusted sensitive VNF (VM, container) Trusted Domain 3; each Trusted Domain/VM including different TPP enclaves 604-1 (as software enclave); [0034] lines 1-5, An enclave is a protected area in the application's address space (see FIG. 1), which provides confidentiality and integrity even in the presence of privileged malware. Accesses to the enclave memory area from any software not resident in the enclave are prevented; [0037] lines 1-5, Once the application's code and data is loaded into an enclave, it is protected against all external software access. Each enclave has its own code and data for which the SGX programming environment provides confidentiality and integrity; [0071] Software components that are show external to secure enclave 606 are run in a non-protected region of the platform's user space (e.g., in the conventional manner employed for user applications). These software components include an INTEL® Data Plane Development Kit (DPDK) library 620, including a receiver (Rx) queue 622 and a transmit (Tx) queue 624, and a message queue-buffer 626 (as process of virtual machine); [0075] an entity external to a secure enclave cannot access data within a secure enclave, but software running in a secure enclave can access data external to the secure enclave. In this instance, the packet processing performed in secure enclave 605 implements a pull model under which a software entity (not specifically shown) in enclave 604 pulls packets from message queue/buffer 626; [0137] A security goal of the Infrastructure providers is to ensure that the Tenant VNFs/VNFCs and Tenant traffic is not violating the NFVI established security policies, nor causing any malware proliferation into the NFVI or into other Tenants' assets. A Tenant's administrative domain is confine to the Tenant's VNFs/VNFCs (as a user that has administrator privileges with respect to the virtual machine) and Tenant network; [0154] lines 1-4, Platform 1700 further shows three trusted sensitive VNFs 604-1, 604-2, and 604-3, each being part of separate trust domains 1, 2, and 3, that are resident in memory 1706. The trusted sensitive VNFs are used by tenants that deploy their applications on NVFI compute resource; [0155] lines 1-7, Each trust domain provides a secure execution environment in which software and data contained in the TPP enclaves of the trusted sensitive VNFs cannot be accessed by any other tenant (as data stored in the first portion of memory reserved for the software enclave of the virtual machine, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave) i.e., tenant’s administrative privileges, see Fig. 17, different tenant trusted domain corresponding to different VMs). Moreover, the NVFI provider/administrator cannot access any of the memory in the TPP enclaves; [0164] lines 1-10, creating at least one secure enclave in system memory of a compute platform configured to support a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave; also see Abstract, a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave, and software code in a secure enclave can access code and data both within the secure enclave and external to the secure enclave. Software code for implementing packet processing operations is installed in the secure enclaves. The software in the secure enclaves is then executed to perform the packet processing operations. Various configurations of secure enclaves and software code may be implemented, including configurations supporting service chains both within a VM or contain or across multiple VMs or containers, as well a parallel packet processing operations;)
(Baldwin, Fig. 12, VM 124, 135 Key; [0072] lines 1-2, At the heart of the key-manager back end 122 is the database 135 containing keys, policies and the identity of the service to which they link (as unencrypted security artifact); Claim 6, lines 4-7, hold the key in unencrypted form only while actively providing the secure service, and store a copy of the key in protected storage provided by the trusted-device functionality; [0092] lines 1-4, A trusted computing platform provides for trustable platform integrity measurement and reporting, and to this end has a plurality of shielded locations, that is, places (memory, registers, etc.) where it is safe to operate on sensitive data)).
establish a communication intermediary process within the compute instance for interactions with the first child isolated run-time environment;
cause an attestation of a configuration of the first child isolated run-time environment to be initiated by a security manager established at a virtualization management component of the virtualization host that is external to the compute instance;
provide via the communication intermediary process, to one or more destinations, (a) a result of the attestation and (b) an indication of an identity of the security manager;
determine that the result of the attestation has been accepted;
obtain, at the first child isolated run-time environment of the compute instance, an encrypted security artifact transferred from an established encrypted channel via the communication intermediary process, wherein decryption of the security artifact requires a key that is inaccessible to (a) the communication intermediary process established within the compute instance and (b) other programs running at the compute instance; and
perform, at the first child isolated run-time environment, one or more computations using the security artifact and the first subset of the portion of memory.
(Joshi, [0007] lines 1-6, obtaining, with one or more processors, a multi-container application, the multi-container application comprising: a composition file identifying a plurality of container images (as include software container image) configured to provide respective services of the multi-container application upon deployment and execution in a respective container of the multi-container application).
Although the claims at issue are not identical, they are not patentably distinct from each other because the Patent‘214’ is narrower than the instant application. The claim 1 of the Patent‘214’ is directed to “a system” whereas the claim 21 of the instant application is directed to “a computer-implemented method”. The difference in the statutory class of invention between the two claims are merely obvious variant of one another where the invention defined in the claims of U. S. Patent ‘214’ could readily be practiced or embodied in as a computer-implemented method. Therefore, it would have been obvious to one of ordinary skill in the art before the invention was made to modify claim 1 of the patent’214’ to be practiced as a computer-implemented method. The one having ordinary skill in the art would have been motivated to modify the patent’214’’s claim for the simple purpose of carrying out or implementing the computer instructions recited therein as a series of method steps on a computer.
In addition, the Patent‘214’’s narrower scope merely specifies that “segregate a first subset of the portion of memory for a first child isolated run-time environment” and “wherein the first subset of the portion of memory is inaccessible from programs running outside the first child isolated run-time environment” in claim 1 which have the same meaning as compare to “causing a first portion of memory of a virtual machine to be configured for private use by the software enclave” and “wherein after the first portion of memory is configured for private use by the software enclave, data stored in the first portion of memory reserved for the software enclave of the virtual machine cannot be accessed” of claim 21 in the instant application. That is, the term of “segregate a first subset of the portion of memory for a first child isolated run-time environment” of claim 1 in the patent’214’ is for allocation a portion of the memory for the first child isolated run-time environment which is the same thing as compare to “causing a first portion of memory of a virtual machine to be configured for private use by the software enclave” of the instant application. The term of “first portion of memory of a virtual machine” of instant application is same thing as compare to the “a portion of memory of the virtualization host is allocated to the compute instance” as cited in the patent ‘214’, because they are all refers to the virtual machine instance. The term of “first child isolated run-time environment” and “the software enclave” are just different name and they are used for performing a trusted computation. (see “wherein the first subset of the portion of memory is inaccessible from programs running outside the first child isolated run-time environment” of claim 1 in the patent ‘214’ and “wherein after the first portion of memory is configured for private use by the software enclave, data stored in the first portion of memory reserved for the software enclave cannot be accessed from processes” of claim 21 in the instant application).
Moreover, the Patent’214’ does not explicitly claim:
obtaining, at a cloud computing environment via one or more programmatic interfaces, an indication of (a) a software container image to be utilized to perform a trusted computation using a software enclave at a server of the cloud computing environment, and (b) a memory requirement of the software enclave;
the first portion of memory of the virtual machine is from/of a particular server of the cloud computing environment,
wherein a size of the first portion of memory is based at least in part on the memory requirement,
the data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave; and
causing the trusted computation to be performed using the first portion of memory and the software container image.
However, Traut teaches receiving, via one or more programmatic interfaces, an indication of (a) a child partition to be utilized to perform a trusted computation using a software enclave at a computer and (b) a resource requirement of the software enclave (Traut, Fig. 6, 605 Child Partition 2A, 606 Child partition 1B (as software enclave, second level of parent partition); Abstract, lines 1-2, Hierarchical virtualization is disclosed, where such virtualization can be accomplished with a multi-level mechanism; [0002] lines 1-3, The present disclosure generally relates to the field computing. More specifically, it relates to computer virtualization; [0059] lines 3-5, the hypervisor API library 806 exposes the hypervisor API to higher-level components, allowing them to call the hypervisor; [0063] lines 2-11, allows user-level components to create, delete, and manage partitions and specify partition-wide resources (as resource requirement) and quotas, defining scheduling and access control policies. For example, the creation of a new partition might be implemented by first making a hypercall to a module within the hypervisor (as the module receiving an indication via the hypervisor API for crating different partitions (multi-level partitions) with associated the resource requirement); [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure (as child partition 605 to be utilized to perform a trusted computation using the software enclave (i.e., parent partition/second level child partition); also see example of a partition from Fig. 2B, 208 partition that executing APPs 216 and 218 (as trusted computation));
causing the trusted computation to be performed using the first portion of memory and the child partition (Traut, Fig. 2B, 208 partition that executing APPs 216 and 218 (as trusted computation); [0041] lines 3-6, portion of the memory of the child partition A 406 is not accessible (as data is not accessed) 414 by the parent partition 404. Thus, the parent partition 404 cannot access the resources of the child partition A 406; see example of the applications that is running in partition: [0028] lines 1-10, Referring again to FIG. 2A, above the host OS 204 are two partitions…Within each partition 208 and 210 are guest operating systems (guest OSs) A 212 and B 214, respectively. Running on top of guest OS A 212 are two applications, application A1 216 and application A2 218, and running on top of guest OS B 214 is application B1 220. [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure; [Examiner noted: the application/processes are running within the child partition that is secure (i.e., trusted computation) using the assigned portion of the memory]; also see [0051] line 5, memory usage).
It would have been obvious to one having ordinary skill in the art before the invention was made to modify the claim 1 of the patent’214’ by including the step of obtaining the request/indication for utilizing the child petition with requested resources for performing the trusted computation as taught by Traut. One of ordinary skilled would have been motivated to modify claim of patent’214’ in the manner described above for the purpose of clarifying that the isolated environment is utilized based on the received request with the resource requirement in order to perform the trusted application within the isolated environment in order to improve the system efficiency.
Both patent’214’ and Traut fail to specifically teach when receiving via one or more programmatic interfaces, an indication of a child partition to be utilized at a computer, it is obtaining, at a cloud computing environment, an indication of (a) a software container image to be utilized at a server of the cloud computing environment, and when performing the trusted computation, it is using the software container image.
However, Joshi teaches obtaining, at a cloud computing environment, an indication of (a) a software container image to be utilized at a server of the cloud computing environment, and when performing the trusted computation, it is using the software container image (Joshi, Fig. 1, Cloud computing environment, 14 computing device (as server); 36 container (as software enclave); [0002] lines 1-6, Distributed applications are computer applications implemented across multiple hosts. The hosts may be a group of computers, virtual machines, or containers...Examples include client-server architectures, in which a client computer cooperates with a server to provide functionality to a user; [0007] lines 1-6, obtaining, with one or more processors, a multi-container application, the multi-container application comprising: a composition file identifying a plurality of container images (as include software container image) configured to provide respective services of the multi-container application upon deployment and execution in a respective container of the multi-container application; [0047] lines 1-7, may provide operating-system-level virtualization to form multiple isolated user-space instances that appear to an application executing within the respective instances as if the respective instance is an independent computing device. In some embodiments, applications executing within one user-space instance may be prevented from accessing memory (as trusted computation) allocated to another user-space instance; also see [0050] the containers 36 may execute application components 37 and [0089] computer system 1000 may include or be a combination of a cloud-computing system).
It would have been obvious to one having ordinary skill in the art before the invention was made to modify the claim of the patent’214’ and Traut by including the feature of obtaining the container images that to provide respective services of the multi-container application for execution in a respective container at the cloud computing environment as taught by Joshi. One of ordinary skilled would have been motivated to modify claim of patent’214’ and Traut in the manner described above for the purpose of clarifying that the obtained request is to initializing the secure containers at the cloud environment which preventing any potential malware attacks within the cloud and improving the system security.
Patent’214’, Traut and Joshi fail to specifically teach the resource requirement is a memory requirement of the software enclave, and the first portion of memory of the virtual machine is from/of a particular server of the cloud computing environment, wherein a size of the first portion of memory is based at least in part on the memory requirement.
However, BHANDARI teaches the resource requirement is a memory requirement of the software enclave, and the first portion of memory of the virtual machine is from/of a particular server of the cloud computing environment, wherein a size of the first portion of memory is based at least in part on the memory requirement (BHANDARI, Fig. 3, Virtual machine 123 edit setting, 134 specify GPU requirements, video memory, RAM requirement; [0011] lines 3-4, cloud-based or on premise computing environments; [0027] lines 6-11, the administrator can specify CPU requirements, memory requirements, or other settings for a virtual machine which, if the resources are available in a host in a computing system 106, will be assigned to the host for execution; [0054] lines 1-5, identify a host having the requested video frame buffer memory which can be specified by administrator in the configuration of a virtual machine. For instance, the GVPM 140 can identify a GPU 121 of a host having an available video frame buffer memory that is equal to or greater than a required video frame buffer memory specified in the configuration of a virtual machine (as software enclave) (as causing a first portion of memory of a particular server of the cloud computing environment (i.e., a host of the cloud that having available memory resource) to be configured for use by the software enclave (i.e., used by the VM), wherein the size of the first portion of memory is based at least in part on the memory requirement); also see Fig. 9B).
It would have been obvious to one having ordinary skill in the art before the invention was made to modify the claim of the patent’214’, Traut and Joshi by including the feature of providing the memory requitement of the virtual machine and identifying a particular host that having enough memory for assigning the virtual machine as taught by BHANDARI. One of ordinary skilled would have been motivated to modify claim of patent’214’, Traut and Joshi in the manner described above for the purpose of allowing the system to easily identifying a particular host/server that having enough resources based on the memory requirement specified from the user which improving the resource utilization and system efficiency.
Patent’214’, Traut, Joshi and BHANDARI fail to specifically teach the data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave.
However, Sood teaches the data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave (Sood, Fig. 1, 112 physical memory, 110 protected region, Enclave (as first portion of memory); Fig. 6, 604 Trusted sensitive VNF (VM, container), 605 Trusted packet processing enclave (as virtual machine that comprises the software enclave); Fig. 17, 1700 NVFI platform, 604-1 Trusted sensitive VNF (VM, container) Trusted Domain 1, 604-2 Trusted sensitive VNF (VM, container) Trusted Domain 2, 604-3 Trusted sensitive VNF (VM, container) Trusted Domain 3; each Trusted Domain/VM including different TPP enclaves 604-1 (as software enclave); [0034] lines 1-5, An enclave is a protected area in the application's address space (see FIG. 1), which provides confidentiality and integrity even in the presence of privileged malware. Accesses to the enclave memory area from any software not resident in the enclave are prevented; [0037] lines 1-5, Once the application's code and data is loaded into an enclave, it is protected against all external software access. Each enclave has its own code and data for which the SGX programming environment provides confidentiality and integrity; [0071] Software components that are show external to secure enclave 606 are run in a non-protected region of the platform's user space (e.g., in the conventional manner employed for user applications). These software components include an INTEL® Data Plane Development Kit (DPDK) library 620, including a receiver (Rx) queue 622 and a transmit (Tx) queue 624, and a message queue-buffer 626 (as process of virtual machine); [0075] an entity external to a secure enclave cannot access data within a secure enclave, but software running in a secure enclave can access data external to the secure enclave. In this instance, the packet processing performed in secure enclave 605 implements a pull model under which a software entity (not specifically shown) in enclave 604 pulls packets from message queue/buffer 626; [0137] A security goal of the Infrastructure providers is to ensure that the Tenant VNFs/VNFCs and Tenant traffic is not violating the NFVI established security policies, nor causing any malware proliferation into the NFVI or into other Tenants' assets. A Tenant's administrative domain is confine to the Tenant's VNFs/VNFCs (as a user that has administrator privileges with respect to the virtual machine) and Tenant network; [0154] lines 1-4, Platform 1700 further shows three trusted sensitive VNFs 604-1, 604-2, and 604-3, each being part of separate trust domains 1, 2, and 3, that are resident in memory 1706. The trusted sensitive VNFs are used by tenants that deploy their applications on NVFI compute resource; [0155] lines 1-7, Each trust domain provides a secure execution environment in which software and data contained in the TPP enclaves of the trusted sensitive VNFs cannot be accessed by any other tenant (as data stored in the first portion of memory reserved for the software enclave of the virtual machine, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave) i.e., tenant’s administrative privileges, see Fig. 17, different tenant trusted domain corresponding to different VMs). Moreover, the NVFI provider/administrator cannot access any of the memory in the TPP enclaves; [0164] lines 1-10, creating at least one secure enclave in system memory of a compute platform configured to support a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave; also see Abstract, a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave, and software code in a secure enclave can access code and data both within the secure enclave and external to the secure enclave. Software code for implementing packet processing operations is installed in the secure enclaves. The software in the secure enclaves is then executed to perform the packet processing operations. Various configurations of secure enclaves and software code may be implemented, including configurations supporting service chains both within a VM or contain or across multiple VMs or containers, as well a parallel packet processing operations).
It would have been obvious to one having ordinary skill in the art before the invention was made to modify the claim of the Patent’214’, Traut, Joshi and BHANDARI by including the feature of preventing the administrators/privileges to access the data in the protected portion of the memory as taught by Sood. One of ordinary skilled would have been motivated to modify claim of Patent’214’, Traut, Joshi and BHANDARI in the manner described above for the purpose of providing the data encryption and security which improving the overall system security and performance (see Sood, Abstract, “secure enclave” and [0131] “providing confidentiality of data and code”).
Patent’214’, Traut, Joshi, BHANDARI and Sood fail to specifically teach that the data stored in the first portion of memory, comprising at least an unencrypted security artifact.
However, Baldwin teaches the data stored in the first portion of memory, comprising at least an unencrypted security artifact (Baldwin, Fig. 12, VM 124, 135 Key; [0072] lines 1-2, At the heart of the key-manager back end 122 is the database 135 containing keys, policies and the identity of the service to which they link (as unencrypted security artifact); Claim 6, lines 4-7, hold the key in unencrypted form only while actively providing the secure service, and store a copy of the key in protected storage provided by the trusted-device functionality; [0092] lines 1-4, A trusted computing platform provides for trustable platform integrity measurement and reporting, and to this end has a plurality of shielded locations, that is, places (memory, registers, etc.) where it is safe to operate on sensitive data)).
It would have been obvious to one having ordinary skill in the art before the invention was made to modify the claim of the Patent’214’, Traut, Joshi, BHANDARI and Sood by including the feature of utilizing a shielded location for storing the unencrypted keys as taught by Baldwin. One of ordinary skilled would have been motivated to modify claim of Patent’214’, Traut, Joshi, BHANDARI and Sood in the manner described above for the purpose of protecting data against internal and external attacks as well as accidental leaks which improving the system security and performance (see Baldwin [0003] “protecting data against internal and external attacks as well as accidental leaks”).
Similar claims mappings of the remaining claims (i.e., 22-40 of the instant application with claims 2-20 of Patent’214’) would have been obvious to a person having ordinary skill in the art but have been omitted for the sake of brevity.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 23, 25, 30, 32, 37 and 39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 23 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1, Statutory Category: Yes, the claim 23 is a computer-implemented method that recites a series of steps and therefore falls in the statutory category of a process.
Step 2A- Prong 1: Judicial Exception Recited: Yes, the claim recites: “in response to determining that a software state of the software enclave satisfies a criterion” As drafted, the claim recites a method including step that could be performed in the human mind, but for the recitation of generic computing components. The human mind can easily judging/evaluating/determining whether a software state of the software enclave satisfies a criterion. Therefore, but for the recitation of generic computing components, these steps may be a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion).
Therefore, yes, the claims do recite judicial exceptions.
Step 2A- Prong 2: Integrated into a practical Application: No, this judicial exception is not integrated into a practical application. In this case, the claim 23 is depending on claim 21. And the claims 21 and 23 recites an additional limitations that “obtaining, at a cloud computing environment via one or more programmatic interfaces, an indication of (a) a software container image to be utilized to perform a trusted computation using a software enclave at a server of the cloud computing environment, and (b) a memory requirement of the software enclave” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)).” In addition, the limitation of “causing a first portion of memory of a virtual machine of a particular server of the cloud computing environment to be configured for private use by the software enclave, wherein a size of the first portion of memory is based at least in part on the memory requirement, and wherein after the first portion of memory of the particular server is configured for private use by the software enclave, data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave; and causing the trusted computation to be performed using the first portion of memory and the software container image” which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Further, the limitation of “establishing a secure channel for communication between the software enclave and one or more client programs” which is Applying the judicial exception with, or by use of, a particular machine (MPEP 2106.05(b)) and an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h))). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to the abstract idea.
Step 2B: Claim provides an Inventive Concept: No. The additional element “obtaining, at a cloud computing environment via one or more programmatic interfaces, an indication of (a) a software container image to be utilized to perform a trusted computation using a software enclave at a server of the cloud computing environment, and (b) a memory requirement of the software enclave” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)).” In addition, the limitation of “causing a first portion of memory of a virtual machine of a particular server of the cloud computing environment to be configured for private use by the software enclave, wherein a size of the first portion of memory is based at least in part on the memory requirement, and wherein after the first portion of memory of the particular server is configured for private use by the software enclave, data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave; and causing the trusted computation to be performed using the first portion of memory and the software container image” which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Further, the limitation of “establishing a secure channel for communication between the software enclave and one or more client programs” which is Applying the judicial exception with, or by use of, a particular machine (MPEP 2106.05(b)) and an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h))). And “obtaining” and “establishing” are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). These additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept in Step 2B.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Here, the “obtaining” step which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)), and “establishing” step was considered as Applying the judicial exception with, or by use of, a particular machine and an attempt to generally link the use of the judicial exception to a particular technological environment or field of use and thus it is re-evaluated in Step 2B to determine if it is more than what is well understood, routine, conventional activity in the field.
The “obtaining” step is for the purpose of “communication” and “transmitting the data” and these can be reached on one of court case (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) see MPEP § 2106.05(d) II). Accordingly, a conclusion that “obtain” and “transmission” are well understood, routine, conventional activity is supported under Berkheimer options 2.
Additionally, the establish step is for purpose of setting up the communications and this can be reached on one of publications (U.S patent application Eisenberg, Pub. 2003/0018535 A1). Eisenberg specifically indicated that establishing the communication link are well known to one of ordinary skill in the art (see Eisenberg [0028] the media 10 has instructions stored thereon for facilitating establishing the customer/host electronic communications link 20 between the customer computer 14 and a host computer 18. The customer/host electronic communications link 20, as well as a host/retailer electronic communications link 26 and the customer/retailer electronic communications link 28, may be effectuated via any of those methods which are well known to one of ordinary skill in the art which may utilize telephone, cable (Digital Subscriber Lines (DSL) and variations thereof, wire, optical, etc.), optical communications (including infrared), and wireless forms of communications, such as those based upon cellular, satellite, and radio frequency (RF), and other forms of electromagnetic wave based mediums). Accordingly, a conclusion that the establishing step is well understood, routine, conventional activity is supported under Berkheimer options 3.
For these reasons, there is no inventive concept in the claim, and thus the claim is ineligible.
With respect to the dependent claim 25, the claim elaborates that assigning, to the virtual machine launched at the particular server, a second portion of memory of the particular server prior to configuring the first portion of memory for private use by the software enclave, wherein the first portion of memory is a subset of the second portion (the claim 25 is depends on claim 21, for each limitations of claim 21, please refers to 101 rejection of claim 23 above. In addition, “assigning, to the virtual machine launched at the particular server, a second portion of memory…” as being treated as part of abstract idea and is analogues to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
Dependent claims 30 and 32 recite the same features as applied to claims 23 and 25 respectively above, therefore they are also rejected under the same rationale.
Dependent claims 37 and 39 recite the same features as applied to claims 23 and 25 respectively above, therefore they are also rejected under the same rationale.
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 21, 24-25, 28, 31-32, 35 and 38-39 are rejected under 35 U.S.C. 103 as being unpatentable over Traut (US. Pub. 2007/0050764 A1) in view of Joshi et al. (US Pub. 2018/0287883 A1) and further in view of BHANDARI et al. (US Pub. 2019/0102212 A1), Sood et al. (US Pub. 2018/0114012 A1) and Baldwin et al. (US Pub. 2010/0082991 A1).
Traut, Joshi, BHANDARI, Sood and Baldwin were cited in the previous Office Action.
As per claim 21, Traut teaches the invention substantially as claimed including A computer-implemented method, comprising:
receiving, via one or more programmatic interfaces, an indication of (a) a child partition to be utilized to perform a trusted computation using a software enclave at a computer and (b) a resource requirement of the software enclave (Traut, Fig. 6, 605 Child Partition 2A, 606 Child partition 1B (as software enclave, second level of parent partition); Abstract, lines 1-2, Hierarchical virtualization is disclosed, where such virtualization can be accomplished with a multi-level mechanism; [0002] lines 1-3, The present disclosure generally relates to the field computing. More specifically, it relates to computer virtualization; [0059] lines 3-5, the hypervisor API library 806 exposes the hypervisor API to higher-level components, allowing them to call the hypervisor; [0063] lines 2-11, allows user-level components to create, delete, and manage partitions and specify partition-wide resources (as resource requirement) and quotas, defining scheduling and access control policies. For example, the creation of a new partition might be implemented by first making a hypercall to a module within the hypervisor (as the module receiving an indication via the hypervisor API for crating different partitions (multi-level partitions) with associated the resource requirement); [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure (as child partition 605 to be utilized to perform a trusted computation using the software enclave (i.e., parent partition/second level child partition); also see example of a partition from Fig. 2B, 208 partition that executing APPs 216 and 218 (as trusted computation));
causing a first portion of memory of a virtual machine of the computer to be configured for private use by the software enclave, and wherein after the first portion of memory is configured for private use by the software enclave, the first portion of memory reserved for the software enclave of the virtual machine cannot be accessed by the virtual machine that comprises the software enclave (Traut, Fig. 4C, 403 Hardware (as include memory), 414 memory not controlled by parent partition; Fig. 6, multi-level administration, 604, 606, 605 and 607; [0003] lines 1-4, The notion of virtualization entails the virtualizing of computer hardware such that multiple operating systems, each of which may be contained in a separate partition, can run on a single piece of hardware; [0011] A child partition is created by the virtualization stack within the parent partition; [0047] lines 17-18, reallocate resources among the partitions they control; [0040] lines 10-14, the parent partition 404 may close the door on any tampering with the child partition A 406, since when the child partition A 406 becomes emancipated it cannot be hacked via the parent partition 404 (as private use and cannot be accessed); [0041] lines 3-6, portion of the memory of the child partition A 406 is not accessible (as data is not accessed) 414 by the parent partition 404. Thus, the parent partition 404 cannot access the resources of the child partition A 406; [0026] lines 9-12, The virtualization program 110 virtualizes a guest hardware architecture 108 (shown as dashed lines to illustrate the fact that this component is a partition or a "virtual machine") (as memory of the virtual machine); [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure; [0047] lines 1-18, One benefit of this type of hierarchical arrangement is that it supports multi-level administration of large machines. For example, a "machine administrator" can control the virtualization stack within a "root partition" (i.e. the top-most parent partition). This administrator can then create sub-partitions that have virtualization stacks of their own and assign each of these a set of machine resources (memory (as including first portion of the memory), processors, NICs, disk drives, and so on). This administrator can then allow other administrators (e.g. team-level administrators) to further partition the resources they were assigned. In such a scenario, the second-level virtualization stack is constrained to use the resources provided by the first-level (i.e. root-level) virtualization stack [Examiner noted: the first portion of memory of a virtual machine is to be configured for private use (i.e., secure use) only by the child partition/software enclave (Fig. 6, 606), and the first portion of memory cannot be accessed from the virtual machine/parent partition]); and
causing the trusted computation to be performed using the first portion of memory and the child partition (Traut, Fig. 2B, 208 partition that executing APPs 216 and 218 (as trusted computation); [0041] lines 3-6, portion of the memory of the child partition A 406 is not accessible 414 by the parent partition 404. Thus, the parent partition 404 cannot access the resources of the child partition A 406; see example of the applications that is running in partition: [0028] lines 1-10, Referring again to FIG. 2A, above the host OS 204 are two partitions…Within each partition 208 and 210 are guest operating systems (guest OSs) A 212 and B 214, respectively. Running on top of guest OS A 212 are two applications, application A1 216 and application A2 218, and running on top of guest OS B 214 is application B1 220. [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure; [Examiner noted: the application/processes are running within the child partition that is secure (i.e., trusted computation) using the assigned portion of the memory]; also see [0051] line 5, memory usage).
Traut fails to specifically teach when receiving via one or more programmatic interfaces, an indication of a child partition to be utilized at a computer, it is obtaining, at a cloud computing environment, an indication of (a) a software container image to be utilized at a server of the cloud computing environment, the computer is server and when performing the trusted computation, it is using the software container image.
However, Joshi teaches obtaining, at a cloud computing environment, an indication of (a) a software container image to be utilized at a server of the cloud computing environment, the computer is server and when performing the trusted computation, it is using the software container image (Joshi, Fig. 1, Cloud computing environment, 14 computing device (as server); 36 container (as software enclave); [0002] lines 1-6, Distributed applications are computer applications implemented across multiple hosts. The hosts may be a group of computers, virtual machines, or containers...Examples include client-server architectures, in which a client computer cooperates with a server to provide functionality to a user; [0007] lines 1-6, obtaining, with one or more processors, a multi-container application, the multi-container application comprising: a composition file identifying a plurality of container images (as include software container image) configured to provide respective services of the multi-container application upon deployment and execution in a respective container of the multi-container application; [0047] lines 1-7, may provide operating-system-level virtualization to form multiple isolated user-space instances that appear to an application executing within the respective instances as if the respective instance is an independent computing device. In some embodiments, applications executing within one user-space instance may be prevented from accessing memory (as trusted computation) allocated to another user-space instance; also see [0050] the containers 36 may execute application components 37 and [0089] computer system 1000 may include or be a combination of a cloud-computing system).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut with Joshi because Joshi’s teaching of obtaining the container images that to provide respective services of the multi-container application for execution in a respective container at the cloud computing environment would have provided Traut’s system with the advantage and capability to allow the system to initializing the secure containers at the cloud environment in order to prevent any potential malware attacks within the cloud which improving the system security.
Although Traut and Joshi teach the resource requitement of software enclave and the first portion of memory of a virtual machine of the computer to be configured for private use by the software enclave, Traut and Joshi fail to specifically teach the resource requirement is a memory requirement of the software enclave, and when causing a first portion of memory of a virtual machine of a computer to be configured for private use by the software enclave, the computer is a particular server of the cloud computing environment, wherein a size of the first portion of memory is based at least in part on the memory requirement.
However, BHANDARI teaches the resource requirement is a memory requirement of the software enclave, and when causing a first portion of memory of a virtual machine of a computer to be configured for private use by the software enclave, the computer is a particular server of the cloud computing environment, wherein a size of the first portion of memory is based at least in part on the memory requirement. (BHANDARI, Fig. 3, Virtual machine 123 edit setting, 134 specify GPU requirements, video memory, RAM requirement; [0011] lines 3-4, cloud-based or on premise computing environments; [0027] lines 6-11, the administrator can specify CPU requirements, memory requirements, or other settings for a virtual machine which, if the resources are available in a host in a computing system 106, will be assigned to the host for execution; [0054] lines 1-5, identify a host having the requested video frame buffer memory which can be specified by administrator in the configuration of a virtual machine. For instance, the GVPM 140 can identify a GPU 121 of a host having an available video frame buffer memory that is equal to or greater than a required video frame buffer memory specified in the configuration of a virtual machine (as software enclave) (as causing a first portion of memory of a particular server of the cloud computing environment (i.e., a host of the cloud that having available memory resource) to be configured for use by the software enclave (i.e., used by the VM), wherein the size of the first portion of memory is based at least in part on the memory requirement); also see Fig. 9B).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut and Joshi with BHANDARI because BHANDARI’s teaching of providing the memory requitement of the virtual machine and identifying a particular host that having enough memory for assigning the virtual machine would have provided Traut and Joshi’s system with the advantage and capability to easily identifying the host/server that with enough resources based on the memory requirement specified from the user which improving the resource utilization and system efficiency.
Although Traut, Joshi and BHANDARI teach the first portion of memory reserved for the software enclave of the virtual machine cannot be accessed by the virtual machine that comprises the software enclave, Traut, Joshi and BHANDARI fail to specifically teach that data stored in the first portion of memory reserved for the software enclave of the virtual machine, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave.
However, Sood teaches data stored in the first portion of memory reserved for the software enclave of the virtual machine, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave (Sood, Fig. 1, 112 physical memory, 110 protected region, Enclave (as first portion of memory); Fig. 6, 604 Trusted sensitive VNF (VM, container), 605 Trusted packet processing enclave (as virtual machine that comprises the software enclave); Fig. 17, 1700 NVFI platform, 604-1 Trusted sensitive VNF (VM, container) Trusted Domain 1, 604-2 Trusted sensitive VNF (VM, container) Trusted Domain 2, 604-3 Trusted sensitive VNF (VM, container) Trusted Domain 3; each Trusted Domain/VM including different TPP enclaves 604-1 (as software enclave); [0034] lines 1-5, An enclave is a protected area in the application's address space (see FIG. 1), which provides confidentiality and integrity even in the presence of privileged malware. Accesses to the enclave memory area from any software not resident in the enclave are prevented; [0037] lines 1-5, Once the application's code and data is loaded into an enclave, it is protected against all external software access. Each enclave has its own code and data for which the SGX programming environment provides confidentiality and integrity; [0071] Software components that are show external to secure enclave 606 are run in a non-protected region of the platform's user space (e.g., in the conventional manner employed for user applications). These software components include an INTEL® Data Plane Development Kit (DPDK) library 620, including a receiver (Rx) queue 622 and a transmit (Tx) queue 624, and a message queue-buffer 626 (as process of virtual machine); [0075] an entity external to a secure enclave cannot access data within a secure enclave, but software running in a secure enclave can access data external to the secure enclave. In this instance, the packet processing performed in secure enclave 605 implements a pull model under which a software entity (not specifically shown) in enclave 604 pulls packets from message queue/buffer 626; [0137] A security goal of the Infrastructure providers is to ensure that the Tenant VNFs/VNFCs and Tenant traffic is not violating the NFVI established security policies, nor causing any malware proliferation into the NFVI or into other Tenants' assets. A Tenant's administrative domain is confine to the Tenant's VNFs/VNFCs (as a user that has administrator privileges with respect to the virtual machine) and Tenant network; [0154] lines 1-4, Platform 1700 further shows three trusted sensitive VNFs 604-1, 604-2, and 604-3, each being part of separate trust domains 1, 2, and 3, that are resident in memory 1706. The trusted sensitive VNFs are used by tenants that deploy their applications on NVFI compute resource; [0155] lines 1-7, Each trust domain provides a secure execution environment in which software and data contained in the TPP enclaves of the trusted sensitive VNFs cannot be accessed by any other tenant (as data stored in the first portion of memory reserved for the software enclave of the virtual machine, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave) i.e., tenant’s administrative privileges, see Fig. 17, different tenant trusted domain corresponding to different VMs). Moreover, the NVFI provider/administrator cannot access any of the memory in the TPP enclaves; [0164] lines 1-10, creating at least one secure enclave in system memory of a compute platform configured to support a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave; also see Abstract, a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave, and software code in a secure enclave can access code and data both within the secure enclave and external to the secure enclave. Software code for implementing packet processing operations is installed in the secure enclaves. The software in the secure enclaves is then executed to perform the packet processing operations. Various configurations of secure enclaves and software code may be implemented, including configurations supporting service chains both within a VM or contain or across multiple VMs or containers, as well a parallel packet processing operations; [Examiner noted: the data stored in the protected memory of the enclave cannot be accessed by a user that has administrator privileges with respect to the virtual machine (i.e., including Tenant's administrative, see Fig. 17, 604-1, tenant trusted domain) within the same virtual machine as software enclave (i.e., see Abstract, software code in a secure enclave can access code and data both within the secure enclave and external to the secure enclave, but the secure enclave itself will preventing any access from external of secure enclave) and software processes are executed outside of any software enclave of the virtual machine, including the software enclave (i.e., see [0034] lines 1-5, Accesses to the enclave memory area from any software not resident in the enclave are prevented and [0155] lines 1-7, Each trust domain provides a secure execution environment in which software and data contained in the TPP enclaves of the trusted sensitive VNFs cannot be accessed by any other tenant).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut, Joshi and BHANDARI with Sood because Sood’s teaching of preventing tenant administrators/privileges (as different software processes running outside of software enclave) to access the data in the protected portion of the memory would have provided Traut, Joshi and BHANDARI’s system with the advantage and capability to providing the data encryption and security which improving the overall system security and performance (see Sood, Abstract, “secure enclave” and [0131] “providing confidentiality of data and code”).
Traut, Joshi, BHANDARI and Sood fail to specifically teach the data stored in the first portion of memory, comprising at least an unencrypted security artifact.
However, Baldwin teaches the data stored in the first portion of memory, comprising at least an unencrypted security artifact (Baldwin, Fig. 12, VM 124, 135 Key; [0072] lines 1-2, At the heart of the key-manager back end 122 is the database 135 containing keys, policies and the identity of the service to which they link (as unencrypted security artifact); Claim 6, lines 4-7, hold the key in unencrypted form only while actively providing the secure service, and store a copy of the key in protected storage provided by the trusted-device functionality; [0092] lines 1-4, A trusted computing platform provides for trustable platform integrity measurement and reporting, and to this end has a plurality of shielded locations, that is, places (memory, registers, etc.) where it is safe to operate on sensitive data)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut, Joshi, BHANDARI and Sood with Baldwin because Baldwin’s teaching of utilizing a shielded location for storing the unencrypted keys would have provided Traut, Joshi, BHANDARI and Sood’s system with the advantage and capability to protecting data against internal and external attacks as well as accidental leaks which improving the system security and performance (see Baldwin [0003] “protecting data against internal and external attacks as well as accidental leaks”).
As per claim 24, Traut, Joshi, BHANDARI, Sood and Baldwin teach the invention according to claim 21 above. Traut further teaches configuring the first portion of memory such that the data stored in the first portion of memory cannot be accessed from outside the software enclave (Traut, Fig. 6, multi-level administration, 604, 606, 605 and 607; [0011] lines 12-14, the child partition asks the parent partition for exclusive control of resources; [0041] lines 3-6, portion of the memory of the child partition A 406 is not accessible 414 by the parent partition 404. Thus, the parent partition 404 cannot access the resources of the child partition A 406; [0042] lines 1-4, the entire child partition B 408 is not accessible 414 by the parent partition 404, and therefore the parent partition 404 is fully distrusted, thereby making the child partition B 408 very secure (as cannot be accessed from outside the software enclave)).
As per claim 25, Traut, Joshi, BHANDARI, Sood and Baldwin teach the invention according to claim 21 above. Traut further teaches assigning, to the virtual machine launched at the computer, a second portion of memory of the particular server prior to configuring the first portion of memory for private use by the software enclave, wherein the first portion of memory is a subset of the second portion (Traut, Fig. 6, 608 parent partition (as virtual machine), 606 Child partition 1B (as software enclave); Abstract, lines 1-2, Hierarchical virtualization is disclosed, where such virtualization can be accomplished with a multi-level mechanism; [0026] line 11, component is a partition or a “virtual machine”; [0047] lines 1-18, One benefit of this type of hierarchical arrangement is that it supports multi-level administration of large machines. For example, a "machine administrator" can control the virtualization stack within a "root partition" (i.e. the top-most parent partition). This administrator can then create sub-partitions that have virtualization stacks of their own and assign each of these a set of machine resources (memory (as including assigning first portion of the memory), processors, NICs, disk drives, and so on). This administrator can then allow other administrators (e.g. team-level administrators) to further partition the resources they were assigned. In such a scenario, the second-level virtualization stack is constrained to use the resources (as first portion of memory is a subset of the second portion) provided by the first-level (i.e. root-level) virtualization stack [Examiner noted: the top-most parent partition (i.e., virtual machine) is launched and a second portion of memory is assigned to the virtual machine (see Fig. 2A), the first portion is from the second portion of the memory for next lower level partition (i.e., child partition)]). In addition, BHANDARI teaches virtual machine is launched at the particular server (BHANDARI, Fig. 3, Virtual machine 123 edit setting, 134 specify GPU requirements, video memory, RAM requirement; [0011] lines 3-4, cloud-based or on premise computing environments; [0027] lines 6-11, the administrator can specify CPU requirements, memory requirements, or other settings for a virtual machine which, if the resources are available in a host in a computing system 106, will be assigned to the host for execution; [0054] lines 1-5, identify a host having the requested video frame buffer memory which can be specified by administrator in the configuration of a virtual machine. For instance, the GVPM 140 can identify a GPU 121 of a host having an available video frame buffer memory that is equal to or greater than a required video frame buffer memory specified in the configuration of a virtual machine).
As per claim 28, it is a system claim of claim 21 above. Therefore, it is rejected for the same reason as claim 21 above. In addition, Traut further teaches one or more computing devices (Traut, [0002] lines 1-3, The present disclosure generally relates to the field computing. More specifically, it relates to computer virtualization); wherein the one or more computing devices include instructions that upon 10execution on or across the one or more processors of the computing devices (Traut, [0008] lines 1-2, many processors provide hardware support for one level of virtualization; Claim 15, lines 1-3, computer readable medium bearing computer executable instructions providing hierarchical virtualization).
As per claims 31-32, they are system claims of claims 24-25 respectively above. Therefore, they are rejected for the same reasons as claims 24-25 respectively above.
As per claim 35, it is one or more non-transitory computer-accessible storage media claim of claim 21 above. Therefore, it is rejected for the same reason as claim 21 above.
As per claims 38-39, they are one or more non-transitory computer-accessible storage media claims of claims 24-25 respectively above. Therefore, they are rejected for the same reasons as claims 24-25 respectively above.
Claims 22-23, 29-30 and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Traut, Joshi, BHANDARI, Sood and Baldwin, as applied to claims 21, 28 and 35 respectively above, and further in view of Tsirkin (US. Pub. 2019/0268318 A1).
Tsirkin was cited in the previous Office Action.
As per claim 22, Traut, Joshi, BHANDARI, Sood and Baldwin teach the invention according to claim 21 above. Traut, Joshi, BHANDARI, Sood and Baldwin fail to specifically teach providing, to a client of the cloud computing environment, a result of an attestation of software state of the software enclave.
However, Tsirkin teaches providing, to a client of the cloud computing environment, a result of an attestation of software state of the software enclave (Tsirkin, Fig. 3, 330 processing device, 352 validation component, 354 Attestation module; [0051] lines 1-4, Attestation module 354 can perform a first validation process to prove to the guest owner of the VM 350 that the VM 350 may be securely launched with encrypted virtualization features enabled…attestation module 354 can obtain a measurement representative of a state of the VM 350. The measurement may be a hash of contents of a memory of the VM 350 (e.g., a guest memory of the VM 350 as described in connection with FIG. 2). Attestation module 354 can then transmit the measurement to hypervisor 340 for transmission to the guest owner (as provide to client with measurement (as result of attestation, i.e., state of VM)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut, Joshi, BHANDARI, Sood and Baldwin with Tsirkin because Tsirkin’s teaching of ensuring and verifying the security of the virtual machine for the user would have provided Traut, Joshi, BHANDARI, Sood and Baldwin’s system with the advantage and capability to improve the system security and ensuring the privacy for the users.
As per claim 23, Traut, Joshi, BHANDARI, Sood and Baldwin teach the invention according to claim 21 above. Traut, Joshi, BHANDARI, Sood and Baldwin fail to specifically teach in response to determining that a software state of the software enclave satisfies a criterion, establishing a secure channel for communication between the software enclave and one or more client programs.
However, Tsirkin teaches in response to determining that a software state of the software enclave satisfies a criterion, establishing a secure channel for communication between the software enclave and one or more client programs (Tsirkin, Fig. 3, 354 Attestation module; [0051] lines 1-4, Attestation module 354 can perform a first validation process to prove to the guest owner of the VM 350 that the VM 350 may be securely launched with encrypted virtualization features enabled…attestation module 354 can obtain a measurement representative of a state of the VM 350. The measurement may be a hash of contents of a memory of the VM 350 (e.g., a guest memory of the VM 350 as described in connection with FIG. 2). Attestation module 354 can then transmit the measurement to hypervisor 340 for transmission to the guest owner; [0014] lines 1-6, Upon receiving the measurement, the guest owner can determine whether the measurement is valid; [0015] lines 5-13, the hypervisor may receive, from the guest owner, a message indicating that the measurement is valid and/or that the virtual machine is authenticated by the guest owner. The hypervisor can pass the message to the virtual machine. The virtual machine can receive secret data associated with the virtual machine. The secret data may be encrypted data that can be used for booting and/or executing the virtual machine on the host machine. In one implementation, the virtual machine can receive the secret data from the guest owner over a secure networking channel (as the secure channel for communication is established for transmitting the secret data for execution); also see [0024] lines 2-6, Users can interact with applications executing on the VMs 111, 112, 121, 122 using client computer systems (as include client program)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut, Joshi, BHANDARI, Sood and Baldwin with Tsirkin because Tsirkin’s teaching of ensuring and verifying the security of the virtual machine and only allowing secured virtual machine to perform the operation for the user would have provided Traut, Joshi, BHANDARI, Sood and Baldwin’s system with the advantage and capability to improve the system security and ensuring the privacy for the users.
As per claims 29-30, they are system claims of claims 22-23 respectively above. Therefore, they are rejected for the same reasons as claims 22-23 respectively above.
As per claims 36-37, they are one or more non-transitory computer-accessible storage media claims of claims 22-23 respectively above. Therefore, they are rejected for the same reasons as claims 22-23 respectively above.
Claims 26, 33 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Traut, Joshi, BHANDARI, Sood and Baldwin, as applied to claims 21, 28 and 35 respectively above, and further in view of Cropper et al. (US Pub. 2017/0109187 A1).
Cropper was cited in the previous Office Action.
As per claim 26, Traut, Joshi, BHANDARI, Sood and Baldwin teach the invention according to claim 21 above. BHANDARI further teaches causing the software enclave to be migrated to another server (BHANDARI, [0072] an application accessible by an administrator can query the GVPM 140 to determine if any resources are underutilized. If so, an administrator can initiate a request to perform an optimization that includes migrating virtual machines to provide a better allocation of resources; [0073] migrate the virtual machine from one host to another; also see Fig. 9D).
Traut, Joshi, BHANDARI, Sood and Baldwin fail to specifically teach wherein at the other server, a size of a second portion of memory configured for private use by the software enclave differs from a size of the first portion.
However, Cropper teaches wherein at the other server, a size of a second portion of memory configured for private use by the software enclave differs from a size of the first portion (Cropper, Fig. 8, 406, move VM to HA host group, 414 change VM resource allocation; [0076] lines 10-20, a virtual machine management action may increase a VIOS attribute for a virtual machine such that functionality that places virtual machines on hosts will later detect that the virtual machine needs to be migrated to another host that meets the new value for the VIOS attribute. As another example, a resource allocation for a virtual machine may be changed, e.g., to resize a virtual machine's resource allocation (as differs from a size of the first portion) to a "maximum" size for the virtual machine, which may result in a subsequent rebalancing of workloads on different hosts and the migration of one or more virtual machines; also see [0070] perform one or more virtual machine management actions; Please notes: memory for private use by the software enclave was taught by Traut).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut, Joshi, BHANDARI, Sood and Baldwin with Cropper because Cropper’s teaching of resizing the resource allocation for the virtual machine when migration would have provided Traut, Joshi, BHANDARI, Sood and Baldwin’s system with the advantage and capability to provide the workload balancing which improving the system performance and efficiency (see Cropper, [0076]).
As per claim 33, it is a system claim of claim 26 above. Therefore, it is rejected for the same reason as claim 26 above.
As per claim 40, it is one or more non-transitory computer-accessible storage media claim of claim 26 above. Therefore, it is rejected for the same reason as claim 26 above.
Claims 27 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Traut, Joshi, BHANDARI, Sood and Baldwin, as applied to claims 21 and 28 respectively above, and further in view of Stickle (US Pub. 2014/0258506 A1).
Stickle was cited in the previous Office Action.
As per claim 27, Traut, Joshi, BHANDARI, Sood and Baldwin teach the invention according to claim 21 above. Joshi further teaches one or more performance metrics collected from the software enclave (Joshi, Fig. 1, 40 agent , 37 application component, 36 container (as software enclave); [0050] some of the agents 40 may monitor the computing device 14, for instance, gathering metrics about CPU usage, memory usage, bandwidth usage, and the like. In some embodiments, some of the agents 40 may monitor corresponding ones of the application components (as performance metrics collected from application running in the software enclave)).
Traut, Joshi, BHANDARI, Sood and Baldwin fail to specifically teach providing, via the one or more programmatic interfaces, one or more performance metrics.
However, Stickle teaches providing, via the one or more programmatic interfaces, one or more performance metrics (Stickle, Fig. 1, 114 machine instances; [0019] lines 1-2, A machine instance 114 represents a virtual machine; [0037] lines 1-8, an application 117 executed by a machine instance 114 in association with a storage volume 115 in the computing environment 103 can be configured to report its usage via a usage report 147 generated by the usage API 129 to the application usage service 141. In some embodiments, the application 117 can be instrumented to report its usage via the usage API 129 (as providing, via the one or more programmatic interfaces, one or more performance metrics (i.e., usage)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Traut, Joshi, BHANDARI, Sood and Baldwin with Stickle because Stickle’s teaching of providing the usage data/metrics via the API would have provided Traut, Joshi, BHANDARI, Sood and Baldwin’s system with the advantage and capability to allow the system to easily determining the load/traffic spikes in order to creating/terminating the virtual machine based on the determined load which improving the system resource utilization (see Stickle, [0013] machine instances may be created and/or terminated in rapid fashion or on an on-demand basis).
As per claim 34, it is a system claim of claim 27 above. Therefore, it is rejected for the same reason as claim 27 above.
Response to Arguments
In the remark applicant’s argue in substance:
(a), The cited references fail to teach or suggest "data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave," as recited in amended claim 21.
(b), Sood's description of "entities" that are required to ensure that their "policies" and "its execution if protected from unauthorized access" including "system/network/security administrators" fails to teach or suggest that data stored in the first portion of memory reserved for the software enclave of the virtual machine of the particular server, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave, as recited by amended claim 21.
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), examiner would like to point out that Sood clearly teaches “data stored in the first portion of memory reserved for the software enclave of the virtual machine, comprising at least an unencrypted security artifact, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave”.
For example, Sood teaches a system that having a trusted sensitive VNF/virtual machine that having a trusted packet processing enclave, and the data stored in the memory that reserved/allocated for that trusted packet processing enclave cannot be accessed by any process outside of the trusted packet processing enclave, even with the user having administrator privileges with the trusted sensitive VNF/virtual machine (see Sood, Fig. 1, 112 physical memory, 110 protected region, Enclave (as first portion of memory); Fig. 6, 604 Trusted sensitive VNF (VM, container), 605 Trusted packet processing enclave (as virtual machine that comprises the software enclave); Fig. 17, 1700 NVFI platform, 604-1 Trusted sensitive VNF (VM, container) Trusted Domain 1, 604-2 Trusted sensitive VNF (VM, container) Trusted Domain 2, 604-3 Trusted sensitive VNF (VM, container) Trusted Domain 3; each Trusted Domain/VM including different TPP enclaves 604-1 (as software enclave); [0034] lines 1-5, An enclave is a protected area in the application's address space (see FIG. 1), which provides confidentiality and integrity even in the presence of privileged malware. Accesses to the enclave memory area from any software not resident in the enclave are prevented; [0037] lines 1-5, Once the application's code and data is loaded into an enclave, it is protected against all external software access. Each enclave has its own code and data for which the SGX programming environment provides confidentiality and integrity; [0071] Software components that are show external to secure enclave 606 are run in a non-protected region of the platform's user space (e.g., in the conventional manner employed for user applications). These software components include an INTEL® Data Plane Development Kit (DPDK) library 620, including a receiver (Rx) queue 622 and a transmit (Tx) queue 624, and a message queue-buffer 626 (as process of virtual machine); [0075] an entity external to a secure enclave cannot access data within a secure enclave, but software running in a secure enclave can access data external to the secure enclave. In this instance, the packet processing performed in secure enclave 605 implements a pull model under which a software entity (not specifically shown) in enclave 604 pulls packets from message queue/buffer 626; [0137] A security goal of the Infrastructure providers is to ensure that the Tenant VNFs/VNFCs and Tenant traffic is not violating the NFVI established security policies, nor causing any malware proliferation into the NFVI or into other Tenants' assets. A Tenant's administrative domain is confine to the Tenant's VNFs/VNFCs (as a user that has administrator privileges with respect to the virtual machine) and Tenant network; [0154] lines 1-4, Platform 1700 further shows three trusted sensitive VNFs 604-1, 604-2, and 604-3, each being part of separate trust domains 1, 2, and 3, that are resident in memory 1706. The trusted sensitive VNFs are used by tenants that deploy their applications on NVFI compute resource; [0155] lines 1-7, Each trust domain provides a secure execution environment in which software and data contained in the TPP enclaves of the trusted sensitive VNFs cannot be accessed by any other tenant (as data stored in the first portion of memory reserved for the software enclave of the virtual machine, cannot be accessed by a user that has administrator privileges with respect to the virtual machine that comprises the software enclave) i.e., tenant’s administrative privileges, see Fig. 17, different tenant trusted domain corresponding to different VMs). Moreover, the NVFI provider/administrator cannot access any of the memory in the TPP enclaves; [0164] lines 1-10, creating at least one secure enclave in system memory of a compute platform configured to support a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave; also see Abstract, a virtualized execution environment including a plurality of virtual machines (VMs) or containers, each secure enclave occupying a respective protected portion of the system memory, wherein software code external from a secure enclave cannot access code or data within a secure enclave, and software code in a secure enclave can access code and data both within the secure enclave and external to the secure enclave. Software code for implementing packet processing operations is installed in the secure enclaves. The software in the secure enclaves is then executed to perform the packet processing operations. Various configurations of secure enclaves and software code may be implemented, including configurations supporting service chains both within a VM or contain or across multiple VMs or containers, as well a parallel packet processing operations; [Examiner noted: the data stored in the protected memory of the enclave cannot be accessed by a user that has administrator privileges with respect to the virtual machine (i.e., including Tenant's administrative, see Fig. 17, 604-1, tenant trusted domain) within the same virtual machine as software enclave (i.e., see Abstract, software code in a secure enclave can access code and data both within the secure enclave and external to the secure enclave, but the secure enclave itself will preventing any access from external of secure enclave) and software processes are executed outside of any software enclave of the virtual machine, including the software enclave (i.e., see [0034] lines 1-5, Accesses to the enclave memory area from any software not resident in the enclave are prevented and [0155] lines 1-7, Each trust domain provides a secure execution environment in which software and data contained in the TPP enclaves of the trusted sensitive VNFs cannot be accessed by any other tenant).
In addition, BHANDARI teaches virtual machine of the particular server (BHANDARI, Fig. 3, Virtual machine 123 edit setting, 134 specify GPU requirements, video memory, RAM requirement; [0011] lines 3-4, cloud-based or on premise computing environments; [0027] lines 6-11, the administrator can specify CPU requirements, memory requirements, or other settings for a virtual machine which, if the resources are available in a host in a computing system 106, will be assigned to the host for execution; [0054] lines 1-5, identify a host having the requested video frame buffer memory which can be specified by administrator in the configuration of a virtual machine. For instance, the GVPM 140 can identify a GPU 121 of a host having an available video frame buffer memory that is equal to or greater than a required video frame buffer memory specified in the configuration of a virtual machine (as software enclave) (as causing a first portion of memory of a particular server of the cloud computing environment (i.e., a host of the cloud that having available memory resource) to be configured for use by the software enclave (i.e., used by the VM), wherein the size of the first portion of memory is based at least in part on the memory requirement); also see Fig. 9B).
Further, Baldwin teaches the data stored in the first portion of memory, comprising at least an unencrypted security artifact (Baldwin, Fig. 12, VM 124, 135 Key; [0072] lines 1-2, At the heart of the key-manager back end 122 is the database 135 containing keys, policies and the identity of the service to which they link (as unencrypted security artifact); Claim 6, lines 4-7, hold the key in unencrypted form only while actively providing the secure service, and store a copy of the key in protected storage provided by the trusted-device functionality; [0092] lines 1-4, A trusted computing platform provides for trustable platform integrity measurement and reporting, and to this end has a plurality of shielded locations, that is, places (memory, registers, etc.) where it is safe to operate on sensitive data)).
Therefore, Applicant’s argument has not been found to be persuasive. Please refers to 103 rejection above.
As to point (b), please see point (a) above.
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
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, Aimee J Li can be reached at (571) 272-4169. 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.
/ZUJIA XU/Examiner, Art Unit 2195