Prosecution Insights
Last updated: August 14, 2026
Application No. 18/927,696

SECURELY DEPLOYING APPLICATIONS BY A CLOUD SERVICE PROVIDER

Non-Final OA §103§112
Filed
Oct 25, 2024
Examiner
ANKRUM, ALEC CHRISTOPHER
Art Unit
2434
Tech Center
2400 — Computer Networks
Assignee
Microsoft Technology Licensing, LLC
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-58.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
9 currently pending
Career history
13
Total Applications
across all art units

Statute-Specific Performance

§101
9.4%
-30.6% vs TC avg
§103
59.4%
+19.4% vs TC avg
§112
28.1%
-11.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 0 resolved cases

Office Action

§103 §112
CTNF 18/927,696 CTNF 101867 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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-20 are under examination. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant regards as the invention. Regarding claims 1, 9, and 16, they recite the limitations “the secure environment”. There is insufficient antecedent basis for these limitations in the claims as it is unclear whether they are referring to the “secure execution environment” or another environment. For examination purposes, “the secure environment” will be interpreted as referring to the “secure execution environment”. Claims 2-8, 10-15, and 17-20 are rejected based on their respective dependency to indefinite claims 1, 9, and 16. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim s 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 Moorthi et al. (US Patent No. 9,898,393), hereinafter Moorthi 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 a tenant’s cloud deployment, 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.”) ; 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.”) , but Magowan fails to teach wherein source code for the application is stored in the secure execution environment; However, Moorthi teaches wherein source code for the application is stored in the secure execution environment (Moorthi Col. 11 Lines 9-12: “System 200 includes a customer environment 202, which hosts a customer's code repository. The code repository 202 can include source code”) ; 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 Moorthi to store the source code of the application in the secure execution environment to increase the speed and reliability of deploying the application (Moorthi Col. 1 Line 63-Col. 2 Line 3: “Stated broadly, aspects of a system are described that allow large software build and test processes to be carried out quickly, reliably, and with minimal setup overhead using distributed cloud compute resources. In various aspects, provided are systems and method for supporting the SDLC that are easier to use, simpler to setup, and deliver results faster, with the ability to scale to larger and larger groups of users.”). Magowan further teaches 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 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).”) ; and allow one or more [management] operations for the secure 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 block one or more tenant-initiated management operations for the secure environment and 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 Moorthi 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 206.”) 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, Moorthi, 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, Moorthi 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 (Moorthi Col. 63 Lines 46-49: “the system prevents its maintainers from directly accessing user source code using, for example, public key encryption and access control measures (e.g., unix access control measures).”) . 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 Moorthi to prevent access to the source code to increase security (Moorthi “Col. 61 Lines 55-63: “This isolation may be primarily for security, for performance isolation, or to ensure repeatable test execution results, or any combination of the forgoing … isolation can be achieved using virtual memory and operating system user and process isolation and security mechanisms.”). 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 . 07-21-aia AIA Claim s 4-5, 12-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Magowan in view of Moorthi 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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 . 07-21-aia AIA Claim s 6-7, 14-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Magowan in view of Moorthi 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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, Moorthi, 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 . 07-21-aia AIA Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Magowan in view of Moorthi in view of Chennamsetty in view of Sawhney et al. (US Patent No. 9,116,768), hereinafter Sawhney . Regarding claim 8, Magowan, Moorthi 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 a tenant’s cloud deployment (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 tenant’s cloud deployment. 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, Moorthi, 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 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. /A.C.A./Examiner, Art Unit 2434 /NOURA ZOUBAIR/Primary Examiner, Art Unit 2434 Application/Control Number: 18/927,696 Page 2 Art Unit: 2434 Application/Control Number: 18/927,696 Page 3 Art Unit: 2434
Read full office action

Prosecution Timeline

Oct 25, 2024
Application Filed
Jun 16, 2026
Non-Final Rejection mailed — §103, §112
Jul 28, 2026
Examiner Interview Summary

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month