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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 18, 2026 has been entered.
1. Claims 1-20 were previously pending consideration. The received amendment does not cancel or add any claims.
2. Claims 1-20 are currently pending consideration.
Response to Arguments
3. Applicant's arguments filed on February 18, 2026 have been fully considered but they are not persuasive for the following reasons:
4. The Applicant argues that the Cited Prior Art (CPA), Malvankar in view of Kravtsov, does not disclose or render obvious deploying managing, by the agent, compliance of the container environment with the security control, wherein managing comprises determining, by the agent, whether the container environment is implementing the security control. This argument is not found persuasive. Malvankar discloses generating a compliance score of each vector representation of each container build, wherein the ANN outputs the compliance score to determine whether the vector is non-compliant (Figure 3, and associated text). If the vector is non-compliant, the container is abandoned (Figure 3, item 320). Therefore, Malvankar does disclose the managing of the agent the compliance of the container environment and the determination of whether the container environment is implementing the security control. Furthermore, the Applicant argues that the CPA does not disclose that responsive to the determination, by the agent, that the container environment is not implementing the security control, providing, by the agent, a report containing data representing non-compliance of the container environment with the security policy. Malvankar does disclose the generation of a compliance score which can result in a determination of non-compliance which results in abandoning the container (see Figure 3). However, there is no explicit report that is generated. Adam (U.S. Patent Pub. U.S. 2022/0357954) is introduced to disclose the generating of the report. The rejection is provided below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-9, 11, and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar et al. (U.S. Patent Pub. No. US 2023/0118939) in view of Kravtsov et al. (U.S. Patent Pub. No. US 2023/0353593) in further in view of Adam et al. (U.S. Patent Pub. No. US 2022/0357954).
Regarding claim 1, Malvankar discloses:
A method comprising:
determining, by a recommendation engine, a security risk profile for a container environment comprising a plurality of pods to be deployed on an infrastructure comprising a plurality of nodes (paragraph 0035-0037: tools may be distributed across the network, using ANNs to assess container files and VM images with respect to compliance of executable code and to selectively replace layers of the subject container file or VM prior to provisioning the container file or VM image), wherein determining the security risk profile comprises:
determining, by the recommendation engine, a recommendation of a security policy for the container environment based on the security risk profile, wherein the security policy comprises a security control (paragraphs 0032-0040: The identified vector may be previously designated as compliant or non-compliant, either by the library in which it is populated or via a corresponding identifier. In an embodiment, the analyzed metadata file is added to the repository (160) by the representation manager (152) after the assessment by the NN manager (154), with the layers of the file individually identified as compliant or non-compliant. Accordingly, the NN manager (154) conducts an assessment and identifies a vector from the repository closest to the container file or VM image vector representation that is the subject of the analysis); and
deploying the container environment to the infrastructure (paragraph 0004, 0025-0026: deploying the container); and
managing, by the agent, compliance of the container environment with the security control (Figure 3 and associated text), wherein the managing comprises:
determining, by the agent, whether the container environment is implementing the security control (Figure 3, and associated text).
Malvankar does not explicitly disclose determining an infrastructure context characterizing the infrastructure and determining a workload context characterizing a workload associated with the container environment. In an analogous art, Kravtsov discloses creating security context profiles for its environment (infrastructure context) that validates the pod’s security context to enforce environment integrity (paragraph 0016) and the security context profile may differentiate a pod’s communication capabilities (workload context) to establish access and/or permission constraints applied to each pod and container configured at runtime (paragraph 0027). It would have been obvious to one of ordinary skill in the art to use the security context profiles of Kravtsov in the system of Malvankar so that every pod can have a granular profile without the need to pre-define a role (Kravtsov: paragraph 0016).
Furthermore, Malvankar does not explicitly disclose deploying an agent to the infrastructure to manage compliance of the container environment with the security control. Kravtsov discloses deployment of agents on each node for policy enforcement (paragraphs 0016, 0042). It would have been obvious to one of ordinary skill in the art to deploy agents on nodes, as is performed in Kravtsov, in the system of Malvankar to provide policy enforcement without performance degradation (Kravtsov: paragraph 0016). Malvankar does not explicitly disclose the deployment of the agent is after the deployment of the container environment to the infrastructure. Malvankar focuses on the validating of the containers before deployment. However, Kravtsov discloses that policy enforcement (analogous to the security policy based on the security risk profile comprising a security control of the claimed invention) is applied by the deployment of agents on each node (host) (paragraph 0016). Kravtsov discloses that a user can create a security context profile for its environment that validates the pod’s security context to enforce environment integrity (paragraph 0016) and this provides granular control (security control) (paragraph 0016). In Kravtsov, the containers are deployed into a network (See Figure 1) and the agents (paragraphs 0016, 0042) that are deployed (e.g., DaemonSet) retrieve and synchronize policies and apply the policies for the container. These are well-known functions of agents and particularly DaemonSet agents. These agents are deployed after the containers are already deployed into the infrastructure (paragraph 0016 ,0042). It would have been obvious to one of ordinary skill in the art to use agents deployed after the containers in order to enforce the policies on the container on a granular level (Kravtsov: paragraphs 0016, 0042).
The combination of Malvankar and Kravtsov does not explicitly disclose responsive to a determination, by the agent, that the container environment is not implementing the security control, providing, by the agent, a report containing data representing non-compliance of the container environment with the security policy. In an analogous art, Adam discloses evaluating KUBERNETES containers and pods (paragraphs 0052, 0062). Furthermore, Adam discloses generating a compliance report that summarizes the node-by-node findings and can determine whether the computing application is compliant or non-compliant (paragraph 0038-0039). This compliance report can then be sent to a developer or operator of the computing application (paragraph 0039). It would have been obvious to one of ordinary skill in the art to use the compliance reporting of Adam in the system of Malvankar-Kravtsov so that non-compliance can be properly reported to the developers to provide additional visibility into policy violations (Adam: paragraph 0039).
Claim 2 is rejected as applied above in rejecting claim 1. Furthermore, Malvankar discloses:
The method of claim 1, wherein determining the security risk profile further comprises applying, by the recommendation engine, the infrastructure context and the workload context to a rules-based classifier to determine the security risk profile (paragraph 0045: With respect to the example container build file (410), the presence of private keys in the container build file results in a classification of the file as non-compliant since access to the data is restricted by the private keys).
Claim 3 is rejected as applied above in rejecting claim 2. Furthermore, Malvankar discloses:
The method of claim 2, wherein determining the security risk profile further comprises, responsive to application of the infrastructure context and the workload context to the rules-based classifier not providing a classification, applying, by the recommendation engine, the infrastructure context and the workload context to a machine learning-based classifier to determine the security risk profile (paragraphs 0029-0032: neural network manager analyzes files for compliance).
Claim 4 is rejected as applied above in rejecting claim 1. Furthermore, Malvankar discloses:
The method of claim 1, wherein determining the recommendation of the security policy comprises determining a network service security control, a chassis security control or a user management security control for the container environment (paragraph 0075: management layer provides resource provisioning).
Claim 5 is rejected as applied above in rejecting claim 1. Furthermore, Malvankar discloses:
The method of claim 1, wherein determining the security risk profile further comprises: receiving, by the recommendation engine, a perceived security risk of the container environment provided as a user input; and determining the security risk profile based on the perceived security risk (paragraphs 0027-0030: risk assessment).
Claim 6 is rejected as applied above in rejecting claim 1. Furthermore, Kravtsov discloses:
The method of claim 1, wherein determining the security risk profile further comprises: receiving, by the recommendation engine, intent parameters for the container environment provided as user input, wherein the intent parameters represent at least one of an infrastructure for the container environment or a workload for the container environment (paragraphs 0016, 0027: workload and environment contexts are provided in creating a profile).
Claim 7 is rejected as applied above in rejecting claim 1. Furthermore, Kravtsov discloses:
The method of claim 1, wherein:
deploying the agent comprises deploying the agent before the deploying of the container environment (paragraphs 0016, 0042: deploying an agent); and
determining the infrastructure context comprises receiving, by the recommendation engine, input from the agent representing characteristics of the infrastructure (paragraph 0016: create a security context profile for its environment).
Claim 8 is rejected as applied above in rejecting claim 1. Furthermore, Kravtsov discloses:
The method of claim 1, wherein deploying the agent comprises deploying the agent after determination of the recommendation of the security policy (paragraph 0027: security context profiles may include a recommend security profile).
Claim 9 is rejected as applied above in rejecting claim 1. Furthermore, Malvankar discloses:
The method of claim 1, further comprising determining, by the recommendation engine, a recommendation of a security assessment policy for the container environment based on the security risk profile (paragraph 0035-0037: tools may be distributed across the network, using ANNs to assess container files and VM images with respect to compliance of executable code and to selectively replace layers of the subject container file or VM prior to provisioning the container file or VM image).
Claim 11 is rejected as applied above in rejecting claim 1. Furthermore, Malvankar discloses:
The method of claim 1, further comprising determining, by the recommendation engine, a recommendation of a security issue remediation policy for the container environment based on the security risk profile (paragraph 0035-0037: tools may be distributed across the network, using ANNs to assess container files and VM images with respect to compliance of executable code and to selectively replace layers of the subject container file or VM prior to provisioning the container file or VM image).
Regarding claim 17, Malvankar discloses:
A computer system comprising:
a management agent hosted on a first infrastructure that hosts a deployed container environment (paragraph 0035-0037: tools may be distributed across the network, using ANNs to assess container files and VM images with respect to compliance of executable code and to selectively replace layers of the subject container file or VM prior to provisioning the container file or VM image), wherein the management agent to manage compliance of the deployed container environment with a security policy, wherein the security policy comprises a set of security features for the deployed container environment (Figure 3 and associated text: determine compliance), and wherein the management agent to:
determine whether the deployed container environment is implementing a given security feature of the set of security features (Figure 3 and associated text: determine compliance); and
a security management engine hosted on a second infrastructure remote from a first infrastructure, wherein the security management engine to:
responsive to the report, initiate a first responsive action (paragraphs 0031-0035: determining compliance or non-compliance, and in response, can replace layers of the build).
Malvankar does not explicitly disclose a management agent hosted on a first infrastructure that hosts a container environment. In an analogous art, Kravtsov discloses deployment of agents on each node for policy enforcement (paragraphs 0016, 0042). It would have been obvious to one of ordinary skill in the art to deploy agents on nodes, as is performed in Kravtsov, in the system of Malvankar to provide policy enforcement without performance degradation (Kravtsov: paragraph 0016).
Malvankar does not explicitly disclose the deployment of the agent is after the deployment of the container environment to the infrastructure. Malvankar focuses on the validating of the containers before deployment. However, Kravtsov discloses that policy enforcement (analogous to the security policy based on the security risk profile comprising a security control of the claimed invention) is applied by the deployment of agents on each node (host) (paragraph 0016). Kravtsov discloses that a user can create a security context profile for its environment that validates the pod’s security context to enforce environment integrity (paragraph 0016) and this provides granular control (security control) (paragraph 0016). In Kravtsov, the containers are deployed into a network (See Figure 1) and the agents (paragraphs 0016, 0042) that are deployed (e.g., DaemonSet) retrieve and synchronize policies and apply the policies for the container. These are well-known functions of agents and particularly DaemonSet agents. These agents are deployed after the containers are already deployed into the infrastructure (paragraph 0016 ,0042). It would have been obvious to one of ordinary skill in the art to use agents deployed after the containers in order to enforce the policies on the container on a granular level (Kravtsov: paragraphs 0016, 0042).
The combination of Malvankar and Kravtsov does not explicitly disclose responsive to a determination, by the agent, that the container environment is not implementing the security control, providing, by the agent, a report containing data representing non-compliance of the container environment with the security policy. In an analogous art, Adam discloses evaluating KUBERNETES containers and pods (paragraphs 0052, 0062). Furthermore, Adam discloses generating a compliance report that summarizes the node-by-node findings and can determine whether the computing application is compliant or non-compliant (paragraph 0038-0039). This compliance report can then be sent to a developer or operator of the computing application (paragraph 0039). It would have been obvious to one of ordinary skill in the art to use the compliance reporting of Adam in the system of Malvankar-Kravtsov so that non-compliance can be properly reported to the developers to provide additional visibility into policy violations (Adam: paragraph 0039).
Claim 18 is rejected as applied above in rejecting claim 17. Furthermore, Kravtsov discloses:
The computer system of claim 17, wherein:
the security policy comprises at least one of a security control policy, a security assessment policy or a remediation policy (paragraphs 0031-0035: determining compliance or non-compliance, and in response, can replace layers of the build).
Regarding claim 19, Malvankar discloses:
A non-transitory storage medium to store machine-readable instructions that, when executed by a machine associated with a cloud service, cause the machine to:
receive a first compliance from a management agent hosted on an infrastructure that hosts a container environment (paragraph 0035-0037: tools may be distributed across the network, using ANNs to assess container files and VM images with respect to compliance of executable code and to selectively replace layers of the subject container file or VM prior to provisioning the container file or VM image);
process the second compliance report to identify non-compliance of the container environment with a security control policy (paragraphs 0031-0035: determining compliance or non-compliance, and in response, can replace layers of the build), wherein processing the first compliance report comprises determining, based on the first compliance report, whether the deployed container environment is implementing a security control specified by a security control policy (Figure 3 and associated text: determining compliance or non-compliance); and
responsive to identifying non-compliance of the container environment with the security control policy, initiate a first corrective action (paragraphs 0031-0035: determining compliance or non-compliance, and in response, can replace layers of the build).
Malvankar does not explicitly disclose receiving a first compliance report from a management agent hosted on an infrastructure that hosts a container environment. Malvankar does not explicitly disclose a management agent hosted on a first infrastructure that hosts a container environment. In an analogous art, Kravtsov discloses deployment of agents on each node for policy enforcement (paragraphs 0016, 0042). It would have been obvious to one of ordinary skill in the art to deploy agents on nodes, as is performed in Kravtsov, in the system of Malvankar to provide policy enforcement without performance degradation (Kravtsov: paragraph 0016).
Malvankar does not explicitly disclose the deployment of the agent is after the deployment of the container environment to the infrastructure. Malvankar focuses on the validating of the containers before deployment. However, Kravtsov discloses that policy enforcement (analogous to the security policy based on the security risk profile comprising a security control of the claimed invention) is applied by the deployment of agents on each node (host) (paragraph 0016). Kravtsov discloses that a user can create a security context profile for its environment that validates the pod’s security context to enforce environment integrity (paragraph 0016) and this provides granular control (security control) (paragraph 0016). In Kravtsov, the containers are deployed into a network (See Figure 1) and the agents (paragraphs 0016, 0042) that are deployed (e.g., DaemonSet) retrieve and synchronize policies and apply the policies for the container. These are well-known functions of agents and particularly DaemonSet agents. These agents are deployed after the containers are already deployed into the infrastructure (paragraph 0016 ,0042). It would have been obvious to one of ordinary skill in the art to use agents deployed after the containers in order to enforce the policies on the container on a granular level (Kravtsov: paragraphs 0016, 0042).
The combination of Malvankar and Kravtsov does not explicitly disclose responsive to a determination, by the agent, that the container environment is not implementing the security control, providing, by the agent, a report containing data representing non-compliance of the container environment with the security policy. In an analogous art, Adam discloses evaluating KUBERNETES containers and pods (paragraphs 0052, 0062). Furthermore, Adam discloses generating a compliance report that summarizes the node-by-node findings and can determine whether the computing application is compliant or non-compliant (paragraph 0038-0039). This compliance report can then be sent to a developer or operator of the computing application (paragraph 0039). It would have been obvious to one of ordinary skill in the art to use the compliance reporting of Adam in the system of Malvankar-Kravtsov so that non-compliance can be properly reported to the developers to provide additional visibility into policy violations (Adam: paragraph 0039).
Claim 20 is rejected as applied above in rejecting claim 19. Furthermore, Kravtsov discloses:
The storage medium of claim 19, wherein the instructions, when executed by the machine, further cause the machine to:
receive a second compliance report from the management agent (paragraphs 0013-0015, 0044-0045: a management agent can monitor for two separate pod policies);
process the second compliance report to identify non-compliance of the container environment with a security issue remediation policy (paragraph 0013-0015, 0044-0045: receive a report of a violation action); and
responsive to identifying non-compliance of the container environment with the security issue remediation policy, initiate a second corrective action (paragraphs 0044-0045: violation actions may include blocking, detecting or alerting).
Claim(s) 10 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar et al. (U.S. Patent Pub. No. US 2023/0118939) in view of Kravtsov et al. (U.S. Patent Pub. No. US 2023/0353593) further in view of Adam et al. (U.S. Patent Pub. No. US 2022/0357954) further in view of Bhalotra et al. (U.S. Patent 10,397,255).
Claim 10 is rejected as applied above in rejecting claim 9. Furthermore, the combination of Malvankar and Kravtsov does not explicitly disclose that the security assessment policy specifies an action to evaluate the container environment for a security vulnerability or a security intrusion and that the security assessment policy specifies a trigger to initiate the action. In an analogous art, Bhalotra discloses an analysis module which evaluates multiple data sets (column 4, lines 13-23) and an enforcement module which prevents, blocks or mitigates malicious activity that is discovered (column 7, lines 53-60, column 10, lines 61 – column 11, line 23). It would have been obvious to one of ordinary skill in the art to allow the remediation policies to be integrated into the system of Malvankar and Kravtsov so that risk can be mitigated (column 11, lines 1-7).
Claim 12 is rejected as applied above in rejecting claim 1. Furthermore, the combination of Malvankar and Kravtsov does not explicitly disclose the security issue remediation policy specifies an action to respond to a detected security vulnerability or a security intrusion for the container environment and the security issue remediation policy specifies a condition to initiate the action. In an analogous art, Bhalotra discloses an analysis module which evaluates multiple data sets (column 4, lines 13-23) and an enforcement module which prevents, blocks or mitigates malicious activity that is discovered (column 7, lines 53-60, column 10, lines 61 – column 11, line 23). It would have been obvious to one of ordinary skill in the art to allow the remediation policies to be integrated into the system of Malvankar and Kravtsov so that risk can be mitigated (column 11, lines 1-7).
Claim(s) 13, 14 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar et al. (U.S. Patent Pub. No. US 2023/0118939) in view of Kravtsov et al. (U.S. Patent Pub. No. US 2023/0353593) further in view of Adam et al. (U.S. Patent Pub. No. US 2022/0357954) further in view Shen et al. (U.S. Patent Pub. No. US 2021/0109775).
Claim 13 is rejected as applied above in rejecting claim 1. Furthermore, the combination of Malvankar and Kravtsov does not explicitly disclose wherein determining the infrastructure context comprises determining whether the container environment is hosted on a bare metal machine or hosted on a virtual machine. In an analogous art, Shen discloses that the cloud infrastructure can be determined to be a virtual machine (paragraph 0172-0173) or as bare-metal hosts (paragraph 0031). It would have been obvious to differentiate between VM and bare-metal hosts as the infrastructure so that the containers can be properly modified based on whether it is running on a bare-metal host or a VM (paragraphs 0059-060).
Claim 14 is rejected as applied above in rejecting claim 1. Furthermore, the combination of Malvankar and Kravtsov does not explicitly disclose wherein determining the infrastructure context comprises determining whether the container environment is associated with a data security standard. In an analogous art, Shen discloses using a security model based on a library OS to support containers (paragraph 0062). It would have been obvious to determine whether a container is associated with a security standard in order to provide significantly improved performance and isolation (Shen: paragraph 0062).
Claim 16 is rejected as applied above in rejecting claim 1. Furthermore, the combination of Malvankar and Kravtsov does not explicitly disclose wherein determining the infrastructure context comprises determining a cybersecurity framework associated with the infrastructure. In an analogous art, Shen discloses using a security model based on a library OS to support containers (paragraph 0062). It would have been obvious to determine whether a container is associated with a security standard in order to provide significantly improved performance and isolation (Shen: paragraph 0062).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar et al. (U.S. Patent Pub. No. US 2023/0118939) in view of Kravtsov et al. (U.S. Patent Pub. No. US 2023/0353593) further in view of Adam et al. (U.S. Patent Pub. No. US 2022/0357954) further in view Chang et al. (WO 2022/066865).
Claim 15 is rejected as applied above in rejecting claim 1. Furthermore, the combination of Malvankar and Kravtsov does not explicitly disclose that determining the workload context comprises of identifying a stage of a continuous integration/continuous development (CI/CD) pipeline associated with the container environment. In an analogous art, Chang discloses the use of CI/CD tools in a container environment (paragraphs 0193-0201). It would have been obvious to incorporate the stage of CI/CD in the workload context to standardize processes around continuous integration and delivery, new feature rollout and provisioning cloud workloads (paragraph 0201).
Conclusion
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 KAVEH ABRISHAMKAR whose telephone number is (571)272-3786. The examiner can normally be reached M-F 9-5:30.
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, Jung Kim can be reached at 571-272-3804. 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.
/KAVEH ABRISHAMKAR/
03/04/2026Primary Examiner, Art Unit 2494