DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
Claims 1-19 are under examination.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Applicant’s claim to foreign priority to the following foreign application has been
acknowledged by the examiner: 8/11/2023 (PCT/CN2023/112630)
Drawings
Figures 2 and 3 are objected to because they contain blurry and illegible text. Corrected replacement drawings are required.
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 13-17 are rejected under 35 U.S.C. § 101 under the 2019 PEG framework. The claim recites a judicial exception (an abstract idea falling within the “data analysis” groupings) that is not integrated into a practical application.
Step 1: Statutory Category. Claim 13 satisfies the statutory category requirement because it is directed to an apparatus under 35 U.S.C. § 101(a). The claim recites an apparatus performing a series of steps involving providing security resource data and receiving an application deployment unit.
Step 2A, Prong 1: Identification of Judicial Exception. Claim 13 recites a judicial exception within the abstract idea category. First, the claim recites data analysis and information processing: “provide security resource data” and “receive an application deployment unit” constitute mental processes of sending/receiving data and data manipulation that could be performed in the human mind.
Step 2A, Prong 2: Integration into a Practical Application. Claim 13 fails integration analysis. The claim does not recite any specific technological improvement to computer functionality. The claim merely states “application deployment unit” without describing its innovation or technological contribution, which is insufficient under Alice and Mayo. The preamble recites “memory”, “hardware-based security resources”, “processor”, and “machine-readable instructions” but these are generic computer implementation language; there is no claim to specialized hardware, FPGA, ASIC, or particular machine architecture. Per Alice, 573 U.S. at 221, merely implementing an abstract idea on a generic computer does not confer eligibility. The claim does not transform a tangible article into a different state or thing; data manipulation alone—providing data and receiving application data—is not transformation. Per Bilski, 561 U.S. at 618, and PEG p. 56, transformation requires a change in physical properties or state of a tangible article. The additional elements (processor, memory, scheduling node, hardware-based security resources, and machine-readable instructions) are routine, conventional steps in cybersecurity and application deployment and constitute insignificant extra-solution activity. Per PEG p. 56, field-of-use limitations do not suffice. The claim does not recite a specific technological problem solved; the specification describes a business problem (the need to incorporate hardware-based security resources to deploy application with security requirements) but not how the claimed method improves upon application deployment in a non-conventional manner.
Step 2B: Significantly More / WURC Analysis. The additional elements—processor, memory, scheduling node, hardware-based security resources, and machine-readable instructions—are all well-understood, routine, and conventional (WURC) in the field of cybersecurity and application deployment as of the priority date of August 11, 2023. Processors, memory, scheduling nodes, hardware-based security resources, and machine-readable instructions are standard, commercially available components. Hardware-based security resources are well-established techniques. The specification provides no factual evidence demonstrating that these elements, individually or in combination, represent a non-conventional or inventive approach. Under Berkheimer v. HP, Inc., 881 F.3d 1360 (Fed. Cir. 2018), the examiner would need to establish a factual record that these elements are not WURC, and no such record exists. Therefore, the claim fails Step 2B as well.
A similar analysis can be applied to dependent claims 14-17. Claims 14-17 further recite and describe data manipulation using updatable data, data compatibility, and data types that are routine and conventional, therefore they are directed to a judicial exception. The judicial exception is not integrated into a practical application and the claims do not recite additional elements that amount to significantly more than the judicial exception.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-5, 7, 10, 12-13, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hsu et al. (United States Patent 10,567,397), hereinafter Hsu.
Regarding claim 1, Hsu teaches A scheduler apparatus comprising memory circuitry, machine-readable instructions, and processor circuitry to execute the machine-readable instructions to (Hsu Col 3. Lines 34-49: “Security-based container scheduling system 200 has a processor 205 and a set of memory resources 210. A memory resource, as generally described herein, can include any number of volatile or non-volatile memory components capable of storing instructions that can be executed by a processor.”):
identify a plurality of worker nodes within a cluster, where each worker node comprises a hardware-based security resource (Hsu Col. 2 Lines 40-43: “A container scheduler scans metadata associated with nodes, such as for example, nodes that are part of a cluster of nodes, to select a node that has node security attributes listed in its metadata”),
receive a deployment request for an application deployment unit (Hsu Col. 4 Lines 41-48: “This is achieved by first having administrators (e.g., administrator 140 shown in FIG. 1) specify desired security requirements for a container in its container's image metadata, e.g., metadata 120 associated with container image 115 shown in FIG. 1 … When the administrator 140 sends a request to deploy container 105 in cluster 110”), wherein the deployment request includes a security requirement for a type of hardware-based security resource (Hsu Col. 2 Lines 14-18: “Security attributes associated with a node may include, for example, …whether the node has Trusted Platform Module (‘TPM’) hardware”);
select, based on the security requirement, a compatible worker node of the plurality of worker nodes, wherein the compatible worker node comprises the type of hardware-based security resource (Hsu Col. 4 Lines 47-52: “When the administrator 140 sends a request to deploy container 105 in cluster 110, the security-based container scheduling system 200 triggers its translation engine 220 to generate one or more node selectors from the container security attribute(s) specified in the container's image metadata.”); and
schedule the application deployment unit for execution on the compatible worker node (Hsu Col. 5 Lines 59-62: “The container is then scheduled for deployment in a selected node in the cluster of nodes (415). The selected node is one that has a node security attribute that matches the node selector associated with the container.”).
Hsu does not disclose all the above in the same embodiment, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the embodiments of Hsu since it is suggested by Hsu Col. 2 Lines 48-56: “It is appreciated that, in the following description, numerous specific details are set forth to provide a thorough understanding of the examples. However, it is appreciated that the examples may be practiced without limitation to these specific details. In other instances, well-known methods and structures may not be described in detail to avoid unnecessarily obscuring the description of the examples. Also, the examples may be used in combination with each other.” This motivation to combine the embodiments of Hsu applies to the dependent claims as well.
Claims 18 and 19 and are substantially similar to claim 1 and are rejected under the same rationale.
In addition, Hsu teaches claim 19’s a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the method of claim 18 (Hsu Col. 6 Lines 54-57: “Security-based container scheduling system 700 includes a processor 705 and a tangible, non-transitory computer-readable medium 710 storing instructions 715-730 that are executed by the processor 705.”).
Regarding claim 2, Hsu teaches The scheduler apparatus of claim 1, wherein the hardware-based security resource is a trusted execution environment (TEE) (Hsu Col. 2 Lines 14-18: “Security attributes associated with a node may include, for example, …whether the node has Trusted Platform Module (‘TPM’) hardware”).
Regarding claim 4, Hsu teaches The scheduler apparatus of claim 1, wherein the application deployment unit is at least one of:
a pod; and
a container (Hsu Col. 2 Lines 63-67: “A container, as generally described herein, refers to a running instance of an image, which may include an application, its dependencies, libraries, a file system, parameters and all the files required to run it.”).
Regarding claim 5, Hsu teaches The scheduler apparatus of claim 1, further comprising machine-readable instructions to receive worker node data from the plurality of worker nodes within the cluster (Hsu Col. 5 Lines 48-52: “The node may be a part of a cluster of nodes provisioned to host containers for an administrator. For each discovered node in the cluster, the discovery engine 315 generates a command to discover a node security attribute that is associated with the discovered node (405).”).
Regarding claim 7, Hsu teaches The scheduler apparatus of claim 5, further comprising machine-readable instructions to update the worker node data based on a change of the hardware-based security resource in each worker node (Hsu Col. 5 Lines 26-32: “The scheduler plug-in 325 checks whether a node has the available security resource before placing the container on the node. After the container has been created, the scheduler plug-in 325 then allocates the security resource to the container and removes the allocated security resource from the list of available security resources.”).
Regarding claim 10, Hsu teaches The scheduler apparatus of claim 1, further comprising machine-readable instructions to receive security resource data from the compatible worker node after scheduling of the application deployment unit (Hsu Col. 6 Lines 38-46: “If a specific security resource needs to be allocated to a container, the security-based container scheduling system 300 keeps track of security resources by monitoring their availability throughout container deployment (620). This monitoring is performed by resource tracker engine 330, which may keep a list of all available security resources. Scheduler plug-in 325 checks whether the selected node still has the available security resource before placing the container on the node.”).
Regarding claim 12, Hsu teaches The scheduler apparatus of claim 1, wherein a subset of the plurality of worker nodes comprise a plurality of hardware-based security resources (Hsu Col. 5 Lines 24-23: “A resource tracker engine 330 may also be used to track the availability of security resources for the nodes.”).
Regarding claim 13, Hsu teaches A worker apparatus within a cluster, the apparatus comprising memory circuitry, one or more hardware-based security resources, machine-readable instructions, and processor circuitry to execute the machine-readable instructions to (Hsu “a node refers to a computing device on a network, either a virtual or physical machine, such as a personal computer, a cell phone, a printer, or a server, among others.”):
provide security resource data for each of the one or more hardware-based security resources to a scheduling node (Hsu Col. 4 Lines 16-24: “RedFish can be used to discover whether secure boot or FIPS mode is enabled for a node, whether the node has TPM hardware, whether the node has a specific firmware version that contains hot security fixes, and so on. An OS command can be used to discover the OS and SSL/TLS versions of the node. It is appreciated that any number of security attributes may be discovered for a node, using these or other discovery commands or protocols.”); and
receive an application deployment unit for execution on a compatible hardware-based security resource of the one or more hardware-based security resources (Hsu Col. 2 Lines 45-47: “The container is then allocated to the selected node to ensure that its security requirements are maintained throughout its deployment.”).
Claim 16 is substantially similar to claim 2 and is rejected under the same rationale.
Claim 17 is substantially similar to claim 4 and is rejected under the same rationale.
Claims 3, 8, 11, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Tarkhanyan et al. (United States Patent Publication No. 2022/0094690), Tarkhanyan.
Regarding claim 3, Hsu teaches The scheduler apparatus of claim 2, but fails to explicitly teach wherein the cluster comprises a plurality of types of TEEs.
However, Tarkhanyan teaches wherein the cluster comprises a plurality of types of TEEs (Tarkhanyan ¶35: “TEEs 215 may include, but are not necessarily limited to, Software Guard Extensions (SGX) technology by Intel Corp., technology under the name or trademark of TrustZone by ARM, Ltd., technology under the name or trademark of SEV by Advanced Micro Devices, Inc., or a trusted virtual machine.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Tarkhanyan to include a plurality of types of TEEs to better meet a client’s needs (Tarkhanyan ¶22: “A dynamic compute multi-domain fabric established in accordance with one or more embodiments, can include heterogenous compute elements (or homogenous compute elements if called for) that meet ecosystem needs of secure compliance execution, such as a tenant's requirements and/or regulatory requirements.”)
Regarding claim 8, Hsu teaches The scheduler apparatus of claim 5, but fails to explicitly teach wherein further comprising machine-readable instructions to: receive cluster data, wherein the cluster data includes at least one of: an addition of a new worker node to the cluster; and a removal of an existing worker node from the cluster.
However, Tarkhanyan teaches wherein further comprising machine-readable instructions to: receive cluster data, wherein the cluster data includes at least one of:
an addition of a new worker node to the cluster; and a removal of an existing worker node from the cluster (Tarkhanyan ¶32: “a node cluster for a given domain may be removed from the trusted group of node clusters 130 and a new node cluster in that domain, or in another domain, may replace the removed node cluster.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Tarkhanyan to be able to modify the amount of nodes in a cluster to better meet dynamic needs (Tarkhanyan ¶32: “As the needs of workload 104 change during the execution time of the workload, the compute nodes designated within node cluster 118 and/or within node cluster 158 may be modified in response.”).
Regarding claim 11, Hsu teaches The scheduler apparatus of claim 10, but fails to explicitly teach further comprising machine-readable instructions to reschedule the application deployment unit for execution on a second compatible worker node of the plurality of worker nodes when the security resource data no longer satisfies the security requirement.
However, Tarkhanyan teaches further comprising machine-readable instructions to reschedule the application deployment unit for execution on a second compatible worker node of the plurality of worker nodes when the security resource data no longer satisfies the security requirement (Tarkhanyan ¶56: “orchestrator 114, can identify and allocate resources that are available in the initiating compute domain 110 and that satisfy the requirements of the WEP. For example, the WEP may include a requirements for three CPUs, one FPGA, one GPU, and one special-purpose ASIC. If orchestrator 114 determines that the initiating compute domain 110 cannot provide all of the resources specified in the request 220, then other compute domains that may have additional resources are identified (e.g., using a broadcast or other communication).”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Tarkhanyan to ensure execution requirements are met (Tarkhanyan ¶20: “Accordingly, the dynamic nature of the workload compute environment should be considered when assigning resources (e.g., XPUs). To ensure the integrity and confidentiality of such workloads, a dynamic compute boundary should meet trusted execution requirements and tenants (also referred to herein as ‘workload owners’) should be able to obtain an assurance for trustworthiness of the distributed and disaggregated compute fabric.”).
Regarding claim 14, Hsu teaches The worker apparatus of claim 13, but fails to explicitly teach further comprising machine-readable instructions to provide updated hardware-based security resource data for each of the hardware-based security resources.
However, Tarkhanyan teaches further comprising machine-readable instructions to provide updated hardware-based security resource data for each of the hardware-based security resources (Tarkhanyan ¶34: “governors 116 and 156 (also referred to herein as ‘monitoring engine’) may also be included to enable monitoring of the trusted group of node clusters, collecting telemetry data, and reporting the collected telemetry data and other information related to the workload execution.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Tarkhanyan to ensure execution requirements are met (Tarkhanyan ¶20: “Accordingly, the dynamic nature of the workload compute environment should be considered when assigning resources (e.g., XPUs). To ensure the integrity and confidentiality of such workloads, a dynamic compute boundary should meet trusted execution requirements and tenants (also referred to herein as ‘workload owners’) should be able to obtain an assurance for trustworthiness of the distributed and disaggregated compute fabric.”).
Regarding claim 15, Hsu teaches The worker apparatus of claim 13, further comprising machine-readable instructions to:
determine whether the application deployment unit can execute in the compatible hardware-based security resource (Hsu Col. 6 Lines 38-46: “If a specific security resource needs to be allocated to a container, the security-based container scheduling system 300 keeps track of security resources by monitoring their availability throughout container deployment (620). This monitoring is performed by resource tracker engine 330, which may keep a list of all available security resources. Scheduler plug-in 325 checks whether the selected node still has the available security resource before placing the container on the node.”); but fails to explicitly teach and notify the scheduling node when the application deployment unit cannot execute in the compatible hardware-based security resource.
However, Tarkhanyan teaches and notify the scheduling node (Tarkhanyan ¶149: “attestation data obtained for the nodes cluster is determined to indicate that the nodes collectively, as a node cluster, meet (e.g., comply with, satisfy, etc.) the relevant requirement(s)”) when the application deployment unit cannot execute in the compatible hardware-based security resource (Tarkhanyan ¶94: “if any one or more of the compute nodes in the edge node cluster or the cloud node cluster fail attestation, then a secure connected compute fabric is not established between the clusters”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Tarkhanyan to ensure execution requirements are met (Tarkhanyan ¶20: “Accordingly, the dynamic nature of the workload compute environment should be considered when assigning resources (e.g., XPUs). To ensure the integrity and confidentiality of such workloads, a dynamic compute boundary should meet trusted execution requirements and tenants (also referred to herein as ‘workload owners’) should be able to obtain an assurance for trustworthiness of the distributed and disaggregated compute fabric.”).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Murray (United States Patent Publication No. 2022/0263655).
Regarding claim 6, Hsu teaches The scheduler apparatus of claim 5, wherein worker node data includes the type of hardware-based security resource (Hsu Col. 2 Lines 14-18: “Security attributes associated with a node may include, for example, whether secure boot or a Federal Information Processing Standard (‘FIPS’) mode is enabled, whether the node has Trusted Platform Module (‘TPM’) hardware”), but fails to explicitly teach a trusted memory size, a number of devices, and a number of supported keys.
However, Murray teaches a trusted memory size (Murray ¶131: “there may be any number of storage hosts/nodes with any number of storage resources”), a number of devices (Murray ¶128: “These hosts or nodes may have storage resources of any kind per above discussion, local disks/partitions, SAN/NAS servers, RAID servers, PaaS storage systems, Cloud storages, Hadoop data nodes, specialized or self-encrypting disks/drives, to name a few.”), and a number of supported keys (Murray ¶132: “more than one KMS may be in charge of storing cryptographic keys which may be data keys or corresponding WKs per above teachings for storage resources on hosts/nodes”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Murray to avoid keeping a separate database for storing keys (Murray ¶15: “It is further an object of the invention to not require a separate database for storing key-metadata that could get out of sync with the KMS database.”).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Tarkhanyan in view of Zhao et al. (United States Patent Publication No. 2020/0358598), hereinafter Zhao.
Regarding claim 9, Hsu teaches The scheduler apparatus of claim 1, but fails to explicitly teach wherein the deployment request further includes a trusted memory size, a number of devices, and a number of supported keys.
However, Tarkhanyan teaches wherein the deployment request further includes a trusted memory size (Tarkhanyan ¶55: “The request may specify or otherwise indicate resources (e.g., compute, storage, networking, memory that are needed to host a particular workload 104.”), a number of devices (Tarkhanyan ¶25: “a given workload may require particular processing devices, performance criteria, security attributes, privacy attributes, regulatory requirements, and other parameters, or any combination thereof.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu in view of Tarkhanyan to ensure execution requirements are met (Tarkhanyan ¶20: “Accordingly, the dynamic nature of the workload compute environment should be considered when assigning resources (e.g., XPUs). To ensure the integrity and confidentiality of such workloads, a dynamic compute boundary should meet trusted execution requirements and tenants (also referred to herein as ‘workload owners’) should be able to obtain an assurance for trustworthiness of the distributed and disaggregated compute fabric.”).
Hsu and Tarkhanyan fail to explicitly teach wherein the deployment request further includes a number of supported keys.
However, Zhao teaches and a number of supported keys (Zhao ¶46: “the key request may include the source node (the source ONU) of the key request, the destination node (the destination ONU) of the key request, the quantity of secret-keys required”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hsu and Tarkhanyan in view of Zhao to provide keys in an efficient and flexible way (Zhao ¶7: “Examples of the present disclosure provide a method and a device of SKP for final users, to provide secret-keys for multiple final users in an efficient and flexible way”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sahasranamam et al. (United States Patent Publication No. 2022/0164229)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEC ANKRUM whose telephone number is (571)272-9209. The examiner can normally be reached M-F 7:15am-3:15pm.
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, Ali Shayanfar can be reached at 571-270-1050. 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.
/ALEC C ANKRUM/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
