DETAILED ACTION
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 .
Response to Amendment
This office action is in response to amendment/reconsideration filed on 02/26/2026, the amendment/reconsideration has been considered. Claims 1, 6, 8, 9, 11, 13, 14, 16, and 18-20 have been amended. Claims 1-20 are pending for examination as cited below.
Response to Arguments
Applicant’s arguments with respect to amended claim(s) have been considered but are moot in view of the new grounds of rejection necessitated by claim amendments.
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.
Claim(s) 1-6, 11-17 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bojjireddy et al. (Pub. No.: US 2019/0180006 A1), hereinafter “Boj” in view of Zhang et al. (Pub. No.: US 2022/0283846 A1), hereinafter “Zhang” and further in view of Filiz et al. (Pat. No.: US 11,392,422 B1), hereinafter “Filiz”.
As to claim 1. Boj discloses, a computer-implemented method for securely orchestrating containers in a container orchestration environment (Boj, Abstract), the method comprising:
providing a Node Agent for managing containers for running application workloads and a Secure Agent in a controller node of the container orchestration environment (Boj, [0021], The wrapper engine component's functionality is made available as a set of APIs (application programming interfaces)/SDKs (software development kits), or can be made available as a service on cloud to integrate with existing Dev-Ops process,);
restricting accesses to the containers using the Secure Agent (Boj, [0024], An example of such protected memory for executing code and maintaining associated data of that code comprises one or more Intel® Software Guard Extensions (SGX) enclaves. Other protection technologies that can be leveraged by the technology described herein include IBM Z® SSC (Secure Service Container).
Boj however is silent to discloses explicitly, using two API decorators comprising a Node Agent Decorator before the Node Agent, and a Runtime Decorator after the Node Agent;
forwarding node agent API requests to the Node Agent Decorator;
multiplexing, at the Node Agent Decorator, an aggregated orchestration request for the controller node;
multiplexing, at the Runtime Decorator an orchestration request for an associated container; and
restricting accesses to the containers using the Secure Agent.
Filiz discloses a similar concept in the same field of endeavor including, using two API decorators comprising a Node Agent Decorator before the Node Agent, and a Runtime Decorator after the Node Agent (Filiz, col.2, fig.5 network proxy 142B; node agent and 142C network interface; Filiz discloses, interposing network/management layers (network proxy, network interfaces, instance initializer, execution controller) that sit between the orchestration API and the runtime/node agent. These components act as wrappers/interceptors that perform mediation both before and after node-level components – functionally equivalent to the claimed “decorators”);
forwarding node agent API requests to the Node Agent Decorator based on a network address translation (NAT) rule (Filiz, col.2-3, fig.5 (network proxy 142B; network interface configuration; fig.6, task execution request processing routine, fig.7, network credential acquisition routine. Filiz discloses, attaching multiple network interface and configuring network interfaces/credentials so that orchestration /management traffic is routed through specific network paths e.g. network proxy and network interface for orchestration vs. management. That routing/attachment and the use of separate network interfaces is the disclosed mechanism for redirecting/forwarding orchestration traffic – functionally equivalent to forwarding bsed on NAT rules.).
multiplexing, at the Node Agent Decorator, an aggregated orchestration request for the controller node(Filiz, col.17-18, fig.5 “instance components including network proxy 142B, node agent 142C, logging agent 143A”; fig.6 “task execution request processing routine”. Filiz discloses, the network proxy/instance manager/initializer that mediate and coordinate multiple network interfaces and multiple client namespaces on an instance. The proxy/initializer aggregates and directs orchestration and management requests to the appropriate local agents “node agent, pod network namespace”, which is the functional equivalent of multiplexing node agent AI requests.);
transmitting the multiplexed node agent API requests from the Node Agent Decorator to the Secure Agent (Filiz, abstract, col.14, col.20, fig.1, fig.2, fig.6, see the flow where the orchestration service requests execution and the serverless management service receives and manages the request. Filiz further discloses, the container orchestration service generating a request that is submitted to the serverless container management service 140; the management service receives multiplexed/aggregated request and the execution controller 146 enforces policies and provisions compute. This is the transmission of mediated requests to the controller-side secure manager);
multiplexing, at the Runtime Decorator an orchestration request for an associated container (Filiz, col.2, the container runtime and network proxy that mediate runtime requests and the execution controller that receives runtime execution requests and enforces configuration and security. The runtime-side mediation (network proxy + runtime) that forwards requests to the serverless management service is the functional equivalent of the claimed runtime decorator. Also see fig.5, network proxy, container runtime 142D, pod 142E and fig.5, task execution request processing routine);
transmitting the multiplexed orchestration request from the Runtime Decorator to the Secure Agent (Filiz, abstract, col.14, col.20, fig.1, fig.2, fig.6, see the flow where the orchestration service requests execution and the serverless management service receives and manages the request. Filiz further discloses, the container orchestration service generating a request that is submitted to the serverless container management service 140; the management service receives multiplexed/aggregated request and the execution controller 146 enforces policies and provisions compute. This is the transmission of mediated requests to the controller-side secure manager).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art at the time of the invention to incorporate the teachings of “Filiz” into those of “Boj” to provide an executing a containerized application in a nested manner on two separate container orchestration services. For example, a user may submit a request to a container orchestration service to execute a containerized application, and in response, instead of identifying one of the existing compute instances belonging to the user and executing the containerized application on the identified compute instance, the container orchestration service may generate and submit a request to a serverless container management service that can not only acquire compute resources on behalf of the container orchestration service but also manage the compute resources such that the container orchestration service (or the original requesting user) does not need to manage scaling, monitoring, patching, and security of the compute resources.
As to claim 2. The combined system of Boj, and Filiz discloses the invention as in parent claim above including, wherein the containers comprise confidential containers running in a trusted execution environment (TEE) and standard containers running in a cluster in the container orchestration environment (Boj, [0039], Also shown in FIG. 4 is the running of the secured program code (block 448) on an exemplified Kubernetes cluster 450, as part of a cloud infrastructure 452 accessed via cloud management functionality 454 and .
As to claim 3. The combined system of Boj, and Filiz discloses the invention as in parent claim above including, using the Secure Agent to protect sensitive data and code of the containers, restricting access to containers without modifying containers, container runtimes, and platforms in the container orchestration environment (Boj, [0024]).
As to claim 4. The combined system of Boj, and Filiz discloses the invention as in parent claim above including, wherein the containers comprise unmodified confidential containers and the standard containers running in a cluster comprise Open Container Initiative (OCI) containers (Boj, [0021], to download application images, to pull curated apps, to submit unsecure code (to generate secure counterpart program code that will run in a protected memory area (an enclave)), and to convert an application to secure counterpart code that runs in an enclave when executed.).
As to claim 5. The combined system of Boj, and Filiz disclose the invention as in parent claim above including, wherein the Secure Agent uses a Trusted Execution Environment (TEE) contract signature verification process to provide access only to users with a signed contract (Boj, [0024]).
As to claim 6. The combined system of Boj, and Filiz disclose the invention as in parent claim above including, wherein the multiplexed node agent API requests are sent from the Node Agent Decorator and from the Runtime Decorator to the Secure Agent (Filiz, fig.5 and accompanying description, “instance 142 …container runtime 142D…pod 142E. Filiz discloses, a network proxy/network interface configuration and an instance initializer/node agent that interpose on network and orchestration flows. These components perform the functional role of a “runtime decorator” i.e. an interceptor/wrapper that multiplexes and forwards runtime/orchestration requests to the runtime.).
As to claims 11 is rejected for same rationale as applied to claim 1 above.
As to claims 12 is rejected for same rationale as applied to claim 3 above.
As to claims 13 is rejected for same rationale as applied to claim 9 above.
As to claims 14 is rejected for same rationale as applied to claim 6 above.
As to claims 15 is rejected for same rationale as applied to claim 8 above.
As to claims 16 is read in light of specification paragraph [0012], where application has excluded the transitory medium perse e.g. signals from the list of computer readable storage medium, and is rejected for same rationale as applied to claim 1 above.
As to claims 17 is rejected for same rationale as applied to claim 5 above.
As to claims 19 is rejected for same rationale as applied to claim 6 and 14 above.
Claim(s) 7-8 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Boj and Filiz” as applied above, in view of Dewan et al. (Pub. No.: US 2017/0180386 A1), hereinafter “Dewan”.
As to claim 7. The combined system of Boj, and Filiz disclose the invention as in parent claim above. Boj, and Filiz however are silent to disclose explicitly, wherein the Secure Agent uses a Trusted Execution Environment (TEE) contract signature verification process to verify a valid user for the received multiplexed node agent API requests.
Dewan discloses a similar concept in the same field of endeavor including, wherein the Secure Agent uses a Trusted Execution Environment (TEE) contract signature verification process to verify a valid user for the received multiplexed node agent API requests ([0118], wherein the trusted agent in secure communication with the TEE is provided from the host-based TEE, and wherein the host-based TEE is executed by an operating system.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art at the time of the invention to incorporate the teachings of “Dewan” into those of “Boj, and Filiz” to provide a secure transfer of data from computing device sensors to a Trusted Execution Environment (TEE) are disclosed. As disclosed, various data flows, data sequences, and configurations are provided to allow sensor data to maintain integrity and confidentiality while being accessed by trusted agents of a TEE.
As to claim 8. The combined system of Boj, Filiz and Dewan disclose the invention as in claim above including, wherein the Secure Agent sends the node agent API requests to a Container Runtime and associated container for secure execution responsive to verifying a valid user for the received multiplexed node agent API requests (Dewan, [0090], agents are responsible to verify the valid user account via security check.).
As to claims 20 is rejected for same rationale as applied to claims 8 above.
Claim(s) 9-10 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Boj and filiz as applied above in view of Evans et al. (Pub. No.: US 2023/0070125 A1), hereinafter “Evans”.
As to claim 9. The combined system of Boj, and Filiz disclose the invention as in parent claim above. Boj, and Filiz however are silent to disclose explicitly, wherein forwarding node agent API requests to the Node Agent Decorator comprises using a Network Address Translation (NAT) Table for identifying valid clients of the container orchestration environment.
Evans however discloses a similar concept in the same field of endeavor including, wherein forwarding node agent API requests to the Node Agent Decorator comprises using a Network Address Translation (NAT) Table for identifying valid clients of the container orchestration environment (Evans, [0001], PCI Express (PCIe) provides for Address Translation Services (ATS) where a host may use a translation agent to translate a virtual address, provided by an endpoint. As a further complication, the host may include multiple Virtual Machines (VMs) where an endpoint is part of a Trusted Execution Environment (TEE) of one VM and not the other.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art at the time of the invention to incorporate the teachings of “Evans” into those of “Boj, and Filiz” to provide system where, the host may incorporate the physical address and a signature of the physical address generated using a private key into a translated address field of a response to a translation request. An endpoint may treat the combination as a translated address by storing it in an entry of a translation cache, and accessing the entry for inclusion in a memory access request. The host may generate a signature of the translated address from the request using the private key, with the result being compared to the signature from the request.
As to claim 10. The combined system of Boj, Filiz and Evans disclose the invention as in parent claim above, further comprising a computer using Secure Container Orchestration (SCO) logic to implement operations to securely orchestrate containers in the container orchestration environment (Evans, [0001], As a further complication, the host may include multiple Virtual Machines (VMs) where an endpoint is part of a Trusted Execution Environment (TEE) of one VM and not the other.).
As to claims 18 is rejected for same rationale as applied to claim 9 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see the attached PTO-892.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAUQIR HUSSAIN whose telephone number is (571)270-1247. The examiner can normally be reached M-F 7:00 - 8:00 with IFP.
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, Brian J Gillis can be reached at 571 272-7952. 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.
/Tauqir Hussain/Primary Examiner, Art Unit 2446
Prosecution Insights