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, 8, 9, and 16 are amended.
Claims 1-20 are under examination.
Response to Arguments
Applicant’s remarks filed on 8/07/2026 have been fully considered.
Regarding Applicant’s remarks and amendments addressing the 112(b) rejection of claims 1-20, these have been considered and are persuasive. Thus, the 112(b) rejection has been withdrawn.
Regarding Applicant’s remarks on Magowan, Moorthi, and Chennamsetty failing to teach the amended features of claims 1, 9, and 16, these have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-3, 9-11, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Magowan et al. (US Patent Publication No. 2023/0068221 – provided by Applicant in IDS), hereinafter Magowan in view of Erlingsson et al. (United States Patent 11,973,784), hereinafter Erlingsson in view of Chennamsetty et al. (US Patent Publication No. 2016/0080478), hereinafter Chennamsetty.
Regarding claim 1, a method of securely deploying applications by a cloud service provider (Magowan ¶45: “Trusted execution environment 218 provides isolated and secure execution of a set of containers in a pod sandbox virtual machine corresponding to a service, which is provided by an application owner in a container orchestration environment, based on a set of rules contained in a trusted execution environment contract that corresponds to a pod deployment description for the set of containers.”), the method comprising:
creating, within cloud deployment of a tenant, a secure execution environment for an application (Magowan ¶45: “Trusted execution environment 218 provides isolated and secure execution of a set of containers in a pod sandbox virtual machine corresponding to a service, which is provided by an application owner in a container orchestration environment, based on a set of rules contained in a trusted execution environment contract that corresponds to a pod deployment description for the set of containers.”), [wherein the secure execution environment is managed by the cloud service provider];
deploying, within the secure execution environment, the application (Magowan ¶60: “an application owner can create a pod deployment description and give the pod deployment description to a container orchestration environment administrator to use and manage a cluster of host nodes for running containerized applications within the container orchestration environment.”), [wherein source code for the application is stored in the secure execution environment;]
and deploying an agent within the secure execution environment (Magowan ¶62: “embodiments launch a secure agent inside the trusted execution environment to process pod sandbox virtual machine semantics”), wherein the agent is configured to:
allow one or more conforming requests to access the application (Magowana ¶65: “The secure agent enforces the trusted execution environment contract within the trusted execution environment by validating or verifying any external orchestration request from the container runtime, container orchestration environment administrator, or any other source outside the trusted execution environment against rules included in the trusted execution environment contract. It should be noted that the orchestration request can include a sequence of commands to deploy or start an application workload.”);
block one or more [tenant-initiated management] operations for the secure execution environment (Magowan ¶96: “If the computer, using the secure agent, determines that the container runtime interface command to perform the orchestration action on the set of containers is invalid based not finding a matching rule in the trusted execution environment contract, no output of step 614, then the computer, using the secure agent, returns an error to the kubelet (step 616).”) [wherein the one or more blocked tenant-initiated management operations include an attempt, by the tenant that owns the cloud deployment, to obtain the source code for the application stored in the secure execution environment]; and
allow one or more [management] operations for the secure execution environment that are [initiated by the cloud service provider] (Magowan ¶96: “If the computer, using the secure agent, determines that the container runtime interface command to perform the orchestration action on the set of containers is valid based on finding a matching rule in the trusted execution environment contract, yes output of step 614, then the computer, using the secure agent, executes the container runtime interface command to perform the orchestration action on the set of containers comprising the application workload that corresponds to the service in the pod sandbox virtual machine of the trusted execution environment (step 618).”).
Magowan fails to explicitly teach wherein the secure execution environment is managed by the cloud service provider
wherein source code for the application is stored in the secure execution environment
and block one or more tenant-initiated management operations for the secure execution environment, wherein the one or more blocked tenant-initiated management operations include an attempt, by the tenant that owns the cloud deployment, to obtain the source code for the application stored in the secure execution environment
However, Erlingsson teaches wherein the secure execution environment is managed by the cloud service provider (Erlingsson Col. 3 lines 47-52: “Cloud environment 14 may include any suitable network-based computing environment as may serve a particular application. For example, cloud environment 14 may be implemented by one or more compute resources provided and/or otherwise managed by one or more cloud service providers”)
wherein source code for the application is stored in the secure execution environment (Erlingsson Col. 90 lines 58-60: “the source code that has been deployed in a customer's environment may be examined to determine all the things that the code could do.”)
block one or more tenant-initiated management operations for the secure execution environment, wherein the one or more blocked tenant-initiated management operations include an attempt, by the tenant that owns the cloud deployment (Erlingsson Col. 3 Line 56 – Col. 4 line 4: “Compute assets 16 may include, but are not limited to … software runtime environments (e.g., container runtime environments) … A compute asset 16 may be associated with (e.g., owned, deployed, or managed by) a particular entity, such as a customer or client of cloud environment 14 and/or data platform 12.”), to obtain the source code for the application stored in the secure execution environment (Erlingsson Col. 86 lines 49-55: “If one member of the cluster set consists of one or more users that also access an organization’s source code repository, such behavior may be determined to be outside of the typical distribution for members of the cluster set. In response to making some determination … access to the source code repository may be blocked for the users in the cluster”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan in view of Erlingsson to identify and prevent any issues with the source code (Erlingsson Col. 89 lines 47-60: “interactions with a code repository may be monitored, permissions granted to each user of the code repository may be monitored, the number of people that are checking in and checking out code may be monitored, the extent to which code revisions are documented may be monitored, and so on. In such an example, the development processes for a particular customer may be learned and compared to normal behavior for other customers. Through such comparisons, inefficiencies may be identified, vulnerabilities may be identified, and other shortcomings may be identified. In response to the identification of inefficiencies, vulnerabilities, or other shortcoming, alerts may be issued, remediation workflows may be initiated, or some other action may be taken.”).
Magowan and Erlingsson fail to explicitly teach block one or more tenant-initiated management operations for the secure environment ……allow one or more management operations for the secure environment that are initiated by the cloud service provider.
However, Chennamsetty teaches block one or more tenant-initiated management operations for the secure environment (Chennamsetty ¶46: “End user 409 of virtual machines 401, 404, and 405 may request one or more of the aforementioned operations to be performed on one or more of virtual machines 401, 404, and 405 through cloud management system 403. Typically, rights to perform such operations are not granted to end users and can only be performed by administrative user 408 of cloud management system 403.”)
allow one or more management operations for the secure environment that are initiated by the cloud service provider (Chennamsetty ¶46: “cloud management system 403 includes user interface 406 displayed on hardware of cloud management system 403, which allows administrative user 408 of cloud management system 403 to view and perform the aforementioned operations.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan and Erlingsson in view of Chennamsetty to allow the cloud service provider to manage the environment but not the tenant as cloud service provider management operations are more secure (Chennamsetty ¶55: “According to another embodiment, the security assessment displayed in cloud management system 403 includes detailed information about the security assessment to enable the administrator of cloud management system 403 to understand the security assessment and take appropriate action.”).
Examiner Note: “secure execution environment” is being interpreted in light of ¶16 of the specification: “A secure execution environment, as the term is used here, represents an aggregation of resources such as physical or virtual compute resources, storage resources, networking resources, and other resources, paired with mechanisms that safeguard source code from misappropriation.”
Claims 9 and 16 are substantially similar to claim 1 and are rejected under the same rationale.
In addition, Magowan teaches claim 9’s apparatus for securely deploying applications by a cloud service provider (Magowan ¶45: “Trusted execution environment 218 provides isolated and secure execution of a set of containers in a pod sandbox virtual machine corresponding to a service, which is provided by an application owner in a container orchestration environment, based on a set of rules contained in a trusted execution environment contract that corresponds to a pod deployment description for the set of containers.”), comprising: a memory; and one or more processing devices, operatively coupled to the memory, the one or more processing devices configured to (Magowan ¶43: “Processor unit 204 serves to execute instructions for software applications and programs that may be loaded into memory”)
In addition, Magowan teaches claim 16’s non-transitory computer readable storage medium storing instructions which, when executed, cause a processing device to (Magowan ¶21: “The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of the present invention.”).
Regarding claim 2, Magowan, Erlingsson, and Chennamsetty teach the method of claim 1 but Magowan fails to teach wherein the secure execution environment includes uncompiled source code for the application, the method further comprising blocking, by the agent, an attempt to obtain the uncompiled source code for the application.
However, Erlinggsson teaches wherein the secure execution environment includes uncompiled source code for the application, the method further comprising blocking, by the agent, an attempt to obtain the uncompiled source code for the application (Erlingsson Col. 86 lines 49-55: “If one member of the cluster set consists of one or more users that also access an organization's source code repository, such behavior may be determined to be outside of the typical distribution for members of the cluster set. In response to making some determination … access to the source code repository may be blocked for the users in the cluster”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan and Chennamsetty in view of Erlingsson to identify and prevent any issues with the source code (Erlingsson Col. 89 lines 47-60: “interactions with a code repository may be monitored, permissions granted to each user of the code repository may be monitored, the number of people that are checking in and checking out code may be monitored, the extent to which code revisions are documented may be monitored, and so on. In such an example, the development processes for a particular customer may be learned and compared to normal behavior for other customers. Through such comparisons, inefficiencies may be identified, vulnerabilities may be identified, and other shortcomings may be identified. In response to the identification of inefficiencies, vulnerabilities, or other shortcoming, alerts may be issued, remediation workflows may be initiated, or some other action may be taken.”).
Claims 10 and 17 are substantially similar to claim 2 and are rejected under the same rationale.
Regarding claim 3, the method of claim 1 wherein deploying the agent within the secure execution environment further comprises deploying one or more secure kubelets (Magowan ¶5: “In a container orchestration environment, such as Kubernetes, a host node comprises a kubelet, kube-proxy, and container runtime. The kubelet is an agent that runs on each host node and is responsible for the running state of each host node, ensuring that all containers on a host node are running and healthy.”).
Claims 11 and 18 are substantially similar to claim 3 and is rejected under the same rationale.
Claims 4-5, 12-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Magowan in view of Erlingsson in view of Chennamsetty in view of Saxena et al. (US Patent Publication No. 2022/0121470 – provided by Applicant in IDS), hereinafter Saxena.
Regarding claim 4, Magowan, Erlingsson, and Chennamsetty teach the method of claim 1 but fail to teach wherein source code for the application includes metadata indicating that the application must be executed in a secure execution environment.
However, Saxena teaches wherein source code for the application includes metadata indicating that the application must be executed in a secure execution environment (Saxena ¶71: “The metadata further includes security preference information indicating one or more preferred execution environments for the microservice …The security preferences may include one or more security requirements, e.g., where an encrypted execution environment is required for the microservice.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, and Chennamsetty in view of Saxena to require the application be executed in a secure environment to increase security measures to protect against advanced adversaries (Saxena ¶62: “Current orchestration systems do not currently take into account security requirements or preferences of microservices when making deployment decisions. This contrasts with recent advances in security mechanisms for applications, e.g., hardware-provided confidentiality and/or integrity isolation techniques, e.g., encrypted VM or application isolations such as Intel's SGX™ and TDX™. Such techniques can provide protections against advanced adversaries who attack the operating system and/or hypervisor of a node, or even provide protections against physical attacks in some cases.”).
Claims 12 and 19 are substantially similar to claim 4 and are rejected under the same rationale.
Regarding claim 5, Magowan, Erlingsson, and Chennamsetty teach the method of claim 1 but fail to teach wherein data associated with the application is encrypted at rest and wherein data communications associated with the application are encrypted.
However, Saxena teaches wherein data associated with the application is encrypted at rest (Saxena ¶71: “the security preference information may include an ordered set of preferred execution environments for the microservice, e.g., an encrypted, isolated environment (e.g., TDX or SGX) as a first priority”) and wherein data communications associated with the application are encrypted (Saxena ¶69: “a deployment policy may steer the sidecar onto M2 so that the sidecar either supplies a software version of the operation performed by QAT1, or selects a combination of software and hardware method to encrypt its file, network, or memory data.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, and Chennamsetty in view of Saxena to utilize encryption for the application for data at rest and its communications to increase security measures to protect against advanced adversaries (Saxena ¶62: “Current orchestration systems do not currently take into account security requirements or preferences of microservices when making deployment decisions. This contrasts with recent advances in security mechanisms for applications, e.g., hardware-provided confidentiality and/or integrity isolation techniques, e.g., encrypted VM or application isolations such as Intel's SGX™ and TDX™. Such techniques can provide protections against advanced adversaries who attack the operating system and/or hypervisor of a node, or even provide protections against physical attacks in some cases.”).
Claim 13 is substantially similar to claim 5 and is rejected under the same rationale.
Claims 6-7, 14-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Magowan in view of Erlingsson in view of Chennamsetty in view Yang et al. (US Patent Publication No. 2010/0121954), hereinafter Yang in view of Cunetto et al. (US Patent No. 7,701,947), hereinafter Cunetto.
Regarding claim 6, Magowan, Erlingsson, and Chennamsetty teach the method of claim 1 further comprising: receiving a request to access the application (Magowan ¶65: “The secure agent enforces the trusted execution environment contract within the trusted execution environment by validating or verifying any external orchestration request from the container runtime, container orchestration environment administrator, or any other source outside the trusted execution environment against rules included in the trusted execution environment contract. It should be noted that the orchestration request can include a sequence of commands to deploy or start an application workload.”); but fail to teach and blocking the request responsive to determining that the request is not issued to a port.
However, Yang teaches and blocking the request responsive to determining that the request is not issued to a port [defined in the source code] (Yang ¶15: “blocking or unblocking the first user's access to a particular port on which the particular application runs to disallow or allow access to the particular application”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, and Chennamsetty in view of Yang to address security concerns with access control for the application (Yang ¶26: “For the security concern, the devices 101 and 103 may need to implement access controls. For example, the device 101 may implement a firewall which functions based on a predetermined rule set.”).
Magowan, Erlingsson, Chennamsetty, and Yang fail to teach a port defined in the source code
However, Cunnetto teaches a port defined in the source code (Cunetto Col. 6 Lines 6-11: “The computer readable medium may further include a retrieving source code segment that retrieves service policies from the subscriber account; a determining source code segment that determines from the service policies whether the subscriber is entitled to access the network from the access port, as requested”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, Chennamsetty, and Yang in view of Cunetto to define the port used in the source code to dynamically apply appropriate security policies of port access (Cunetto Col. 6 Lines 62-65: “The present invention enables a high speed network, such as an ATM network, an optical network, or the like, to dynamically apply the individual service policies of a network subscriber through any compatible interface, or port. Thus, the appropriate service policy can even be applied when the subscriber accesses the network from a port remote from the subscriber's permanent port.”).
Claims 14 and 20 are substantially similar to claim 6 and is rejected under the same rationale.
Regarding claim 7, Magowan, Erlingsson, and Chennamsetty teach the method of claim 1 further comprising: receiving a request to access the application (Magowan ¶65: “The secure agent enforces the trusted execution environment contract within the trusted execution environment by validating or verifying any external orchestration request from the container runtime, container orchestration environment administrator, or any other source outside the trusted execution environment against rules included in the trusted execution environment contract. It should be noted that the orchestration request can include a sequence of commands to deploy or start an application workload.”); but Magowan, Erlingsson, and Chennamsetty fail to teach and allowing the request responsive to determining that the request is issued to a port.
However, Yang teaches and allowing the request responsive to determining that the request is issued to a port [defined in the source code] (Yang ¶15: “blocking or unblocking the first user's access to a particular port on which the particular application runs to disallow or allow access to the particular application”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, and Chennamsetty in view of Yang to address security concerns with access control for the application (Yang ¶26: “For the security concern, the devices 101 and 103 may need to implement access controls. For example, the device 101 may implement a firewall which functions based on a predetermined rule set.”).
Magowan, Erlingsson, Chennamsetty, and Yang fail to teach a port defined in the source code
However, Cunnetto teaches a port defined in the source code (Cunetto Col. 6 Lines 6-11: “The computer readable medium may further include a retrieving source code segment that retrieves service policies from the subscriber account; a determining source code segment that determines from the service policies whether the subscriber is entitled to access the network from the access port, as requested”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, Chennamsetty, and Yang in view of Cunetto to define the port used in the source code to dynamically apply appropriate security policies of port access (Cunetto Col. 6 Lines 62-65: “The present invention enables a high speed network, such as an ATM network, an optical network, or the like, to dynamically apply the individual service policies of a network subscriber through any compatible interface, or port. Thus, the appropriate service policy can even be applied when the subscriber accesses the network from a port remote from the subscriber's permanent port.”).
Claim 15 is substantially similar to claim 7 and is rejected under the same rationale.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Magowan in view of Erlingsson in view of Chennamsetty in view of Sawhney et al. (US Patent No. 9,116,768), hereinafter Sawhney.
Regarding claim 8, Magowan, Erlingsson and Chennamsetty teach the method of claim 1 further comprising: offering the application in an application marketplace (Magowen ¶2: “Many cloud services offer a container orchestration environment as a service (e.g., Platform-as-a-Service, Infrastructure-as-a-Service, or the like).”);
receiving a request to deploy the application within the cloud deployment of the tenant (Magowan ¶65: “It should be noted that the orchestration request can include a sequence of commands to deploy or start an application workload.”);
but fail to explicitly teach and blocking the application from being deployed in standard execution environments within the cloud deployment of the tenant.
However, Sawheny teaches blocking the application from being deployed in standard execution environments within the tenant’s cloud deployment (Sawhney Col. 10 Lines 8-15: "determination module 108 may identify at least one security measure that deployment environment 202 is to implement prior to or while executing application 130. Determination module 108 may then block, prevent, or otherwise not allow deployment environment 202 to execute application 130 until deployment environment 202 implements the security measure." Col. 5 Lines 40-52: "The term “deployment environment, as used herein, generally refers to any type or form of Software and/or hardware-based computing platform capable of executing an application. Examples of deployment environments include, without limitation, mobile computing environments, workplace computing environments, home and/or personal computing environments, cloud-based computing environments, combinations of one or more of the same, and/or any additional type of computing environment”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Magowan, Erlingsson, and Chennamsetty in view of Sawhney to not allow the application to be deployed in an environment that is not secure to increase security and control of application deployment (Sawhney Col. 4 Lines 13-21: “Moreover, the disclosed systems and methods may ensure the safe and secure execution of an application deployed within an application container by monitoring and/or restricting the actions performed by the application once the application has been deployed. As such, the systems and methods described herein may provide enterprises, IT administrators, etc., with enhanced and more efficient control over the deployment of applications to external computing environments.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Duncan (United States Patent Publication No. 2025/0007895).
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 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
