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 . This office Action is in response to claims filed 03/12/2024.
Claims 1-20 are pending
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 7-8, 13, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hui et al. Pub. No. CN 115185628 A (hereafter HUI), citations below correspond to English Translation provided, in view of Tellez et al. Pub. No. US 2018/0091449 A1 (hereafter Tellez).
With regards to Claim 1, Hui teaches deploying a pod with at least one container on a container instance (“the cluster automatically schedules the pod to the virtual node for creation” and that “the virtual node calls the service of the container instance, creates a corresponding container instance according to the network information of the cluster and the mirror image of the pod”) (Page 2, line 32), and that “changes the pod on the virtual node into a running state”.
Hui also teaches updating a status of the pod (“the virtual node updates the pod state after the container instance operation is finished” (Page 4, Line 11)). Hui does not teach one or more non-transitory computer readable media comprising instructions which, when executed by one or more hardware processors, cause performance of operations, or subscribing to an event stream associated with the container instance, the event stream comprising container events corresponding to the container instance; consuming the container events from the event stream associated with the container instance; or updating the pod status based on the container events from the event stream associated with the container instance.
However, in analogues art, Tellez teaches (“a non-transitory computer readable medium is provided to store instructions, which when executed by a computing device, cause the computing device to perform a method” [0010] and “the computing device includes hardware 105 comprising a set of one or more processor(s) 111” and “non-transitory machine-readable storage media 113 having stored therein software,” and that “the processor(s) 111 execute the software”) [0031].
Tellez also teaches subscribing to an event stream associated with the container instance, the event stream comprising container events corresponding to the container instance (“the event service receives a subscriber request to subscribe for events of a container” [0009] and that “the events include information about changes to the state of at least one of the set of containers” [0008]. Tellez also states “events are generated for life-cycle changes of a container” [0018].
Tellez further teaches consuming the container events from the event stream associated with the container instance (“Once authenticated, a subscriber will be automatically forwarded events from the container” ([0038]) and “the events received from the container and/or application are then forwarded to the subscriber” [0055]).
Tellez further teaches updating the status based on the container events from the event stream associated with the container instance (“the embodiments provide subscribers with real-time state information for each container”) [0018]. This teaching of Tellez is directed to the status of an individual container, not the status of a pod as a whole. But Hui teaches that pod status is derived from the container instance created for that pod, since “(“the virtual node updates the pod state after the container instance operation is finished” (Page 4, Line 11)). So, because Hui’s pod status tracks the status of its underlying container instance, updating that container-level status via Tellez’s event-driven notifications would, in the combined system, result in updating a status of the pod based on the container events from the event stream associated with the container instance.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the event-driven subscription and notification architecture of Tellez with the pod and container instance management system of Hui. The result is a system in which Hui’s pod status is updated in response to container events received via an event stream, rather than by running a status-check command like Hui’s own “kubecect get node-show-labels” query to determine the running state.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of providing real-time pod status update while reducing resource overhead of continuously polling for status, as Tellez teaches “polling and querying create additional load on the resources of the system in comparison to the automated streaming” (¶ [0025]).
With regards to claim 7, Hui in view of Tellez teaches the non-transitory media of Claim 1.
Hui teaches a virtual agent that monitors and manages containers (the Virtual kubelet provides a series of interfaces in the provider, and the methods are called when a pod is created, deleted, updated and the like” (Page 7, Line 32) and that “Virtual Kubelet can implement the following functions: create, delete, update pod…monitoring of containers, obtaining status of single or multiple pods” (Line 11, Page 5))”). Under the broadest reasonable interpretation, Hui’s virtual kubelet corresponds to the claimed virtual agent.
Hui further teaches that this virtual agent launches a plurality of container instances (“deploying a mirror image of a virtual kubelet at a master node of a cluster” involves “creating a virtual node in the cluster” (Page 2, Line 25), and separately “the cluster automatically schedules the pod to the virtual node for creation” and that “and the virtual node calls the service of the container instance, creates a corresponding container instance according to the network information of the cluster and the mirror image of the pod”) (Line 4, Page 6). Hui’s virtual node, not virtual kubelet itself, is what calls the container instance service to create the container instance. But the virtual node itself created by the virtual kubelet’s own deployment step in the first place, so under BRI it’s just really an extension of the kubelet. The virtual node’s act of creating a container instance is therefore attributed to the virtual kubelet that created it. Hui’s virtual kubelet manages pod scheduling across the whole cluster, not just a single pod, so it launches a plurality of container instances in this manner, including the container instance of claim 1.
Hui does not teach the event stream is associated with a virtual agent, that the event stream is associated with a plurality of container instances launched by the virtual agent including the container instance, or that the subscribing operation is performed by the virtual agent.
However, in analogues art, Tellez teaches that containers monitoring results are organized as an event stream, as discussed above in claim 1; the event service (“the event service receives a subscriber request to subscribe for events of a container” [0008] and that “Once successfully subscribed, a two-way connection is opened between subscriber 20 and event service… to send and receive data” [0046]). Tellez’s subscriber is generic process in communications with the platform, not a named virtual agent, and Tellez does not itself teach a virtual kubelet or any component that launches container instances.
Combining the two references closes this gap. Hui’s virtual kubelet is the component already monitoring and managing the container instances on the platform. Tellez teaches that monitoring results for those same containers are organized into an event stream a subscriber can subscribe to. Since the kubelet is what launches and tracks the container instances generating that stream, the combined system teaches that event stream is associated with a virtual agent. For the same reason, the combined system teaches that the event stream is associated with a plurality of container instances launched by the virtual agent including the container instance. And because the kubelet is the component already positioned to track the container instances it manages, the combined system teaches that the subscribing operation is performed by the virtual agent.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to combine the event subscription mechanism taught by Tellez with the virtual kubelet architecture of Hui, resulting in a system in which Hui’s virtual kubelet itself performs the subscripting operation to receive events for the container instances it manages, rather than requiring a separate monitoring component.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting the virtual kubelet directly receive up-to-date container information without an additional intermediary component, as Hui already teaches that the virtual kubelet is responsible for “obtaining status of single or multiple pods” (Line 11, Page 5).
With regards to claim 8, Hui in view of Tellez teaches the non-transitory media of Claim 7.
Hui further teaches the updating operation is also performed by the virtual agent (“the virtual node updates the pod state after the container instance operation is finished” and that “the virtual node calls a corresponding container instance service interface after receiving various operations on the pod” (Line 24, Page 8)).
Hui’s virtual node, not the virtual kubelet itself, is what updates the pod state. But as discussed above with respect to claim 7, the virtual node is created by the virtual kubelet’s own deployment step, so under the broadest reasonable interpretation it operates as an extension of the kubelet. The virtual node’s act of updating the pod state should therefore be attributed to the virtual kubelet that created it, the same way the virtual node’s act of creating the container instance was attributed to the kubelet of claim 7. Thus, Hui teaches that the updating operation is performed by the virtual agent.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to have the same kubelet that performs the subscribing operation of claim 7 also perform the updating operation, resulting in a system where both the event subscription and the pod status update happen within the same virtual agent.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of keeping the container’s reported status consistent with its actual execution state, as Hui already teaches that (“the virtual node updates the pod state after the container instance operation is finished” (Line 24, Page 8)).
With regards to Claim 13, Hui teaches deploying a pod with at least one container on a container instance (“the cluster automatically schedules the pod to the virtual node for creation” and that “the virtual node calls the service of the container instance, creates a corresponding container instance according to the network information of the cluster and the mirror image of the pod”) (Page 2, line 32), and that “changes the pod on the virtual node into a running state”.
Hui also teaches updating a status of the pod (“the virtual node updates the pod state after the container instance operation is finished” (Page 4, Line 11)). Hui does not teach a method comprising, or subscribing to an event stream associated with the container instance, the event stream comprising container events corresponding to the container instance; consuming the container events from the event stream associated with the container instance; or updating the pod status based on the container events from the event stream associated with the container instance.
However, in analogues art, Tellez teaches (“a non-transitory computer readable medium is provided to store instructions, which when executed by a computing device, cause the computing device to perform a method” [0010] and “the computing device includes hardware 105 comprising a set of one or more processor(s) 111” and “non-transitory machine-readable storage media 113 having stored therein software,” and that “the processor(s) 111 execute the software”) [0031].
Tellez also teaches subscribing to an event stream associated with the container instance, the event stream comprising container events corresponding to the container instance (“the event service receives a subscriber request to subscribe for events of a container” [0009] and that “the events include information about changes to the state of at least one of the set of containers” [0008]. Tellez also states “events are generated for life-cycle changes of a container” [0018].
Tellez further teaches consuming the container events from the event stream associated with the container instance (“Once authenticated, a subscriber will be automatically forwarded events from the container” ([0038]) and “the events received from the container and/or application are then forwarded to the subscriber” [0055]).
Tellez further teaches updating the status based on the container events from the event stream associated with the container instance (“the embodiments provide subscribers with real-time state information for each container”) [0018]. This teaching of Tellez is directed to the status of an individual container, not the status of a pod as a whole. But Hui teaches that pod status is derived from the container instance created for that pod, since “(“the virtual node updates the pod state after the container instance operation is finished” (Page 4, Line 11)). So, because Hui’s pod status tracks the status of its underlying container instance, updating that container-level status via Tellez’s event-driven notifications would, in the combined system, result in updating a status of the pod based on the container events from the event stream associated with the container instance.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the event-driven subscription and notification architecture of Tellez with the pod and container instance management system of Hui. The result is a system in which Hui’s pod status is updated in response to container events received via an event stream, rather than by running a status-check command like Hui’s own “kubecect get node-show-labels” query to determine the running state.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of providing real-time pod status update while reducing resource overhead of continuously polling for status, as Tellez teaches “polling and querying create additional load on the resources of the system in comparison to the automated streaming” (¶ [0025]).
With regards to claim 19, Hui in view of Tellez teaches the method of Claim 13.
Hui teaches a virtual agent that monitors and manages container (the Virtual kubelet provides a series of interfaces in the provider, and the methods are called when a pod is created, deleted, updated and the like” (Page 7, Line 32) and that “Virtual Kubelet can implement the following functions: create, delete, update pod…monitoring of containers, obtaining status of single or multiple pods” (Line 11, Page 5))”). Under the broadest reasonable interpretation, Hui’s virtual kubelet corresponds to the claimed virtual agent.
Hui further teaches this virtual agent launches a plurality of container instances (“deploying a mirror image of a virtual kubelet at a master node of a cluster” involves “creating a virtual node in the cluster” (Page 2, Line 25), and separately “the cluster automatically schedules the pod to the virtual node for creation” and that “and the virtual node calls the service of the container instance, creates a corresponding container instance according to the network information of the cluster and the mirror image of the pod”) (Line 4, Page 6). Hui’s virtual node, not virtual kubelet itself, is what calls the container instance service to create the container instance. But the virtual node itself created by the virtual kubelet’s own deployment step in the first place, so under BRI it’s just really an extension of the kubelet. The virtual node’s act of creating a container instance is therefore attributed to the virtual kubelet that created it. Hui’s virtual kubelet manages pod scheduling across the whole cluster, not just a single pod, so it launches a plurality of container instances in this manner.
Hui does not teach the event stream is associated with a virtual agent, that the event stream is associated with a plurality of container instances launched by the virtual agent including the container instance, or that the subscribing operation is performed by the virtual agent.
However, in analogues art, Tellez teaches that containers monitoring results are organized as an event stream, as discussed above in claim 13; the event service (“the event service receives a subscriber request to subscribe for events of a container” [0008] and that “Once successfully subscribed, a two-way connection is opened between subscriber 20 and event service… to send and receive data” [0046]). Tellez’s subscriber is generic process in communications with the platform, not a named virtual agent, and Tellez does not itself teach a virtual kubelet or any component that launches container instances.
Combining the two references closes this gap. Hui’s virtual kubelet is the component already monitoring and managing the container instances on the platform. Tellez teaches that monitoring results for those same containers are organized into an event stream a subscriber can subscribe to. Since the kubelet is what launches and tracks the container instances generating that stream, the combined system teaches that event stream is associated with a virtual agent. For the same reason, the combined system teaches that the event stream is associated with a plurality of container instances launched by the virtual agent including the container instance. And because the kubelet is the component already positioned to track the container instances it manages, the combined system teaches that the subscribing operation is performed by the virtual agent.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to combine the event subscription mechanism taught by Tellez with the virtual kubelet architecture of Hui, resulting in a system in which Hui’s virtual kubelet itself performs the subscripting operation to receive events for the container instances it manages, rather than requiring a separate monitoring component.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting the virtual kubelet directly receive up-to-date container information without an additional intermediary component, as Hui already teaches that the virtual kubelet is responsible for “obtaining status of single or multiple pods” (Line 11, Page 5).
With regards to Claim 20, Hui in view of Tellez teaches a system comprising: at least one device including a hardware processor (“each of the computing devices includes hardware 105 comprising a set of one or more processor(s) 111” [0031]).
The system being configured to perform operations comprising: deploying a pod with at least one container on a container instance. Hui teaches (“the cluster automatically schedules the pod to the virtual node for creation” and that “the virtual node calls the service of the container instance, creates a corresponding container instance according to the network information of the cluster and the mirror image of the pod”) (Page 2, line 32), and that “changes the pod on the virtual node into a running state” after the creation succeeds.
Hui does not teach subscribing to an event stream associated with the container instance, the event stream comprising container events corresponding to the container instance.
However, in analogues art, Tellez teaches subscribing to an event stream associated with the container instance, the event stream comprising container events corresponding to the container instance (“receiving, at the event service, a subscriber request to subscribe for events of a container” and that “the events include information about changes to the state of at least one of the set of containers”; Tellez ([0018]) states “events are generated for life-cycle changes of a container”).
Tellez further teaches consuming the container events from the event stream associated with the container instance (“Once authenticated, a subscriber will be automatically forwarded events from the container” ([0038]) and “the events received from the container and/or application are then forwarded to the subscriber” [0055]).
Tellez further teaches updating the status based on the container events from the event stream associated with the container instance (“the embodiments provide subscribers with real-time state information for each container”) [0018]. This teaching of Tellez is directed to the status of an individual container, not the status of a pod as a whole. But Hui teaches that pod status is derived from the container instance created for that pod, since “(“the virtual node updates the pod state after the container instance operation is finished” (Page 4, Line 11)). So, because Hui’s pod status tracks the status of its underlying container instance, updating that container-level status via Tellez’s event-driven notifications would, in the combined system, result in updating a status of the pod based on the container events from the event stream associated with the container instance.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the event-driven subscription and notification architecture of Tellez with the pod and container instance management system of Hui. The result is a system in which Hui’s pod status is updated in response to container events received via an event stream, rather than by whatever status-detection mechanism Hui otherwise employs.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of providing real-time pod status update while reducing resource overhead of continuously polling for status, as Tellez teaches “polling and querying create additional load on the resources of the system in comparison to the automated streaming” (¶ [0025]).
Claim(s) 2, 11-12, and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hui in view of Tellez, further in view of Mueller et al. Pub. No. US 2021/0311757 Al (hereafter Mueller).
With regards to Claim 2, Hui in view of Tellez teaches the non- transitory media of claim 1.
As established in claim 1, Tellez teaches wherein the operations further comprise: consuming the container events from the event stream (“Once authenticated, a subscriber will be automatically forwarded events from the container” ([0038]) and “the events received from the container and/or application are then forwarded to the subscriber” [0055]). Tellez’s own architecture confirms this consuming mechanism is not limited to a single event type “The subscription can in some cases also identify the types of events for which notification is requested, which can be any subset of the entire set of possible event types in a given platform” [0054]).
Also as established in claim 1, Tellez and Hui teach updating the status of the pod based on the container events from the event stream. Tellez states that (“the embodiments provide subscribers with real-time state information for each container”) [0018], and Hui states (“the virtual node updates the pod state after the container instance operation is finished” (Page 4, Line 11)). Tellez’s real time state information is what teaches the subscriber and triggers a status update. Hui’s pod status derives from the container instance’s status. So notification delivered through Tellez’s mechanism results in updating the pod’s status.
Hui and Tellez do not teach the event stream further comprises hypervisor events corresponding to the container instance.
However, in analogous art, Mueller teaches that (“a hypervisor-VM channel is used to enable communication between pod VM controller 154 and all of pod VMs 130 that are managed by pod VM controller 154” and that “when an introspection command for a target container is received by pod VM controller 154, pod VM controller 154 determines the pod VM hosting the target container and forwards the introspection command to pod VM agent 136” [0020]).
Mueller doesn’t use the terms “hypervisor event” or “event stream”. But Mueller states that (“Hypervisor 150 includes a host daemon 152 and a pod VM controller 154” [0015] so pod VM controller 154 is part of hypervisor itself, not a separate component. Mueller’s adds “pod VM agent 136 (more generally referred to as the" container management process" [0016], and pod VM 154 “forwards the introspection command to pod VM agent 136” [0020]) a container management component tied to the container instance. Under the broadest reasonable, those communications read on hypervisor events corresponding to the container instance.
Incorporating Mueller’s hypervisor-originated communications into the event-stream architecture already taught by Hui and Tellez results in a system wherein the event stream further comprises hypervisor events corresponding to the container instance.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to combine Mueller’s hypervisor-to-container- communication channel with the event-driven pod and container instance management system of Hui and Tellez, resulting in a system where the event stream consumed by Hui’s pod management system further comprise hypervisor events corresponding to the container instance.
A person of ordinary skill in the art would have been motivated to make this combination for the purpose of providing a communication path between the hypervisor and the container management process that doesn’t depend on network availability as Mueller teaches that its hypervisor-VM channel “circumvents the network layer and it allows applications to work when network access is restricted or unavailable” [0019].
With regards to claim 11, Hui, Tellez, and Mueller teach the non-transitory media of Claim 1.
Hui and Tellez do not teach that the status of the pod is updated on a container orchestration API server.
However, in analogues art, Mueller teaches this (“Kubernetes master 104 is a physical or virtual server that manages Kubernetes objects 106” and it “schedules pods onto…different hosts…and updates the status of Kubernetes objects 106”. Mueller also states that “kubect1…is a command line interface to a Kubernetes API server, depicted in FIG. 2 as "Kubernetes master” [0021]). So, Mueller directly identifies the Kubernetes master as a Kubernetes API server, not just a generic management system.
Mueller further teaches that (“The pod VM controllers of the different hosts 120 periodically poll Kubernetes master 104…and execute tasks to bring the actual state of the pods to the desired state” (¶0014). Under the broadest reasonable interpretation, the Kubernetes role in tracking and updating pod status, combined with its identification as Kubernetes API server, teaches the claimed container orchestration API server on which pod status is updated.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to update pod status on a centralized API server like Mueller’s Kubernetes master, rather than only locally at virtual node, resulting in a system where pod status is tracked centrally while node-level components synchronize actual pod to state.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of giving a single, authoritative source for pod status across the cluster, as Mueller teaches that node-level component already “periodically poll Kubernetes master 104…to bring the actual state of the pods to the desired state”.
With regards to claim 12, Hui, Tellez, and Mueller teach the non-transitory media of Claim 1.
Hui and Tellez do no teach that the container instance comprises a virtual machine that executes a container.
However, in analogues art, Mueller teaches (the hypervisor supports a virtual machine execution space within which multiple VMs may be concurrently instantiated and executed” and “the VMs…include pod VMs 130, which also function as Kubernetes pods” (¶0011)). Mueller further supports “Each pod VM 130 has one or more containers 132 running therein in an execution space managed by container runtime 134” and that “the lifecycle of containers 132 is managed by pod VM agent 136” (¶0016). So, Mueller’s pod VM is a virtual machine that runs one or more containers inside it.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to implement Hui’s container instance as a pod VM the way Mueller teaches, resulting in a container instance that itself is a virtual machine executing one or more containers.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of isolating each pod’s container within its own virtual machine boundary, as Mueller teaches that each pod VM has “the lifecycle of containers…managed by pod VM agent 136” running inside that VM [0016].
With regards to Claim 14, Hui in view of Tellez teaches the method of Claim 13. As discussed in claim 13, Hui in view of Tellez further teaches consuming events from the event stream and updating the status of the pod based on the events from the event stream (that mechanism doesn’t depend on what type of events the event stream carries).
Hui and Tellez do not teach the event stream further comprises hypervisor events corresponding to the container instance.
However, in analogues art, Mueller teaches hypervisor-originated communications corresponding to hypervisor events associate with the container instance (“a hypervisor-VM channel is used to enable communication between pod VM controller 154 and all of pod VMs 130 that are managed by pod VM controller 154” and that “communication over the hypervisor-VM channel is governed by the so-called virtual sockets protocol” [0019]). Mueller adds that “when an introspection command for a target container is received by pod VM controller 154, pod VM controller 154 determines the pod VM hosting the target container and forwards the introspection command to pod VM agent 136” ([0020).
Mueller doesn’t use the terms “hypervisor event” or “event stream”. But Mueller states that (“Hypervisor 150 includes a host daemon 152 and a pod VM controller 154” [0015] so pod VM controller 154 is part of hypervisor itself, not a separate component. Mueller’s adds “pod VM agent 136 (more generally referred to as the" container management process" [0016], and pod VM 154 “forwards the introspection command to pod VM agent 136” [0020]) a container management component tied to the container instance. Under the broadest reasonable, those communications read on hypervisor events corresponding to the container instance.
Incorporating Mueller’s hypervisor-originated communications into the event-stream architecture already taught by Hui and Tellez results in a system wherein the event stream further comprises hypervisor events corresponding to the container instance. And because Hui and Tellez already teach consuming events from the event stream and updating the pod’s status based on those events regardless of event type, adding hypervisor events to the stream’s content means that same mechanism now also results in consuming the hypervisor events from the event stream and updating the status of the pod based on the hypervisor events from the event.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to combine Mueller’s hypervisor-to-container- communication channel with the event-driven pod and container instance management system of Hui and Tellez. The result is a system in which the event stream consumed by Hui’s pod management system further comprises hypervisor events corresponding to the container instance, and pod status is updated based on those hypervisor events in addition to container events.
A person of ordinary skill in the art would have been motivated to make this combination for the purpose of providing a communication path between the hypervisor and the container management process that doesn’t depend on network availability as Mueller teaches that its hypervisor-VM channel “circumvents the network layer and it allows applications to work when network access is restricted or unavailable” [0019].
Claim(s) 3-4 and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over HUI in view of Tellez, further in view of Mueller, further in view of Rimac et al. Pub. No US 2019/0012218 Al (hereafter Rimac).
With regards to Claim 3, Hui, Tellez, and Mueller teach the non-transitory media of Claim 2.
Hui in view of Tellez teaches that a container instance service that launched the container instance transmits the container events corresponding to the container instance to the event stream. Hui states that “the virtual node calls the service of the container instance, [the container instance] creates a corresponding container instance” (Page 2, line 32), so Hui’s container instance service is the entity that launched the container instance. Tellez teaches that this kind of entity transmits events to the event stream (“events are emitted by the platform component services 50 at various stages of changes in the state of containers 70 controlled by the platform 30” [0041], and “the component services of the platform 30 publish events at various stages of the implementation of the received request…are published to a message bus 90, which is used by the event service 80 to capture these events” [0046]). Under BRI, Hui’s container instance service is a component service of the kind Tellez describes, since it is the component responsible for the container instance’s creation and operation. So the combined system teaches that the container instance service transmits the container events corresponding to the container instance to the event stream.
Hui, Tellez, and Mueller do not teach that the container instance service transmits the hypervisor events corresponding to the container instance to a second event stream, or that a management plane transmits the hypervisor events corresponding to the container instance from the second event stream to the event stream.
However, in analogues art, Rimac teaches container instance service transmits the hypervisor events corresponding to the container instance to a second event stream and that a management plane transmits the hypervisor events corresponding to the container instance from the second event stream to the event stream. As to the second event stream, Rimac’s message bus is configured (“to receive, by the message bus for the event type, an event of the event type that is published to the message bus” [0004], without restricting which component acts as the publisher for a given event type. Rimac’s global event queues store events that “await transfer to the [local message buses] of the [edge cloud nodes] and, eventually, processing by hosts” [0068], a stream of events separate from the local queue a host actually pulls from. Under BRI, the container instance service already established above can publish to this global stream the same way any component publishes to Rimac’s message bus by event type, so that the hypervisor events Mueller’s pod VM controller generates for the container instance get transmitted, by the container instance service, to this second, global stream.
As to the management plane, Rimac’s local event dispatcher “receive events from the [global event queues] …and to dispatch the events to the [local event queues] for storage…while the events await transfer to the hosts…to be processed” [0073]). So, the dispatcher functions as a management level component that moves events out of the second, global stream and into the local stream the host consumes from.
Under the broadest reasonable interpretation, Rimac’s uses generic “event type A” and “event type B” labels rather than “hypervisor” or “container”. However, the claim requires a second, distinct event stream whose contents get moved into the primary stream. Rimac’s global-local queue structure does that.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to incorporate Rimac’s global-to-local event queue architecture into the combined system of Hui, Tellez, and Mueller. This results in a system where a hypervisor events, transmitted by the container instance service to a second event stream, rather than being written to the primary stream directly.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of separating event storage from event distribution, so a single stream can serve multiple distributed consumers, as Rimac teaches that its global queues hold events “await transfer to the [local message buses] of the [edge cloud nodes] and, eventually, processing by hosts”.
With regard to claim 4, Hui, Tellez, Mueller, and Rimac teach the non-transitory media of Claim 3.
Rimac further teaches a predefined rule requires forwarding of the hypervisor events corresponding to the container instance to the event stream, and the hypervisor events corresponding to the container instance are forwarded from the second event stream to the event stream based on the predefined rule (“based on a local queuing policy of the host and a local event retrieval condition detected at the host” [0057], and that hosts control “selection of events from the event buffers…based on the host-specific event selection policies” [0041]). Rimac also describes a scoring mechanism where the message bus calculates (“a score on these two metrics for each queue… dispatching incoming events to the queue that has the highest score” [0085]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to govern Rimac’s event transfer using the queuing policies and scoring-based dispatch Rimac describes, rather than transferring events unconditionally. This results in a system where hypervisor events move from second event stream to the event stream only when the policy’s conditions are met.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing processing delay, as Rimac teaches that dispatching to the highest queue “will minimize the latencies for the corresponding service or application for which events of the event type are being handled”.
With regards to Claim 15, Hui, Tellez, and Mueller teach the method Claim 14.
Hui in view of Tellez teaches that a container instance service that launched the container instance transmits the container events corresponding to the container instance to the event stream. Hui states that “the virtual node calls the service of the container instance, [the container instance] creates a corresponding container instance” (Page 2, line 32), so Hui’s container instance service is the entity that launched the container instance. Tellez teaches that this kind of entity transmits events to the event stream (“events are emitted by the platform component services 50 at various stages of changes in the state of containers 70 controlled by the platform 30” [0041], and “the component services of the platform 30 publish events at various stages of the implementation of the received request…are published to a message bus 90, which is used by the event service 80 to capture these events” [0046]). Under BRI, Hui’s container instance service is a component service of the kind Tellez describes, since it is the component responsible for the container instance’s creation and operation. So the combined system teaches that the container instance service transmits the container events corresponding to the container instance to the event stream.
Hui, Tellez, and Mueller do not teach that the container instance service transmits the hypervisor events corresponding to the container instance to a second event stream, or that a management plane transmits the hypervisor events corresponding to the container instance from the second event stream to the event stream.
However, in analogues art, Rimac teaches both limitations. As to the second event stream, Rimac’s message bus is configured (“to receive, by the message bus for the event type, an event of the event type that is published to the message bus” [0004], without restricting which component acts as the publisher for a given event type. Rimac’s global event queues store events that “await transfer to the [local message buses] of the [edge cloud nodes] and, eventually, processing by hosts” [0068], a stream of events separate from the local queue a host actually pulls from. Under BRI, the container instance service already established above can publish to this global stream the same way any component publishes to Rimac’s message bus by event type, so that the hypervisor events Mueller’s pod VM controller generates for the container instance get transmitted, by the container instance service, to this second, global stream.
As to the management plane, Rimac’s local event dispatcher “receive events from the [global event queues] …and to dispatch the events to the [local event queues] for storage…while the events await transfer to the hosts…to be processed” [0073]). So, the dispatcher functions as a management level component that moves events out of the second, global stream and into the local stream the host consumes from.
Under the broadest reasonable interpretation, Rimac’s uses generic “event type A” and “event type B” labels rather than “hypervisor” or “container”. However, the claim requires a second, distinct event stream whose contents get moved into the primary stream. Rimac’s global-local queue structure does that.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to incorporate Rimac’s global-to-local event queue architecture into the combined system of Hui, Tellez, and Mueller. This results in a system where a hypervisor events, transmitted by the container instance service to a second event stream, rather than being written to the primary stream directly.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of separating event storage from event distribution, so a single stream can serve multiple distributed consumers, as Rimac teaches that its global queues hold events “await transfer to the [local message buses] of the [edge cloud nodes] and, eventually, processing by hosts”.
With regard to claim 16, Hui, Tellez, Mueller, and Rimac teach the method of Claim 15.
Rimac further teaches a predefined rule requires forwarding of the hypervisor events corresponding to the container instance to the event stream, and the hypervisor events corresponding to the container instance are forwarded from the second event stream to the event stream based on the predefined rule (“based on a local queuing policy of the host and a local event retrieval condition detected at the host” [0057], and that hosts control “selection of events from the event buffers…based on the host-specific event selection policies” [0041]). Rimac also describes a scoring mechanism where the message bus calculates (“a score on these two metrics for each queue… dispatching incoming events to the queue that has the highest score” [0085]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to govern Rimac’s event transfer using the queuing policies and scoring-based dispatch Rimac describes, rather than transferring events unconditionally. This results in a system where hypervisor events move from second event stream to the event stream only when the policy’s conditions are met.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing processing delay, as Rimac teaches that dispatching to the highest queue “will minimize the latencies for the corresponding service or application for which events of the event type are being handled”
Claim(s) 5 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hui in view of Tellez, further in view of Mueller, further in view of Mani et al. Pub. No. US 2019/0286475 Al.
With regards to claim 5, Hui, Tellez, and Mueller teach the non-transitory media of Claim 2, as discussed above.
Hui, Tellez, and Mueller as discussed in claim 2, also teach that at least some of the hypervisor events correspond to different events of the container instance. Mueller states that (“examples of introspection commands include "exec" to execute a command inside the target container while the target container is running, "attach" to hook up to standard input-output channels of the target container while the target container is running, and "port-forward" to establish a bidirectional communication channel with the target container while the target container is running” [0023]) three distinct types of hypervisor originated commands directed at the container instance.
Hui, Tellez, and Mueller do not teach that at least some of the hypervisor events correspond to planned maintenance of the container instance.
However, in analogues art, Mani teaches hypervisor events that correspond to planned maintenance of a virtual machine (the service provider may implement a migration management function 350 that is configured to identify when an event is detected that is associated with maintenance of a virtual machine [0043], and that “the event that is detected may be any command, request or other data that indicates that a shutdown/restart is in progress at a virtual machine or is scheduled to occur” [0045]. Mani further teaches “when a virtual machine is migrated for scheduled maintenance, the resulting downtime, while known in advance, will nevertheless require loss of use while the virtual machine is shut down and migrated” [0003]).
As the specification disclose that the container instance is a virtual machine that executes a containerized application [0020], therefore Mani’s teaching of scheduled maintenance shutdown/restart events detected with respect to virtual machine corresponds to hypervisor events that correspond to planned maintenance of the container.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to further modify the combined system of Hui, Tellez, and Mueller so that at least some of the hypervisor events include scheduled maintenance events taught by Mani, resulting in which pod status is updated based on hypervisor events that include planned maintenance.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting the pod management system anticipate scheduled downtime before as it happens, as Mani teaches that scheduled maintenance downtime, “while in advance,” still causes “loss of use while the virtual machine is shut down and migrated”.
With regards to claim 17, Hui, Tellez, and Mueller teach the method of Claim 14.
Hui, Tellez, and Mueller as discussed in claim 14, also teach that at least some of the hypervisor events correspond to different events of the container instance. Mueller states that (“examples of introspection commands include "exec" to execute a command inside the target container while the target container is running, "attach" to hook up to standard input-output channels of the target container while the target container is running, and "port-forward" to establish a bidirectional communication channel with the target container while the target container is running” [0023]) three distinct types of hypervisor originated commands directed at the container instance.
Hui, Tellez, and Mueller do not teach that at least some of the hypervisor events correspond to planned maintenance of the container instance.
However, in analogues art, Mani teaches hypervisor events that correspond to planned maintenance of a virtual machine (the service provider may implement a migration management function 350 that is configured to identify when an event is detected that is associated with maintenance of a virtual machine [0043], and that “the event that is detected may be any command, request or other data that indicates that a shutdown/restart is in progress at a virtual machine or is scheduled to occur” [0045]. Mani further teaches “when a virtual machine is migrated for scheduled maintenance, the resulting downtime, while known in advance, will nevertheless require loss of use while the virtual machine is shut down and migrated” [0003]).
As the specification disclose that the container instance is a virtual machine that executes a containerized application [0020], therefore Mani’s teaching of scheduled maintenance shutdown/restart events detected with respect to virtual machine corresponds to hypervisor events that correspond to planned maintenance of the container.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to further modify the combined system of Hui, Tellez, and Mueller so that at least some of the hypervisor events include scheduled maintenance events taught by Mani, resulting in which pod status is updated based on hypervisor events that include planned maintenance.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting the pod management system anticipate scheduled downtime before as it happens, as Mani teaches that scheduled maintenance downtime, “while in advance,” still causes “loss of use while the virtual machine is shut down and migrated”.
Claim(s) 6 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hui in view of Tellez, further in view of Vijendra et al. Pub. No. US 2019/0391897 Al.
With regards to claim 6, Hui in view of Tellez teaches the non-transitory media of Claim 1.
Hui and Tellez do no teach that subscribing to the event stream associated with the container instance comprises subscribing to a stream partition, of the event stream, associated with the container instance.
However, in analogues art, Vijendra teaches “the broker 606 may organize the container metrics in topics, where the container metrics data collector 604 acts as a producer which pushes messages into topics stored in partitions with particular offsets” [0052], and that “614 may subscribe to the container metrics by pulling messages by topic, partition and offset” [0054]. So, Vijendra’s stream processing framework subscribes to a specific partition of the broker’s stream to receive metrics for the container it monitors.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to have Tellez’s subscriber subscribe to a specific partition of the event stream the way Vijendra teaches, rather than to the stream as a whole, resulting in a system were subscribing to the event stream associated with the container instance means subscribing to the specific partition carrying that container instance’s events.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting a subscriber receive only the events relevant to the container instances it manages rather than every event on the stream, as Vijendra teaches that its broker organizes container metrics “into topics stored in partitions with particular offsets” so a consumer can pull specific partitioned data rather than the whole stream [0052].
With regards to claim 18, Hui in view of Tellez, further in view of Vijendra teaches the method of Claim 13.
Hui and Tellez do no teach that subscribing to the event stream associated with the container instance comprises subscribing to a stream partition, of the event stream, associated with the container instance.
However, in analogues art, Vijendra teaches “the broker 606 may organize the container metrics in topics, where the container metrics data collector 604 acts as a producer which pushes messages into topics stored in partitions with particular offsets” [0052], and that “614 may subscribe to the container metrics by pulling messages by topic, partition and offset” [0054]. So, Vijendra’s stream processing framework subscribes to a specific partition of the broker’s stream to receive metrics for the container it monitors.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to have Tellez’s subscriber subscribe to a specific partition of the event stream the way Vijendra teaches, rather than to the stream as a whole, resulting in a system where subscribing to the event stream associated with the container instance means subscribing to the specific partition carrying that container instance’s events.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting a subscriber receive only the events relevant to the container instances it manages rather than every event on the stream, as Vijendra teaches that its broker organizes container metrics “into topics stored in partitions with particular offsets” so a consumer can pull specific partitioned data rather than the whole stream [0052].
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hui in view of Tellez, further in view of Murthy et al. Pub. No US 2016/0219089 Al (hereafter Murthy).
With regards to claim 9, Hui in view of Tellez teaches the non-transitory media of Claim 7.
Hui and Tellez do not teach the virtual agent includes multiple virtual agent replicas, or that the subscribing operation is performed by the virtual agent replicas.
However, in analogues art, Murthy teaches multiple virtual agent replicas (“embodiments deploy multiple CEP engines in a cluster and deployed on a number of devices” and that “the cluster can selfheal in case of a CEP engine failures or a specific instance becoming busy” [0030]). Murthy further teaches (“the messaging system can identify a number of consumer devices (e.g., forming a "consumer cluster ring") available to receive and process messages on a given topic that a producer device generates” and that “The producer device maintains a registry of the consumer devices that have been identified as having subscribed to the topic” [0043]). Murthy’s clustered CEP engines and consumer devices each perform the same event consumption role, so under the broadest reasonable interpretation, they teach a plurality of virtual agent replicas.
Murthy further teaches the subscribing operation is performed by the virtual agent replicas (“the consumer-facing sub-module(s) provides an interface for consumer devices…to provide advertisement data for indicating topics to which the consumer devices request to subscribe” [0060]) and that “the consumer device 402 interfaces with the messaging service 406 and invokes an API call to an example function subscribe(topic)” [0071]). Each consumer device in Murthy’s cluster independently calls this subscribe function, so the subscribing operation is performed by each of the replicas, not just a single instance.
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to replace the single virtual kubelet of Hui with the clustered, replica-based architecture taught by Murphy, resulting in a system where multiple virtual agent replicas each perform the subscribing operation taught by Tellez.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of avoiding a single point of failure in the virtual agent, as Murthy teaches that its clustered arrangement can “selfheal in case of an CEP engine failures or a specific instance becoming busy” [0030]).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hui in view of Tellez, further in view of Chen et al. Pub. No US 2024/0028368 Al.
With regards to claim 10, Hui in view of Tellez teaches the non-transitory media of Claim 7.
Hui and Tellez do not teach that the virtual agent identifies the event stream to a container instance service that launched the container instance.
However, in analogues art, Chen teaches this structure using two separate components. Chen states (“an edge agent can be executed in the private network with the edge hypervisor” and “can subscribe to a topic identifier associated with the edge hypervisor shadow” [0011], where “the topic identifier registered to the edge hypervisor shadow 203 can be referred to as a "hypervisor shadow" topic identifier” [0043]). The edge agent’s subscription to that specific topic identifies, to the message broker routing the shadow’s publication, which streams the shadow’s messages should reach it through.
Hui and Tellez also do not teach the container instance transmits the container events to the identified event stream.
Chen further states “the edge hypervisor shadow 203 can publish this message to the topic or topic identifier to which the edge agent 206 subscribes according to the subscription data 212” [0048] so it is the shadow, a component separate from the agent, that transmits to the topic the agent identified by subscribing to it.
Under BRI, the edge agent corresponds to the virtual agent (Hui’s virtual kubelet, established above with claim 7), and the edge hypervisor shadow corresponds to the container instance service (Hui’s container instance service, established above with claim 3).
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to modify the combined system of Hui and Tellez so that Hui’s virtual kubelet identifies a specific event stream by subscribing to it, and Hui’s container instance service publishes container events to the event stream the virtual kubelet identified for it, rather than to a generically fixed stream.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of letting a single virtual kubelet manage and route events for multiple container instances to their own separately identified streams, as Chen teaches that topic identifies are individually registered per component so that “the message broker service can identify” which streams messages belongs to [0042].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20180121264 A1
Teaches
Retrying even stream by re-pulling the stream
US 20230297592 A1
Teaches
Stream partition based on which system component the data responds to
US 20160055045 A1
Teaches
Hypervisor level infrastructure that detects faults and relays faults notification
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEZMURE DAWIT whose telephone number is (571)270-5581. The examiner can normally be reached Mon-Fri 7:30am-5pm. 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 571-272-3338. 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.
/MEZMURE DAWIT/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights