DETAILED ACTION
1. This office action is in response to an amendment filed on 11/03/2025. Claims 1-20 are pending. Claims 1, 8 and 15 are independent. Each independent claim is amended.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Interview Summary
3. On November 3, 2025, applicant's representative attorney James Bennin, Reg. No. 60,692 and examiner conducted applicant-initiated telephone interview. The summary of the interview is attached.
Response to Arguments
4. Applicant’s arguments filed on November 3, 2025, with regarding to the 35 U.S.C. 103 rejection to the independent claims 1, 8 and 15 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.
5. Applicant’s representative in particular argued that the following amended (underlined and bolded) claim limitations recited in independent claims 1, 8 and 15 aren’t disclosed by the references/prior arts of the record namely by Vivek Vijay Sarkale (NPL Publication, “Secure Cloud Container: Runtime Behavior Monitoring using Most Privileged Container (MPC) (herein after referred as MPC) (IEEE, 2017) in view of Vikas Goel (Goel) (US Pub. No. 2019/0273744A1).
Regarding independent claims 1, 8 and 15, it has been argued that the following underlined amended claim limitation is not disclosed by the combination of MPC in view Goel, “accessing a centralized security database that comprises, for at least one user, data representing one or more container privileges for operations required to run applications in software containers on a computing system, wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation;”
Examiner would like to point out that, the newly founded prior art NPL document, titled, “Using RBAC, Generally Available in Kubernetes v1.8” by (Eric Chiang), discloses each and every amended/underlined claim limitation.
In particular Chiang discloses each and every amended claim limitation as shown below: accessing a centralized security database [Under title, “Granting access to users, “RBAC is configured using standard Kubernetes resources. Users can be bound to a set of roles (ClusterRoles and Roles) through bindings (ClusterRoleBindings and RoleBindings”. Note: This teaches that authorization information is stored as standard Kubernetes resources, managed centrally within the cluster, i.. a centralized security databases of authorizations rules] that comprises, for at least one user, data [Under title, “Granting access to users, Under title, “ClusterRoleBindings grant a user, group, or service account a ClusterRole’s power across the entire cluster”, this teaches that authorization data is associated with at least one user, satisfying the requirement that the database comprises data, “for at least one user”] representing one or more container privileges [Creating custom rules, “Each ClusterRole holds a list of permissions specifying “rules.” And further shown, rules:- apiGroups: ["apps"]; resources: ["deployments"]; verbs: ["get", "list", "watch", "create", "delete", "update", "patch". Note permissions over deployment, pods, configmaps, secrets etc., directly the ability to create, manage, and run containerized applications, and therefore represents container privileges] for operations required to run applications in software containers on a computing system, wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation;” [Creating custom rules, “verbs: ["get", "list", "watch"]…Verbs correspond to the HTTP verb of the request. Note: This shows that authorization data specifies, for each operation (verb), whether it is permitted. Operations not listed are forbidden, thereby indicating for each operation whether the user is authorized. In other words, Chiang teaches a centralized authorization system storing user specific, operation-by-operation container privileges, that meets the amended limitation, “…wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation;”]
Regarding independent claims, applicant further argued that the following additional underlined amended claim limitation is not disclosed by the by the combination of MPC in view Goel, “wherein the software container is started by a container runtime service that is separate from the centralized security database”
Examiner would like to point out that, the newly founded prior art NPL document, titled, “Navigating the Kubernetes Architecture - A Comprehensive Guide” by (Kunal Verma), discloses each and every amended/underlined claim limitation.
In particular Verma discloses each and every amended claim limitation as shown below:
“the software container is started by a container runtime service [Container Runtime, “A container runtime or container engine is a software component responsible for executing and managing containers. Some of the main tasks it handles: container creation; container execution; resource isolation” Note: This teaches that a container runtime service whose responsible is to execute/start containers and meets the limitation, “the software container is started by a container runtime service”] that is separate [Process in the Worker Node, “As soon as the Kubelet receives this request from the API Server, it forwards the request to the Container Runtime component which is responsible for creating and managing the entire lifecycle of the actual containers itself” and See under the title, “Process in the Control Plane”, see also “ONLY the API Server talks to the ETCD component for storing the data". This collectively teaches that: the container runtime executes containers on worker nodes, and the centralized database(etcd) is accessed only by the API server in the control plane. Thus, the container runtime service is architecturally separate from the centralized database] from the centralized security data [See section, ETCD - The Cluster Database
,“A Kubernetes Cluster has an internal database called etcd, which by default stores all the cluster data.” Note: This teaches a centralized database used by the cluster, which stores control-plane data including configuration and authorization objects]
6. Thus, in response to the 35 U.S.C. 103 rejection set forth in the previous office action, applicant amended at least each independent claim 1, 8 and 15, presumably to overcome the 35 U.S.C. 103 rejection set forth in the previous office action. Since, the newly amended claims changed the scope and necessitated new grounds of rejection, applicant’s arguments are moot. The analysis of the claims under consideration, as amended, follows in the corresponding section below.
Claim Rejections - 35 USC § 103
7. 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 non-obviousness.
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 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.
8. Claims 1-2, 4-9, 11-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vivek Vijay Sarkale (NPL Publication, “Secure Cloud Container: Runtime Behavior Monitoring using Most Privileged Container (MPC) (herein after referred as MPC) (IEEE, 2017) in view of Vikas Goel (Goel) (US Pub. No. 2019/0273744A1) (Patent Date: Sep. 5, 2019) further in view of NPL document, titled, “Using RBAC, Generally Available in Kubernetes v1.8” by (Eric Chiang, Chiang) (October 28, 20217), and further in view of NPL document, titled, “Navigating the Kubernetes Architecture - A Comprehensive Guide” by (Kunal Verma, Verma) (October 2, 2023)
The following is referring to the independent claims 1, 8 and 15:
As per independent claim 1, MPC discloses a method comprising: in response to a request to initiate a software container in a container runtime environment [Page 355, second Column, Step 1 in Section V and figure 4 it describes receiving a request to initiate a container via the container engine. See pages 355-356], accessing a Page 355, Second column, Steps 2-3 and figure 4, that describes the container engine sending the request to MPC which accesses container-specific security policies. See pages 355-356… Access control policies are defined using introduced privileges-based access control mechanism. Fig.4 illustrates detailed design. When the container initiates run request, the container engine allowed to look up inside its security profiles. Container engine forwards the request packet (packed with security profile) to Most Privileged Container (MPC). The MPC makes use of policies to verify privileges (root or nonroot) that process is demanding on the host. If the processes claims for root privileges, then request is denied due to security concern because containerization security policy specifies that ‘very few processes are allowed to run as a root’. Processes demands to run without root privileges are assigned as a nonroot] verifying that a user associated with the request has been granted permission to initiate a software container based on the data representing the one or more container privileges identified in the Page 355, Second column, Steps 3 and figure 4, MPC checks the security profile to verify required privileges (e.g. root; non-root) for the container. See pages 355-356]; and in response to verifying that the user has been granted permission to initiate the software container [Page 355, Second column, Steps 4 and figure 4, it describes Upon successful verification, permission is granted and passed to the container engine for execution. See pages 355-356] starting the software container by permitting use of associated operations required to run applications in the software container, [Page 355, Second column, Steps 5 and figure 4,, it describes Operations allowed are those defined in the policies; runtime monitoring ensures compliance. See pages 355-356].
MPC discloses all the limitation but doesn’t explicitly disclose the following underlined or bolded claim limitation: “centralized security database or “accessing a centralized security database that comprises for at least one user, data representing one or more container privileges for operations required to run applications in software containers on a computing system”
However Goel discloses; “accessing a centralized security database that comprises for at least one user, data representing one or more container privileges for operations required to run applications in software containers on a computing system” [See Para. 0005 and para. 0042-0044 at least abstract, he disclosed computer-implemented method for running applications on a multi-tenant container platform may include (1) receiving, at a host administrator service on a container host computing device and via a host administrator service socket handle, a request for a privileged operation from an application running in a non-privileged container, (2) performing, based on a user identifier of the application, a security check of a user associated with the application, (3) comparing, when the security check results in approval, a process identifier of the requested privileged operation against a whitelist of permitted operations to determine the requested privileged operation is permissible, and (4) initiating running, when the requested privileged operation is permissible, the requested privileged operation.
MPC and Goel are analogous/in the same field of endeavor as they both are directed to software container in a container runtime environment.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of MPC runtime behavior enforcement with a mechanism such as “Centralized Security database” as per teachings of Goel’s identity-based privilege control to enhance the security of the system by enforcing both identity and container specific privilege policies at execution time and this provides robust access model for running application on a multi-tenant container platform. [See Goel, at least para. 0003 and para 0042-0044]
The combination of MPC and Goel doesn’t explicitly disclose the following underlined amended claim limitation, “accessing a centralized security database that comprises, for at least one user, data representing one or more container privileges for operations required to run applications in software containers on a computing system, wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation;”
However, Chiang discloses the above underlined amended claim limitation as shown below: accessing a centralized security database [Under title, “Granting access to users, “RBAC is configured using standard Kubernetes resources. Users can be bound to a set of roles (ClusterRoles and Roles) through bindings (ClusterRoleBindings and RoleBindings”. Note: This teaches that authorization information is stored as standard Kubernetes resources, managed centrally within the cluster, i.. a centralized security databases of authorizations rules] that comprises, for at least one user, data [Under title, “Granting access to users, Under title, “ClusterRoleBindings grant a user, group, or service account a ClusterRole’s power across the entire cluster”, this teaches that authorization data is associated with at least one user, satisfying the requirement that the database comprises data, “for at least one user”] representing one or more container privileges [Creating custom rules, “Each ClusterRole holds a list of permissions specifying “rules.” And further shown, rules:- apiGroups: ["apps"]; resources: ["deployments"]; verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]. Note permissions over deployment, pods, configmaps, secrets etc., directly the ability to create, manage, and run containerized applications, and therefore represents container privileges] for operations required to run applications in software containers on a computing system, wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation;” [Creating custom rules, “verbs: ["get", "list", "watch"]…Verbs correspond to the HTTP verb of the request. Note: This shows that authorization data specifies, for each operation (verb), whether it is permitted. Operations not listed are forbidden, thereby indicating for each operation whether the user is authorized. In other words, Chiang teaches a centralized authorization system storing user specific, operation-by-operation container privileges, that meets the amended limitation, “…system, wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation;”]
MPC, Goel and Chiang are analogous/in the same field of endeavor as they all are directed to software container in a container runtime environment.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of MPC and Goel with a mechanism such as “system, wherein the data indicates, for each of the operations, whether the at least one user is authorized to use the operation” as per teachings of Chiang to enhance the security of the system by providing fine-grained operation-level access control over containerized application. [See Chiang, introductory section, RBAC is a mechanism for controlling access to the Kubernetes API”]
The combination of MPC, Goel and Chiang doesn’t explicitly disclose the following underlined amended claim limitation,” wherein the software container is started by a container runtime service that is separate from the centralized security database”
However, Verma discloses the above underlined amended claim limitation:
“the software container is started by a container runtime service [Container Runtime, “A container runtime or container engine is a software component responsible for executing and managing containers. Some of the main tasks it handles: container creation; container execution; resource isolation” Note: This teaches that a container runtime service whose responsible is to execute/start containers and meets the limitation, “the software container is started by a container runtime service”] that is separate [Process in the Worker Node, “As soon as the Kubelet receives this request from the API Server, it forwards the request to the Container Runtime component which is responsible for creating and managing the entire lifecycle of the actual containers itself” and See under the title, “Process in the Control Plane”, see also “ONLY the API Server talks to the ETCD component for storing the data". This collectively teaches that: the container runtime executes containers on worker nodes, and the centralized database(etcd) is accessed only by the API server in the control plane. Thus, the container runtime service is architecturally separate from the centralized database] from the centralized security data [See section, ETCD - The Cluster Database, “A Kubernetes Cluster has an internal database called etcd, which by default stores all the cluster data.” Note: This teaches a centralized database used by the cluster, which stores control-plane data including configuration and authorization objects]
MPC, Goel, Chiang and Verma are analogous/in the same field of endeavor as they all are directed to software container in a container runtime environment.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of MPC, Goel and Chiang with a mechanism such as “the software container is started by a container runtime service that is separate from the centralized security database” as per teachings of Verma to enhance the security and scalability and fault isolation to enforce authorization without disrupting the established distributed runtime architecture. [See Verma, Process in the Worker Node, such as “As soon as the Kubelet receives this request from the API Server, it forwards the request to the Container Runtime component which is responsible for creating and managing the entire lifecycle of the actual containers itself”]
As per independent claim 8, independent claim 8 having the same scope as independent claim 1, is rejected for the same reason/rationale as that of the above independent claim 1.
As per independent claim 15, independent claim 15 having the same scope as independent claim 1, is rejected for the same reason/rationale as that of the above independent claim 1.
As per dependent claim 2, the combination of MPC, Goel, Chiang and Verma discloses a method/system as applied to claim 1 above. Furthermore, MPC discloses the method, wherein in response to the request to initiate the software container, the method comprises verifying that the user associated with the request has been granted privilege to use each of a plurality of operations required to run applications in the software container [MPC, page 354, column 2, d, d) Privilege Based Access Control Model (PBAC) We are proposing Privilege Based Access Control mechanism with most privilege container which decides what privilege that user process can have and what type of resources that process can access on real host. Privileges and access permissions are assigned to each and every user process (container) running up on host. Page 351, 2nd column, c) Runtime monitoring. Proposed MPC manages security by scanning container profiles against defined policies and container black lists. The MPC’s run time monitoring block examines process behavior continuously during runtime. Check syslog for information on which operation required privilege].
As per dependent claim 9, dependent claim 9 having the same scope as dependent claim 2, is rejected for the same reason/rationale as that of the above dependent claim 2.
As per dependent claim 16, dependent claim 16 having the same scope as dependent claim 2, is rejected for the same reason/rationale as that of the above dependent claim 2.
As per dependent claim 4, the combination of MPC, Goel, Chiang and Verma discloses a method/system as applied to claim 1 above. Furthermore, MPC discloses the method further comprising providing access to the centralized security database, that comprises for at least one user, the data representing one or more container privileges based on a call from a container runtime service; and in response to verifying that the user has been granted permission to initiate the software container, providing an indication of user privilege for the operations to the container runtime service [ Page 355, MPC is integrated in to container runtime stack and enforces policies at initiation (Steps 2-3) Step 2 - The container engine forwarded the request to proposed MPC security layer Step 3 - MPC Security Layer a) Check the security profile of the requesting container against defined access control policies. b) Check the requesting container against black listed database. See Goel para. 0017, the systems and methods described herein may use of two levels of name-space virtualization, with container implementation software providing a primary level (at the kernel API level) and library interposition selectively handling system calls that require privilege and intermediation.].
As per dependent claim 11, dependent claim 11 having the same scope as dependent claim 4, is rejected for the same reason/rationale as that of the above dependent claim 4.
As per dependent claim 18, dependent claim 18 having the same scope as dependent claim 4, is rejected for the same reason/rationale as that of the above dependent claim 4.
As per dependent claim 5 the combination of MPC, Goel, Chiang and Verma discloses a method/system as applied to claim 2 above. Furthermore, MPC discloses the method further comprising
denying the user an ability to initiate the software container in response to a finding that the data representing one or more container privileges does not grant privilege to use each of the plurality of operations required to run applications in the software container [Page 355, column 2, Steps 3-4, if privileges not met, access is denied and process is halter. See claim 1 where the operation are only granted if the comparing steps determines that privileged operation is permissible. performing a security check of a user associated with the application;
comparing, when the security check results in approval, a process identifier of the requested privileged operation against a whitelist of permitted operations to determine the requested privileged operation is permissible; and initiating running, when the requested privileged operation is permissible, the requested privileged operation and see also Goel at least abstract and claim 1 method for running applications on a multi-tenant container platform may include (1) receiving, at a host administrator service on a container host computing device and via a host administrator service socket handle, a request for a privileged operation from an application running in a non-privileged container, (2) performing, based on a user identifier of the application, a security check of a user associated with the application, (3) comparing, when the security check results in approval, a process identifier of the requested privileged operation against a whitelist of permitted operations to determine the requested privileged operation is permissible].
As per dependent claim 12, dependent claim 12 having the same scope as dependent claim 5, is rejected for the same reason/rationale as that of the above dependent claim 5.
As per dependent claim 19, dependent claim 19 having the same scope as dependent claim 5, is rejected for the same reason/rationale as that of the above dependent claim 5.
As per dependent claim 6 the combination of MPC, Goel, Chiang and Verma discloses a method/system as applied to claim 1 above. Furthermore, MPC discloses the method further comprising providing an administrator interface that provides the data representing one or more container privileges, for the centralized security database to grant container initiation privilege on a per user basis [Page 352, Containers management can be done in web interface so that administrators and container service users can access through the web interface and 353-354, SELinux defines access policies for every user, application, process, and files. It is a system administrator who decides to implement 353 policies to the server in that policies can be strict or lenient based on the situation. SELinux policies are categorized as: Enforcement policies, Multi-level security enforcement policies, and Multi category security enforcement policies. MAC works by assigning labels to each file system object. System administrator refers label to write policies in order to control access between subjects and objects. See Goel at least abstract, 1) receiving, at a host administrator service on a container host computing device and via a host administrator service socket handle, a request for a privileged operation from an application running in a non-privileged container, (2) performing, based on a user identifier of the application, a security check of a user associated with the application, (3) comparing, when the security check results in approval, a process identifier of the requested privileged operation against a whitelist of permitted operations to determine the requested privileged operation is permissible. See figure 1 and para. 0055, the web browser or other interfaces].
As per dependent claim 13, dependent claim 13 having the same scope as dependent claim 6, is rejected for the same reason/rationale as that of the above dependent claim 6.
As per dependent claim 7 the combination of MPC, Goel, Chiang and Verma discloses a method/system as applied to claim 1 above. Furthermore, MPC discloses the method further comprising: in response to the request to initiate the software container [[Page 355, second Column, Step 1 in Section V and figure 4 it describes receiving a request to initiate a container via the container engine. See pages 355-356], calling by a container runtime service, an operating system; and verifying, by the operating system [Page 353, see Linux Kernel Security Modules, Unix system/operating system contains two types of processes: privileged processes with user id 0 or root user and, unprivileged processes with nonzero user id or non-root. Privileged processes do not require passing all kernel permission checks while other unprivileged processes undergo through full permission check. Root privileges are further divided into different forms and named as Linux Capabilities. Linux kernel is central authority to enable or disable capabilities of the root], a user privilege for initiating a software container by the container runtime service, based on accessing the data in the Page 355, Second column, Steps 3 and figure 4, MPC checks the security profile to verify required privileges (e.g. root; non-root) for the container. See pages 355-356]; and verifying user privilege for each of a plurality of operations required to run applications in a software container [Page 355, Second column, Steps 5 and figure 4,, it describes Operations allowed are those defined in the policies; runtime monitoring ensures compliance. See pages 355-356];
MPC substantially discloses all the limitation but doesn’t explicitly disclose the following underlined or bolded claim limitation: “a user privilege for initiating a software container by the container runtime service, based on accessing the data in the ”
However Goel discloses; “a user privilege for initiating a software container by the container runtime service, based on accessing the data in the centralized security database and verifying user privilege for each of a plurality of operations required to run applications in a software container” [See Para. 0005 and para. 0042-0044 at least abstract, he disclosed computer-implemented method for running applications on a multi-tenant container platform may include (1) receiving, at a host administrator service on a container host computing device and via a host administrator service socket handle, a request for a privileged operation from an application running in a non-privileged container, (2) performing, based on a user identifier of the application, a security check of a user associated with the application, (3) comparing, when the security check results in approval, a process identifier of the requested privileged operation against a whitelist of permitted operations to determine the requested privileged operation is permissible, and (4) initiating running, when the requested privileged operation is permissible, the requested privileged operation.
MPC, Goel, Chiang and Verma are analogous/in the same field of endeavor as they all are directed to software container in a container runtime environment.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of MPC, Chiang and Verma with a mechanism such as “Centralized Security database” as per teaching Goel’s identity-based privilege control to enhance the security of the system by enforcing both identity and container specific privilege policies at execution time ant this provide robust access model for running application on a multi-tenant container platform. [See Goel, at least para. 0003 and para 0042-0044]
As per dependent claim 20, dependent claim 20 having the same scope as dependent claim 7, is rejected for the same reason/rationale as that of the above dependent claim 7.
As per dependent claim 14, dependent claim 14 having the same scope as dependent claim 7, and is rejected for the same reason/rationale as that of the above dependent claim 7. However dependent claim 14, has additional limitation, ” wherein the software container is started by a container runtime service that is separate from the centralized security database”
“Verma discloses the above underlined amended additional claim limitation:“the software container is started by a container runtime service [Container Runtime, “A container runtime or container engine is a software component responsible for executing and managing containers. Some of the main tasks it handles: container creation; container execution; resource isolation” Note: This teaches that a container runtime service whose responsible is to execute/start containers and meets the limitation, “the software container is started by a container runtime service”] that is separate [Process in the Worker Node, “As soon as the Kubelet receives this request from the API Server, it forwards the request to the Container Runtime component which is responsible for creating and managing the entire lifecycle of the actual containers itself” and See under the title, “Process in the Control Plane”, see also “ONLY the API Server talks to the ETCD component for storing the data". This collectively teaches that: the container runtime executes containers on worker nodes, and the centralized database(etcd) is accessed only by the API server in the control plane. Thus, the container runtime service is architecturally separate from the centralized database] from the centralized security data [See section, ETCD - The Cluster Database, “A Kubernetes Cluster has an internal database called etcd, which by default stores all the cluster data.” Note: This teaches a centralized database used by the cluster, which stores control-plane data including configuration and authorization objects]
9. Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Vivek Vijay Sarkale (NPL Publication, “Secure Cloud Container: Runtime Behavior Monitoring using Most Privileged Container (MPC) (herein after referred as MPC) (IEEE, 2017) in view of Vikas Goel (Goel) (US Pub. No. 2019/0273744A1) (Patent Date: Sep. 5, 2019) further in view of NPL document, titled, “Using RBAC, Generally Available in Kubernetes v1.8” by (Eric Chiang, Chiang) (October 28, 20217), and further in view of NPL document, titled, “Navigating the Kubernetes Architecture - A Comprehensive Guide” by (Kunal Verma, Verma) (October 2, 2023) and further in view of Eder et al (here in after referred as Eder) (US Patent No. 10.909,165 B2) (Feb. 2, 2021)
As per dependent claim 3, the combination of MPC, Goel, Chiang and Verma discloses a method/system as applied to claim 2 above. Furthermore, MPC discloses the method, wherein the data representing the one or more container privileges of operations required to run applications in the software containers corresponds to a privilege associated with each of the plurality of operations: including mounting of filesystems needed for containers, an ability to create namespaces, a network connection, and [ See section III, table 1, namespace, PID network mount) and Linux capabilities(CAP_SYS-ADMIN etc.) and file system separation see Linux kernel isolation mechanisms supported by MPC and see Goel para. 0017, methods for running applications on a multi-tenant container platform. In some examples, the systems and methods described herein may provide an ambassador-pattern-like extension to container implementation software (e.g., DOCKER) by adding application-specific functionality that mediates required privileged operations of applications such as mounting volumes and reduces security risks that result from privileged container models].
The combination of MPC, Goel, Chiang and Verma discloses all the limitation but doesn’t explicitly disclose the following underlined or bolded claim limitation: “”
However, Eder discloses; “an ability to change root file system directories when running inside a container [See at least abstract, a filesystem can be shared between containers. For example, a computing device having a host filesystem can launch a first container from an image file. Launching the first container can include creating an initialization directory for the first container on the host filesystem. The initialization directory can include a filesystem to be shared between containers. Launching the first container can also include creating a first filesystem directory for the first container on the host filesystem and mounting the initialization directory to the first filesystem directory. The computing device can also launch a second container from the image file. Launching the second container can include creating a second filesystem directory for the second container on the host filesystem and mounting the initialization directory to the second filesystem directory to enable the second container to access the filesystem]
MPC, Goel, Chiang, Verma and Eder are analogous/in the same field of endeavor as they all are directed to software container in a container runtime environment.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of MPC, Goel, Chiang and Verma by adding additional capability such as “an ability to change root file system directories when running inside a container ” as per teaching Eder to enhance the security of the system by providing isolation and enabling the containers to run applications at the same time, without the applications interfering with one another [See Eder, at least end of the Background]
As per dependent claim 10, dependent claim 10 having the same scope as dependent claim 3, is rejected for the same reason/rationale as that of the above dependent claim 3.
As per dependent claim 17, dependent claim 17 having the same scope as dependent claim 3, is rejected for the same reason/rationale as that of the above dependent claim 3.
Conclusion
10. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. US Patent No. 11275861 B2 Neitzel discloses process control software security architecture based on least privilege.
B. US Pub. No. 20240080277 A1, Lee discloses, a container networking interface of the data plane may configure network connections and allocate an IP address for the container. A container runtime of the data pane may generate and configure the container with the IP address and run the container within a micro-virtual machine that is compatible with the container orchestration platform.
C. US Publication No. 20140047272A1 Breternitz discloses “a workload container, which comprises one or more processors of a node executing a workload container module (e.g., software or firmware code), operates on each node. The workload container is an execution framework for workloads to provide a software environment that initiates and orchestrates the execution of workloads on a cluster of nodes”.
D. See the other cited prior arts.
11. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMSON B LEMMA whose telephone number is 571-272-3806. The examiner can normally be reached on M-F 8am-10pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Yin-Chen Shaw can be reached on 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SAMSON B LEMMA/Primary Examiner, Art Unit 2498