DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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) 2-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumatagi et al. (Pub 20200356397) (hereafter Kumatagi) in view of Wang et al. (Pub 20210240540) (hereafter Wang).
As per claim 2, Kumatagi teaches:
A virtualized computing system, comprising:
a host cluster having hypervisors being bare metal hypervisors directly executing on hardware platforms of hosts, each hypervisor supporting execution of virtual machines (VMs), the VMs including first VMs, the first VMs including container engines supporting execution of containers in the first VMs; ([Paragraph 99], For example, runV is capable of using existing hypervisors such as KVM, Xen, and ESXi. (i.e. bare-metal hypervisor) [Fig. 4] discloses plurality of hypervisors on plurality nodes running plurality of VMs. [Paragraph 15], Cloud compute resources are typically housed in large server farms that run one or more network applications, typically using a virtualized architecture wherein applications run inside a virtual server, or so-called “virtual machines” (VMs), that are mapped onto physical servers in a data center facility. The virtual machines typically run on top of a hypervisor, which is a control program that allocates physical resources to the virtual machines. Modern hypervisors often use hardware-assisted virtualization, which provides efficient and full virtualization by using virtualization-specific hardware capabilities, primarily from the host CPUs. [Paragraph 8], FIG. 5 illustrates a plurality of compute nodes at least one of which includes a plurality of containers, according to one or more embodiments. [Paragraph 22], One such approach involves isolating container execution using one or more virtual machines. In this approach, the container workloads are launched inside one or more virtual machines instead of regular cgroups-based containers.)
an orchestration control plane integrated with each hypervisor, the orchestration control plane including VM controllers, the VM controllers installed and executing in the hypervisors external to the VMs, the VM controllers configured to manage the VMs; and ([Paragraph 77], The compute nodes 602 may be managed by a container orchestration manager (COM) 610. In Kubernetes, for example, each compute node 602 contains services (i.e., node components) necessary to run one or more pods 608 and is managed by Kubernetes master components. The services on each compute node 602 may include the container runtime 604 (e.g., runC), an agent 612 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 610 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 610 may include at least a portion of one or more of the Kubernetes master components. [Paragraph 84], In Kubernetes, for example, each compute node 702 contains services (i.e., node components) necessary to run one or more pods and is managed by Kubernetes master components. The services on each compute node 702 may include the container runtime 704 (e.g., runV or other hypervisor-based runtime implementations of the OCI runtime specification), an agent 712 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 710 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 710 may include at least a portion of one or more of the Kubernetes master components.)
VM agents, executing in the first VMs, configured as agents of the VM controllers to manage the containers executing in the first VMs. ([Paragraph 69], Kubelet is an agent that makes sure that containers are running in a pod. The kubelet ensures that the containers specified in a set of PodSpecs provided through various mechanisms are running and healthy. [Paragraph 96], The services on each compute node 802 may include the container runtime 804 (e.g., runC), the hypervisor-based container runtime 805 (e.g., runV), an agent 812 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 811 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 811 may include at least a portion of one or more of the Kubernetes master components. [Paragraph 4-8], FIG. 1 depicts a cloud computing node, according to one or more embodiments. FIG. 4 illustrates a plurality of compute nodes at least one of which includes a plurality of virtual machines, according to one or more embodiments. FIG. 5 illustrates a plurality of compute nodes at least one of which includes a plurality of containers, according to one or more embodiments. [Paragraph 22], One such approach involves isolating container execution using one or more virtual machines. In this approach, the container workloads are launched inside one or more virtual machines instead of regular cgroups-based containers. )
Although Kumatagi discloses of agents (i.e. kubelets) to manage Kubernetes containers running/executing in VMs.
Kumatagi does not explicitly disclose VM agents, executing in the first VMs.
Wang teaches VM agents, executing in the first VMs. ([Paragraph 19], A node is a virtual machine (VM) or physical computer that serves as a “worker machine” having an agent (e.g., Kubernetes Kubelet) for managing the node and communicating with the master. Containerized applications can be deployed on top of a running cluster.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Kumatagi wherein plurality of nodes with corresponding hypervisors support execution of containers in VMs, orchestration control plane (container orchestration manager COM) is configured to manage containers/VMs with corresponding kubelets (i.e. agents) to manage containers, into teachings of Wang wherein VM agents (i.e. kubelets) are executing in VMs, because this would enhance the teachings of Kumatagi wherein by executing kubelets within VMs, it assists in management of plurality of containers deployed across servers to coordinate cluster nodes having a worker machine (i.e. agents/kubelets) for managing plurality of nodes. [Wang paragraph 18-19]
As per claim 3, rejection of claim 2 is incorporated:
Kumatagi teaches wherein the VMs include native VMs having guest operating systems executing therein, the guest operating systems isolated from the VM controllers. ([Paragraph 61], Each compute node 400 includes one or more virtual machines 401 each of which includes a guest operating system 403 and one or more application programs (or applications) 402 running on the guest operating system 403. [Paragraph 17], In addition, containers can run instructions native to the core CPU without any special interpretation mechanisms… [Paragraph 22], One such approach involves isolating container execution using one or more virtual machines. In this approach, the container workloads are launched inside one or more virtual machines instead of regular cgroups-based containers.)
As per claim 4, rejection of claim 2 is incorporated:
Kumatagi teaches further comprising a VM management server, wherein the orchestration control plane includes an application programming interface (API) server and a scheduler, and wherein: the API server is configured to create pods in response to specification data;
the scheduler is configured to select candidate hosts of the host cluster on which to schedule the pods and to provide the candidate hosts to the VM management server; and
the VM management server is configured to select one or more of the candidate hosts on which to deploy the pods. ([Paragraph 67], Master components provide the Kubernetes cluster's control plane (also referred to as “Kubernetes control plane”). Master components may include, but are not limited to, kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and cloud-controller-manager. Master components make global decisions about the Kubernetes cluster. For example, master components handle scheduling. In addition, master components are utilized in detecting and responding to cluster events. For example, master components are responsible for starting up a new pod when a replication controller's “replicas” field is unsatisfied. Master components can be run on any machine in the cluster. Nonetheless, set up scripts typically start all master components on the same machine, and do not run user containers on that machine. [Paragraph 59], For example, container management systems (e.g., Kubernetes, Docker Swarm) may be utilized for managing container lifecycle (Create, Read, Update, and Delete (CRUD) in a cluster-wide system. As a typical example, once a container creation request is received, a scheduler selects the host where requested container will run. Then, an agent in the selected host launches the container. It is to be appreciated that the terms “host” and “node” are used interchangeably herein to refer to a hardware apparatus or hardware system involving at the least, a processor, a memory, and a communication mechanism for interacting with other hosts/nodes. [Paragraph 64], “Kubernetes” is a portable, extensible open-source platform for managing containerized workloads and services. It facilitates both declarative configuration and automation. The Kubernetes project was open-sourced by Google in 2014. Kubernetes orchestrates computing, networking, and storage infrastructure on behalf of user workloads. Kubernetes is an example of an orchestration framework. Other orchestration frameworks include, but are not limited to, Docker Swarm, LXD, Rancher, and Apache Aurora/Mesos.)
As per claim 5, rejection of claim 4 is incorporated:
Kumatagi teaches wherein the orchestration control plane includes a controller, and wherein: the scheduler is configured to convert specifications of the pods into VM specifications; and the controller is configured to cooperate with the VM management server to deploy the first VMs having the VM specifications. ([Paragraph 67], Master components provide the Kubernetes cluster's control plane (also referred to as “Kubernetes control plane”). Master components may include, but are not limited to, kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and cloud-controller-manager. Master components make global decisions about the Kubernetes cluster. For example, master components handle scheduling. In addition, master components are utilized in detecting and responding to cluster events. For example, master components are responsible for starting up a new pod when a replication controller's “replicas” field is unsatisfied. Master components can be run on any machine in the cluster. Nonetheless, set up scripts typically start all master components on the same machine, and do not run user containers on that machine. [Paragraph 69], Kubelet is an agent that makes sure that containers are running in a pod. The kubelet ensures that the containers specified in a set of PodSpecs provided through various mechanisms are running and healthy.)
As per claim 6, rejection of claim 2 is incorporated:
Kumatagi teaches further comprising: a virtual infrastructure (VI) control plane having a network manager configured to manage software-defined (SD) networking for the host cluster and network agents, in the hypervisors, configured to cooperate with the network manager. ([Paragraph 77], The compute nodes 602 may be managed by a container orchestration manager (COM) 610. In Kubernetes, for example, each compute node 602 contains services (i.e., node components) necessary to run one or more pods 608 and is managed by Kubernetes master components. The services on each compute node 602 may include the container runtime 604 (e.g., runC), an agent 612 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 610 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 610 may include at least a portion of one or more of the Kubernetes master components. [Paragraph 55], Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75. [Paragraph 68], Node components run on every compute node in the Kubernetes cluster. Node components are responsible for maintaining running pods and providing the Kubernetes runtime environment. Node components may include, but are not limited to, kubelet, kube-proxy, and container runtime. [Paragraph 70], Kube-proxy is a network proxy. The kube-proxy enables the Kubernetes service abstraction by maintaining network rules on the compute node and performing connection forwarding.)
As per claim 7, rejection of claim 6 is incorporated:
Kumatagi teaches wherein the VM controllers are configured to: communicate with the network agents in the hypervisors to obtain network configurations for the pod VMs; communicate with image services in the hypervisors to obtain container images for the first VMs; and start the VM agents.
([Paragraph 77], The compute nodes 602 may be managed by a container orchestration manager (COM) 610. In Kubernetes, for example, each compute node 602 contains services (i.e., node components) necessary to run one or more pods 608 and is managed by Kubernetes master components. The services on each compute node 602 may include the container runtime 604 (e.g., runC), an agent 612 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 610 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 610 may include at least a portion of one or more of the Kubernetes master components. [Paragraph 55], Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75. [Paragraph 72], More generally, Kubernetes supports any implementation of the Container Runtime Interface (CRI) provided by Kubernetes. CRI enables a variety of container runtimes to be plugged in easily. Prior to the introduction of CRI in Kubernetes 1.5, only the default Docker image repository was used and its default OCI-compatible runtime, runC. The Open Container Initiative (OCI) created a runtime specification that details the API for an OCI-compatible container runtime. runC, runV, and Intel's Clear Containers (also known as “cc-runtime) are examples of OCI-compatible container runtimes. runC has built-in support for CRIU—checkpoint/restore in userspace, described below, to checkpoint and restore a container. runV is a hypervisor-based Docker runtime for OCI. runV is also referred to as “Hyper runV”. [Paragraph 59], For example, container management systems (e.g., Kubernetes, Docker Swarm) may be utilized for managing container lifecycle (Create, Read, Update, and Delete (CRUD) in a cluster-wide system. As a typical example, once a container creation request is received, a scheduler selects the host where requested container will run. Then, an agent in the selected host launches the container. It is to be appreciated that the terms “host” and “node” are used interchangeably herein to refer to a hardware apparatus or hardware system involving at the least, a processor, a memory, and a communication mechanism for interacting with other hosts/nodes.)
As per claim 8, rejection of claim 2 is incorporated:
Kumatagi teaches wherein the VM agents are configured to: start the containers; and report status of the containers to the VM controllers. ([Paragraph 59], For example, container management systems (e.g., Kubernetes, Docker Swarm) may be utilized for managing container lifecycle (Create, Read, Update, and Delete (CRUD) in a cluster-wide system. As a typical example, once a container creation request is received, a scheduler selects the host where requested container will run. Then, an agent in the selected host launches the container. It is to be appreciated that the terms “host” and “node” are used interchangeably herein to refer to a hardware apparatus or hardware system involving at the least, a processor, a memory, and a communication mechanism for interacting with other hosts/nodes. [Paragraph 75], Addons are pods and services that are responsible for implementing cluster features. Addons include, but are not limited to, cluster DNS (i.e., a DNS server which serves DNS records for Kubernetes services), Dashboard (i.e., web-based UI for Kubernetes clusters that allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself), Container Resource Monitoring (i.e., responsible for recording generic time-series metrics about containers in a central database, as well as providing a UI for browsing the data recorded in that database), and Cluster-level Logging (i.e., responsible for saving container logs to a central log store with a search/browse interface).)
As per claims 9, 11, 12 and 13, these are host computer claims corresponding to the virtualized computing system claims 2, 3, 6 and 8. Therefore, rejected based on similar rationale.
As per claim 10, rejection of claim 9 is incorporated:
Kumatagi teaches wherein the first VMs includes kernels, wherein the container engines and the VM agents execute on the kernels, and wherein the containers share the kernels of the first VMs. ([Paragraph 58], The compute nodes 400 of FIG. 4 include a plurality of exemplary system VMs, or full virtualization VMs, that provide a complete substitute for the targeted real machine and a level of functionality required for the execution of a complete operating system 403. The compute nodes 500 of FIG. 5 include a plurality of exemplary OS-level virtualization systems that allow the resources of a computer to be partitioned via the kernel's support for multiple isolated user space instances, which are usually called containers and may look and feel like real machines to the end users. Some embodiments of the present invention may be used with various types of virtualization. For example, some embodiments of the present invention may be used with management for virtual machines (such as OpenStack) and management for containers (such as Kubernetes). [Paragraph 21], Containers share the kernel with the host operating system… [Paragraph 59], Then, an agent in the selected host launches the container. It is to be appreciated that the terms “host” and “node” are used interchangeably herein to refer to a hardware apparatus or hardware system involving at the least, a processor, a memory, and a communication mechanism for interacting with other hosts/nodes.)
Wang teaches VM agents ([Paragraph 19], A node is a virtual machine (VM) or physical computer that serves as a “worker machine” having an agent (e.g., Kubernetes Kubelet) for managing the node and communicating with the master. Containerized applications can be deployed on top of a running cluster.)
As per claim 14, rejection of claim 9 is incorporated:
Kumatagi teaches wherein the hypervisor includes a virtual switch, and wherein virtual network interface cards (vNICs) of the first VMs are coupled to one or more logical networks implemented by the virtual switch. ([Paragraph 55], Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75. [Paragraph 125], The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers.)
As per claim 15, rejection of claim 14 is incorporated:
Kumatagi teaches wherein the VM controller is coupled to a server of the orchestration control plane through the virtual switch. ([Paragraph 55], Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75. [Paragraph 125], The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers.)
As per claim 16, Kumatagi teaches:
A method of container orchestration in a virtualized computing system including a host cluster having hypervisors being bare metal hypervisors directly executing on hardware platforms of hosts, the hypervisors supporting execution of virtual machines (VMs), the hypervisors including VM controllers of an orchestration control plane installed and executing therein external to the VMs, the method comprising: ([Paragraph 99], For example, runV is capable of using existing hypervisors such as KVM, Xen, and ESXi. (i.e. bare-metal hypervisor) [Fig. 4] discloses plurality of hypervisors on plurality nodes running plurality of VMs. [Paragraph 15], Cloud compute resources are typically housed in large server farms that run one or more network applications, typically using a virtualized architecture wherein applications run inside a virtual server, or so-called “virtual machines” (VMs), that are mapped onto physical servers in a data center facility. The virtual machines typically run on top of a hypervisor, which is a control program that allocates physical resources to the virtual machines. Modern hypervisors often use hardware-assisted virtualization, which provides efficient and full virtualization by using virtualization-specific hardware capabilities, primarily from the host CPUs. [Paragraph 8], FIG. 5 illustrates a plurality of compute nodes at least one of which includes a plurality of containers, according to one or more embodiments. [Paragraph 22], One such approach involves isolating container execution using one or more virtual machines. In this approach, the container workloads are launched inside one or more virtual machines instead of regular cgroups-based containers.
receiving, at the orchestration control plane, specification data for an application; and
deploying, based on the specification data, first VMs the VMs, the first VMs executing on the hypervisors and within one or more of the hosts, the first VMs including container engines supporting execution of containers in the first VMs, the first VMs executing VM agents configured as agents of the VM controllers to manage the containers executing in the first VMs. ([Paragraph 77], The compute nodes 602 may be managed by a container orchestration manager (COM) 610. In Kubernetes, for example, each compute node 602 contains services (i.e., node components) necessary to run one or more pods 608 and is managed by Kubernetes master components. The services on each compute node 602 may include the container runtime 604 (e.g., runC), an agent 612 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 610 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 610 may include at least a portion of one or more of the Kubernetes master components. [Paragraph 84], In Kubernetes, for example, each compute node 702 contains services (i.e., node components) necessary to run one or more pods and is managed by Kubernetes master components. The services on each compute node 702 may include the container runtime 704 (e.g., runV or other hypervisor-based runtime implementations of the OCI runtime specification), an agent 712 (e.g., kubelet) which listens for the instructions from the container orchestration manager (COM) 710 with regard to container lifecycle operations to be performed on that compute node, and a network proxy (e.g., kube-proxy). The container orchestration manager (COM) 710 may include at least a portion of one or more of the Kubernetes master components. [Paragraph 59], For example, container management systems (e.g., Kubernetes, Docker Swarm) may be utilized for managing container lifecycle (Create, Read, Update, and Delete (CRUD) in a cluster-wide system. As a typical example, once a container creation request is received, a scheduler selects the host where requested container will run. Then, an agent in the selected host launches the container. It is to be appreciated that the terms “host” and “node” are used interchangeably herein to refer to a hardware apparatus or hardware system involving at the least, a processor, a memory, and a communication mechanism for interacting with other hosts/nodes. [Paragraph 67], Master components provide the Kubernetes cluster's control plane (also referred to as “Kubernetes control plane”). Master components may include, but are not limited to, kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and cloud-controller-manager. Master components make global decisions about the Kubernetes cluster. For example, master components handle scheduling. In addition, master components are utilized in detecting and responding to cluster events. For example, master components are responsible for starting up a new pod when a replication controller's “replicas” field is unsatisfied. Master components can be run on any machine in the cluster. Nonetheless, set up scripts typically start all master components on the same machine, and do not run user containers on that machine. [Paragraph 69], Kubelet is an agent that makes sure that containers are running in a pod. The kubelet ensures that the containers specified in a set of PodSpecs provided through various mechanisms are running and healthy.)
Although Kumatagi discloses of agents (i.e. kubelets) to manage Kubernetes containers running/executing in VMs.
Kumatagi does not explicitly disclose VMs executing VM agents.
Wang teaches VMs executing VM agents. ([Paragraph 19], A node is a virtual machine (VM) or physical computer that serves as a “worker machine” having an agent (e.g., Kubernetes Kubelet) for managing the node and communicating with the master. Containerized applications can be deployed on top of a running cluster.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Kumatagi wherein plurality of nodes with corresponding hypervisors support execution of containers in VMs, orchestration control plane (container orchestration manager COM) is configured to manage containers/VMs with corresponding kubelets (i.e. agents) to manage containers, receive specification data and deploy VMs based on the specification data, into teachings of Wang wherein VM agents (i.e. kubelets) are executing in VMs, because this would enhance the teachings of Kumatagi wherein by executing kubelets within VMs, it assists in management of plurality of containers deployed across servers to coordinate cluster nodes having a worker machine (i.e. agents/kubelets) for managing plurality of nodes. [Wang paragraph 18-19]
As per claims 17 and 18, these are method claims corresponding to the system claims 4 and 5. Therefore, rejected based on similar rationale.
As per claim 19, rejection of claim 16 is incorporated:
Kumatagi teaches deploying, based on the specification data, a native VM of the VMs, the native VM executing on the hypervisors and including a guest operating system executing therein that is isolated from the VM controllers. ([Paragraph 61], Each compute node 400 includes one or more virtual machines 401 each of which includes a guest operating system 403 and one or more application programs (or applications) 402 running on the guest operating system 403. [Paragraph 17], In addition, containers can run instructions native to the core CPU without any special interpretation mechanisms… [Paragraph 22], One such approach involves isolating container execution using one or more virtual machines. In this approach, the container workloads are launched inside one or more virtual machines instead of regular cgroups-based containers. [Paragraph 11], FIG. 8 illustrates a container orchestration system that includes a plurality of compute nodes at least one of which includes a plurality of running containers, a hypervisor-based container runtime (e.g., runV) capable of launching a plurality of virtual machines, and checkpoint/restore in userspace (CRIU) utilized, in response to detection of a triggering factor, to live migrate the cgroups and namespaces of the running containers from the host to the plurality of virtual machines, according to one or more embodiments. [Paragraph 72], More generally, Kubernetes supports any implementation of the Container Runtime Interface (CRI) provided by Kubernetes. CRI enables a variety of container runtimes to be plugged in easily. Prior to the introduction of CRI in Kubernetes 1.5, only the default Docker image repository was used and its default OCI-compatible runtime, runC. The Open Container Initiative (OCI) created a runtime specification that details the API for an OCI-compatible container runtime. runC, runV, and Intel's Clear Containers (also known as “cc-runtime) are examples of OCI-compatible container runtimes. runC has built-in support for CRIU—checkpoint/restore in userspace, described below, to checkpoint and restore a container. runV is a hypervisor-based Docker runtime for OCI. runV is also referred to as “Hyper runV”. [Paragraph 69], Kubelet is an agent that makes sure that containers are running in a pod. The kubelet ensures that the containers specified in a set of PodSpecs provided through various mechanisms are running and healthy.)
As per claim 20, rejection of claim 16 is incorporated:
Kumatagi teaches provisioning, based on the specification data, a persistent volume in shared storage accessible by the host cluster, the persistent volume being attached to a VM of the first VMs. ([Paragraph 72], More generally, Kubernetes supports any implementation of the Container Runtime Interface (CRI) provided by Kubernetes. CRI enables a variety of container runtimes to be plugged in easily. Prior to the introduction of CRI in Kubernetes 1.5, only the default Docker image repository was used and its default OCI-compatible runtime, runC. The Open Container Initiative (OCI) created a runtime specification that details the API for an OCI-compatible container runtime. runC, runV, and Intel's Clear Containers (also known as “cc-runtime) are examples of OCI-compatible container runtimes. runC has built-in support for CRIU—checkpoint/restore in userspace, described below, to checkpoint and restore a container. runV is a hypervisor-based Docker runtime for OCI. runV is also referred to as “Hyper runV”. [Paragraph 69], Kubelet is an agent that makes sure that containers are running in a pod. The kubelet ensures that the containers specified in a set of PodSpecs provided through various mechanisms are running and healthy. [Paragraph 25], Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models. [Paragraph 55], Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.)
As per claim 21, rejection of claim 16 is incorporated:
Kumatagi teaches wherein the first VMs include kernels, wherein the container engines and the VM agents execute on the kernels, and wherein the containers share the kernels of the first VMs. ([Paragraph 58], The compute nodes 400 of FIG. 4 include a plurality of exemplary system VMs, or full virtualization VMs, that provide a complete substitute for the targeted real machine and a level of functionality required for the execution of a complete operating system 403. The compute nodes 500 of FIG. 5 include a plurality of exemplary OS-level virtualization systems that allow the resources of a computer to be partitioned via the kernel's support for multiple isolated user space instances, which are usually called containers and may look and feel like real machines to the end users. Some embodiments of the present invention may be used with various types of virtualization. For example, some embodiments of the present invention may be used with management for virtual machines (such as OpenStack) and management for containers (such as Kubernetes). [Paragraph 21], Containers share the kernel with the host operating system… [Paragraph 59], Then, an agent in the selected host launches the container. It is to be appreciated that the terms “host” and “node” are used interchangeably herein to refer to a hardware apparatus or hardware system involving at the least, a processor, a memory, and a communication mechanism for interacting with other hosts/nodes.)
Wang teaches VM agents ([Paragraph 19], A node is a virtual machine (VM) or physical computer that serves as a “worker machine” having an agent (e.g., Kubernetes Kubelet) for managing the node and communicating with the master. Containerized applications can be deployed on top of a running cluster.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights