DETAILED ACTION
This communication is in response to the application filed on 03/29/2024 in which claims 1-20 are pending in the application. Claims 1, 10, and 20 are in independent form.
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 .
Specification
The disclosure is objected to because of the following informalities:
¶ [0005] recites "Therefore ways to control asynchronous start up or asynchronous termination are developed" It appears "Therefore, ways to control asynchronous start up or asynchronous termination are developed" was intended.
¶ [0010] recites "Therefore ways to control asynchronous start up or asynchronous termination are developed" It appears "Therefore, ways to control asynchronous start up or asynchronous termination are developed" was intended.
¶ [0011] recites "Thus performance is improved and risk of dropped calls is mitigated" It appears "Thus, performance is improved and risk of dropped calls is mitigated " was intended.
¶ [0012] recites "During a waiting state a container is able to poll a file system of the host node to check for presence of a flag or to run a hyper text transfer protocol HTTP session with another container in the group" It appears "During a waiting state a container is able to poll a file system of the host node to check for presence of a flag or to run a hypertext transfer protocol HTTP session with another container in the group" was intended.
¶ [0012] recites " A container transitions from a waiting state to a running state in response to detecting a flag or other signal shared with another container in it’s group" It appears " A container transitions from a waiting state to a running state in response to detecting a flag or other signal shared with another container in its group" was intended.
¶ [0020] recites "The first container comprises an application with software instructions that cause the first container to write a flag to a specified location in a the shared volume when specified conditions are met" It appears “The first container comprises an application with software instructions that cause the first container to write a flag to a specified location in the shared volume when specified conditions are met" was intended.
¶ [0023] recites "The synch servers are hyper text transfer protocol HTTP servers or servers running any other protocol suitable for sending packets between containers" It appears “The synch servers are hypertext transfer protocol HTTP servers or servers running any other protocol suitable for sending packets between containers" was intended.
¶ [0023] recites “The second synch server 302 is a service running on the second container 108 which allows the second container 108 to send packets to and receive packets from the first container 108” It appears “The second synch server 304 is a service running on the second container 108 which allows the second container 108 to send packets to and receive packets from the first container 106” was intended.
¶ [0024] recites "However, in this example the flag is received at the second container 108 in a payload of a packet rather then retrieved from a shared volume" It appears “However, in this example the flag is received at the second container 108 in a payload of a packet rather than retrieved from a shared volume" was intended.
¶ [0050] recites "Alternatively or in addition to the other examples described herein, examples include any combination of the following clauses:" It appears “Alternatively, or in addition to the other examples described herein, examples include any combination of the following clauses:" was intended.
¶ [0064] recites "The method of any of clauses J to M wherein the first container is part of a data plane of a 5G telecommunications network, and the second container is part of a signaling plane of the 5G telecommunications network" It appears “The method of any of clause’s J to M wherein the first container is part of a data plane of a 5G telecommunications network, and the second container is part of a signaling plane of the 5G telecommunications network" was intended.
¶ [0067] recites "The method of any of clauses J to P wherein the flag is a file stored in a shared volume accessible by the first container and the second container, and wherein checking the flag comprises reading from the file in the shared volume and setting the flag comprises writing the file to the shared volume" It appears “The method of any of clause’s J to P wherein the flag is a file stored in a shared volume accessible by the first container and the second container, and wherein checking the flag comprises reading from the file in the shared volume and setting the flag comprises writing the file to the shared volume" was intended.
¶ [0068] recites "The method of any of clauses J to Q wherein the flag is a packet, and wherein checking the flag comprises sending a request from the first container to the second container, and wherein setting the flag comprises sending the packet from the second container to the first container" It appears “The method of any of clause’s J to Q wherein the flag is a packet, and wherein checking the flag comprises sending a request from the first container to the second container, and wherein setting the flag comprises sending the packet from the second container to the first container." was intended.
¶ [0069] recites "The method of any of clauses J to R wherein the first container and the second container are instantiated on one of bare metal and a virtual machine" It appears “The method of any of clause’s J to R wherein the first container and the second container are instantiated on one of bare metal and a virtual machine" was intended.
Appropriate correction is required.
Claim Objections
Claims 6, 13, and 16 are objected to because of the following informalities:
In claim 6, "wherein checking the flag comprises sending a request from the second container to the first container" should read "wherein checking the flag comprises sending the request from the second container to the first container."
In claim 13, "wherein completed state is communicated to a kubelet in the pod" should read "wherein the completed state is communicated to a kubelet in the pod."
In claim 16, "wherein the second container enters a completed state when all calls registered to the SBC are finished" should read "wherein the second container enters the completed state when all calls registered to the SBC are finished."
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 10, 12, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1).
As per claim 1, Kristiansson discloses:
A method for asynchronous startup of containers within a group of containers orchestrated by an orchestrator [¶ [0046], different instances of the same software container can execute in parallel on different servers to thereby achieve transient containers. In FIG. 1, a first software container 2a is in standby mode, i.e. initialised and ready to be allocated, on a first server 4a. In parallel, a second software container 2b is in standby mode on a second server 4b] (Examiner Note: Containers starting independently, in parallel, or without strict ordering is the core of asynchronous startup), [¶ [0023], System 100 is enabled to optimize and improve an efficiency of orchestrating container management with respect to hyperscale by embedding a supervisor tree process (code) into a container runtime for achieving fine grained pod lifecycle management such that processes are managed within a pod (across one or more container instances) and rule are integrated into external pod management functions that provided by Kubernetes] (Examiner Note: Kubernetes-based lifecycle control shows the containers are orchestrated by an orchestrator);
the method comprising: receiving a request to instantiate a group of containers comprising a first container and a second container [¶ [0080], Using this method, software containers can be initialised and set in a standby state, to prepare them and make the software containers ready to be started. Moreover, since the start parameter(s) are received in the start message, the software container can be configured to any suitable start configuration as the software container transitions from the standby state to the running state, when the main process is started. In this way, a pool of configuration neutral software containers can be initialised in advance, and configured when they are assigned], [¶ [0070], At the start of the process, there are three software containers: a first software container 2a, a second software container 2b and a third software container 2c, all in a standby state 20] (Examiner Note: three software containers: a first software container 2a, a second software container 2b and a third software container 2c, all in a standby state 20 refers to "instantiate a group of containers");
instantiating the first container [¶ [0071], the first software container 2a is selected for the client module 5 of the web server 15. The web server 15 then sends 27 a start message containing a start parameter, in this example ROOM_ID=345, which causes the first software container 2a to transition 28 from the standby state 20 to a running state 21] (Examiner Note: the first software container 2a is selected refers to "instantiating the first container");
instantiating the second container in the group and holding the second container in a waiting state [¶ [0072], Each software container can thus be in a state of not running (not shown), in a standby state 20 or in a running state 21, but only in one state at a time. Each software container can be allocated to only one session (or client) and after the client releases the software container, the execution of the software container ends and is not started again] (Examiner Note: Each software container can thus be in a state of not running (not shown), in a standby state 20 or in a running state 21 refers to "instantiating the second container" and standby state refers to "holding the second container in a waiting state");
in response to the flag being set, transitioning the second container to a running state [¶ [0039], The staging agent is used to manage the lifecycle of the software container, allowing the software container to move to a standby state and a running state], [¶ [0072], Each software container can thus be in a state of not running (not shown), in a standby state 20 or in a running state 21, but only in one state at a time. Each software container can be allocated to only one session (or client) and after the client releases the software container, the execution of the software container ends and is not started again)], [¶ [0071], The web server 15 then sends 27 a start message containing a start parameter, in this example ROOM_ID=345, which causes the first software container 2a to transition 28 from the standby state 20 to a running state 21] (Examiner Note: The flag corresponds to the start message that the staging agent waits for, and the container transitions to the running state once the trigger is received);
communicating the running state to the orchestrator [¶ [0039], The staging agent is used to manage the lifecycle of the software container, allowing the software container to move to a standby state and a running state] (Examiner Note: the lifecycle of the management by staging agent refers to "communicating the running state" and staging agent's lifecycle control is part of the orchestration system), [¶ [0039], Process injection can also be used to inject a process for an allocation agent and a staging agent in the software container. The allocation agent communicates with a container allocator 1 to assist in the allocation of software containers to one or more clients 5] (Examiner Note: The staging agent reports lifecycle changes and the allocation agent communicates container status upward, so the container’s running state is communicated to the orchestrator);
communicating the waiting state of the second container to the orchestrator [¶ [0039], The staging agent is used to manage the lifecycle of the software container, allowing the software container to move to a standby state and a running state] (Examiner Note: the lifecycle of the management by staging agent refers to "communicating the waiting state" and staging agent's lifecycle control is part of the orchestration system), [¶ [0039], Process injection can also be used to inject a process for an allocation agent and a staging agent in the software container. The allocation agent communicates with a container allocator 1 to assist in the allocation of software containers to one or more clients 5] (Examiner Note: The staging agent reports lifecycle changes and the allocation agent communicates container status upward, so the container’s waiting state is communicated to the orchestrator).
Kristiansson discloses the claimed invention as detailed above but does not explicitly teach:
where the second container will rely on a service run by the first container;
checking periodically for a flag from the first container;
setting the flag in response to the first container running the service;
However, Caine discloses:
checking periodically for a flag from the first container [¶ [0032], Specification code 435 enables an application developer to declare differing application status flags and associated container management health actions (e.g., stop container, restart container, pause traffic to container, restart traffic to container, etc.)], [¶ [0032], an intra-pod-orchestrator component (enabled via specification code 435) orchestrates each container supervisor tree code instance to enable processes across different containers to be orchestrated and coordinated. Each node agent 427 is configured to performs container lifecycle management actions with respect to a status action declaration];
setting the flag in response to the first container running the service [¶ [0032], Specification code 435 enables an application developer to declare differing application status flags and associated container management health actions (e.g., stop container, restart container, pause traffic to container, restart traffic to container, etc.)] (Examiner Note: Specification code 435 enables an application developer to declare differing application status flags refers to "setting the flag", and associated container management health actions refers to "in response to the flag being set").
Both Kristiansson and Caine are in the same field of endeavor and they are both in container orchestration systems, and therefore are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson to include periodically checking for a flag from the first container and acting when the flag is set as taught by Caine because using a simple status flag to coordinate container behavior is a predictable and well-understood way to manage dependent container startup.
Motivation would be to improve overall system reliability and coordinated container behavior because using status flags allows dependent containers to detect readiness, synchronize their startup, and transition states in a controlled manner as taught by Caine [¶ 0032].
The combination of Kristiansson and Caine discloses the claimed invention as detailed above but does not explicitly teach:
where the second container will rely on a service run by the first container;
However, Isci discloses:
where the second container will rely on a service run by the first container [¶ [0064], there can be ten containers running and containers of the ten containers can comprise respective services, which can be different from one another. For example, a first container can run a first service, a second container can run a second service, a third container can run a third service, and so on, where the first service, the second service, and the third service can be different services], [¶ [0044 – 0045], If the service is in a compliance state, the service can be available for use. The use of the service can be determined based on a balancing algorithm. For example, the balancing algorithm can be a round-robin balancing algorithm or another balancing algorithm. Alternatively, if the first determination is that the service is in a non-compliance state, the extraction component 106 can remove the service from a load balancer ring. Thus, request traffic for the service is not routed to the service that is determined to be in the non-compliance state After a defined period of time, the verification component 104 can perform a second determination to determine the compliance status of the service. As an example, the defined period of time can be expressed as minutes (e.g., 5 minutes, 10 minutes, 20 minutes), as hours (e.g., one hour, three hours, six hours), or another interval determined to be sufficient for an instance of a service, or a container, to be repaired and/or its status changed to be in compliance with one or more policies].
Kristiansson, Caine, and Isci are in the same field of endeavor and they are both in container-based distributed systems, and therefore are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson and Caine to include having the second container rely on a service provided by the first container as taught by Isci because coordinating container behavior through a service dependency is a routine and predictable design choice in containerized system.
Motivation would be to improve dependent-container coordination and overall system performance because allowing one container to rely on a service provided by another enables orderly startup sequencing and reduces failures caused by unmet service dependencies as taught by Isci [¶ 0064].
As per claim 2, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1.
Caine discloses:
The method of claim 1, wherein the orchestrator is a Kubernetes orchestrator, and the group of containers is a pod of containers [¶ [0016], System 100 enables intra-pod interaction such that Kubernetes are configured to orchestrates pods by orchestrating processes within a pod (across one or more container instances). Rules for orchestrating processes within a pod are integrated into external pod management functions executed via Kubernetes] (Examiner Note: Kubernetes are configured to orchestrate pods… refers to "Kubernetes orchestrator" and pods… orchestrating processes within a pod (across one or more container instances) refers to the "group of containers").
As per claim 3, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1 and 2.
Kristiansson discloses:
The method of claim 2, wherein the waiting state and running state are communicated to a kubelet in the pod [¶ [0009], initialising execution of the software container in the server; setting the software container in a standby state; receiving a start message from a remote device, the start message comprising at least one start parameter for the software container; and starting a main process of the software container and applying the at least one start parameter for the main process, to progress the software container to a running state].
As per claim 10, the claim is rejected using the same rationale as noted above for claim 1.
As per claim 12, the claim is rejected using the same rationale as noted above for claim 2.
As per claim 20, the claim is rejected using the same rationale as noted above for claim 1.
Claim 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1) and in further view of Novlan (US 20200374839 A1).
As per claim 4, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1 but does not explicitly teach:
The method of claim 1, wherein the first container is part of a data plane of a telecommunications network and the second container is part of a signaling plane of the telecommunications network.
However, Novlan discloses:
The method of claim 1, wherein the first container is part of a data plane of a telecommunications network [¶ [0034], 3GPP NR-based 5G mobile networks can be deployed using a split RAN protocol architecture such that on the user plane the packet data convergence protocol (PDCP)] (Examiner Note: In 5G networks, the user plane operates as the data plane, and the PDCP layer corresponds to the first container because it handles user-plane data processing)
and the second container is part of a signaling plane of the telecommunications network [¶ [0053], User plane data can be carried on data radio bearers (DRBs) that traverse the above described user plane RAN protocol architecture. On the control plane, signaling radio bearers (SRBs) can be set up to carry control messages from the radio resource control (RRC) layer, also utilize the packet data control protocol (PDCP) layer at the CU, and are further carry the control messages down through the RLC] (Examiner Note: The signaling radio bearers (SRBs) operate on the control plane and use the PDCP layer to carry RRC control messages, which corresponds to the second container being part of the signaling plane because the control plane is the signaling plane and SRBs represent signaling-plane functionality).
Kristiansson, Caine, Isci, and Novlan are in the same field of endeavor as they are all directed to virtualized network-function deployment and containerized telecommunications systems and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, and Isci to include where the first container belongs to the data plane and the second container belongs to the signaling plane as taught by Novlan in order to separate data handling from signaling.
Motivation would be to improve 5G container-orchestration performance by placing the first container within the data-plane functions of the 5G network, ensuring faster user-plane processing and more efficient coordination with signaling-plane components as taught by Novlan [¶ [0034]].
As per claim 14, the claim is rejected using the same rationale as noted above for claim 4.
Claim(s) 5 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1) and in further view of Lehr (US 20100228708 A1).
As per claim 5, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1 but does not explicitly teach:
the method of claim 1, wherein the flag is a file stored in a shared volume accessible by the first container and the second container, and wherein checking the flag comprises reading from the file in the shared volume and setting the flag comprises writing the file to the shared volume.
However, Lehr discloses:
The method of claim 1, wherein the flag is a file stored in a shared volume accessible by the first container and the second container [¶ [0026], where data sets 84a . . . 84n contained within a container data set 78a may have the same high order bits 104 of the container data set name], and
wherein checking the flag comprises reading from the file in the shared volume [¶ [0026], where data sets 84a . . . 84n contained within a container data set 78a may have the same high order bits 104 of the container data set name. The entry 120 in the virtual file allocation catalog 80 may include the full name of the data sets 84a . . . 84n or the lower order bits 102 of the name, to distinguish the names of data sets within a container data set having the same high order bits. The address range 124 comprises a range of addresses allocated to the data set and a virtual container flag 126 indicates whether the data set identified in the entry 120 in the file allocation catalog 12 comprises a container data set] (Examiner Note: entry 120 in the virtual file allocation catalog 80 or virtual container flag 126 refers to "checking the flag" and container data set 78, data sets 84a . . . 84n, and virtual file allocation catalog 80 refers to "shared volume" file behavior)
setting the flag comprises writing the file to the shared volume [¶ [0026], where data sets 84a . . . 84n contained within a container data set 78a may have the same high order bits 104 of the container data set name, (Examiner Note: data sets 84a . . . 84n contained within a container data set 78a refers to "setting the flag" and writing a data set into the container data set (78a) refers to "writing the file")].
Kristiansson, Caine, Isci, and Lehr are in the same field of endeavor as they are all directed to container-orchestration and container-state management systems and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, and Isci to include where the flag is a file in a shared volume that both containers can access, and checking it means reading the file while setting it means writing to it as taught by Lehr in order to have the containers coordinate by reading and writing a common file.
Motivation would be to improve synchronization and state-sharing between containers by reliably updating the shared-volume file so both containers can access the most current state information; therefore, enhancing orchestration accuracy and overall system performance as taught by Lehr [¶ [0026]].
As per claim 17, the claim is rejected using the same rationale as noted above for claim 5.
Claim(s) 6-8, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1) and Lehr (US 20100228708 A1) and in further view of Shu (US 20190059117 A1).
As per claim 6, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1.
Kristiansson discloses:
wherein checking the flag comprises sending a request from the second container to the first container [¶ [0041], FIG. 1, a first software container 2a is in standby mode, i.e. initialised and ready to be allocated, on a first server 4a. In parallel, a second software container 2b is in standby mode on a second server 4b. The second software container 2b is an instance of the same image which is used for the first software container 2a];
The combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1 but does not explicitly teach:
The method of claim 1, wherein the flag is a packet sent from the first container to the second container;
wherein setting the flag comprises sending the packet from the first container to the second container.
However, Lehr discloses:
wherein setting the flag comprises sending the packet from the first container to the second container [¶ [0026], where data sets 84a . . . 84n contained within a container data set 78a may have the same high order bits 104 of the container data set name] (Examiner Note: Specification mention that flag is a file [¶ [0055]] and a packet [¶ [0026]).
Kristiansson, Caine, Isci, and Lehr are in the same field of endeavor as they are all directed to container-based orchestration systems and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, and Isci to include where setting the flag means the first container sends a packet to the second container as taught by Lehr in order to have one container signal another during coordination.
Motivation would be to improve container to container signaling performance by allowing the first container to indicate readiness through lightweight packet exchange as taught by Lehr [¶ [0026]].
The combination of Kristiansson, Caine, Isci, and Lehr discloses the claimed invention as detailed above but does not explicitly teach:
The method of claim 1, wherein the flag is a packet sent from the first container to the second container.
However Shu discloses:
The method of claim 1, wherein the flag is a packet sent from the first container to the second container [¶ [0072], configuring the first host to generate the connectivity check packet to include an inner header that is addressed from the first virtualized computing instance to the second virtualized computing instance, an outer header that is addressed from the first host to the second host and a connectivity check packet flag] (Examiner Note: Specification mention that flag is a file [¶ [0055]] and a packet [¶ [0026].
Kristiansson, Caine, Isci, Lehr, and Shu are in the same field of endeavor as they are all directed to container-orchestration and inter-container communication system and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, Isci, and Lehr to include where the flag is a packet that the first container sends to the second container as taught by Shu in order to have one container to signal another during coordination.
Motivation would be to improve inter-container communication and orchestration responsiveness by using a packet-based flag that can be transmitted directly between container; therefore, enabling faster and more reliable state signaling as taught by Shu [¶ [0072]].
As per claim 7, the combination of Kristiansson, Caine, Isci, Lehr, and Shu discloses the claimed invention as detailed above for claim 1 and 6.
Shu discloses:
The method of claim 6, wherein the packet is sent from a first server in the first container to a second server in the second container [¶ [0072], configuring the first host to generate the connectivity check packet to include an inner header that is addressed from the first virtualized computing instance to the second virtualized computing instance, an outer header that is addressed from the first host to the second host and a connectivity check packet flag].
As per claim 8, the combination of Kristiansson, Caine, Isci, Lehr, and Shu discloses the claimed invention as detailed above for claim 1, 6, and 7. Kristiansson discloses:
The method of claim 7, wherein the first server and the second server are hypertext transport protocol (HTTP) servers [¶ [0069], A browser client 16 creates a new video conference room by sending a HTTP (Hypertext Transfer Protocol) request 26 to a web server 15] (Examiner Note: Hypertext Transfer Protocol refers to "hypertext transport protocol").
As per claim 18, the claim is rejected using the same rationale as noted above for claim 6.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1) and in further view of Liguori (US 20230093925 A1).
As per claim 9 and 19, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1 but does not explicitly teach:
The method of claim 1, wherein the first container and the second container are instantiated on one of bare metal and a virtual machine.
However, Liguori discloses:
The method of claim 1, wherein the first container and the second container are instantiated on one of bare metal and a virtual machine [¶ [0014], Though each container runs isolated processes, multiple containers can share a common operating system, for example by being launched within the same virtual machine. In contrast, virtual machines are an abstraction of the hardware layer (meaning that each virtual machine simulates a physical machine that can run software). Virtual machine technology can use one physical server to run the equivalent of many servers (each of which is called a virtual machine). While multiple virtual machines can run on one physical machine, each virtual machine typically has its own copy of an operating system, as well as the applications and their related files, libraries, and dependencies. Virtual machines are commonly referred to as compute instances or simply “instances.” Some containers can be run on instances that are running a container agent, and some containers can be run on bare-metal servers] (Examiner Note: the specification recites in [¶ [0059]] that bare metal refers to a physical computing node such as a server).
Kristiansson, Caine, Isci, and Liguori are in the same field of endeavor and they are both in container-based computing systems, and therefore are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, and Isci to include instantiating the first and second containers on either bare metal or a virtual machine as taught by Liguori in order to improve flexibility and performance.
Motivation would be to improve deployment flexibility and system performance because allowing containers to run on either bare metal or virtual machine enables resource allocation and more efficient scaling as taught by Liguori [¶ [0014].
As per claim 19, the claim is rejected using the same rationale as noted above for claim 9.
Claim(s) 11, 13, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1) and in further view of Brezinsky (US 20170308361 A1).
As per claim 11, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1 and 10 but does not explicitly teach:
The method of claim 10, wherein the flag is set, in response to the second container entering a completed state.
However, Brezinsky discloses:
The method of claim 10, wherein the flag is set, in response to the second container entering a completed state [¶ [0103] a container that is consistent with at least some embodiments of the present disclosure is to “kill” the container after a single call application has been completed (e.g., after the application enters a “finished” state)].
Kristiansson, Caine, Isci, and Brezinsky are in the same field of endeavor as they are all directed to container-orchestration systems and container-lifecycle management and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, Isci, and Lehr to include where the flag is set when the second container reaches a complete state as taught by Brezinsky in order to signal that a container has finished its work making it an obvious coordination step for the system.
Motivation would be to improve orchestration accuracy and overall system performance by updating the flag precisely when the second container finishes its task; therefore, ensuring downstream components react only after completion as taught by Brezinsky [¶ [0103]].
As per claim 13, the combination of Kristiansson, Caine, and Isci discloses the claimed invention as detailed above for claim 1, 10, and 12.
Caine discloses:
The method of claim 12, wherein completed state is communicated to a kubelet in the pod [¶ [0023], a node agent (e.g., a kubelet for Kubernetes) executes container lifecycle management actions with respect to a status action declaration enabled via container supervisor tree code].
As per claim 16, the combination of Kristiansson, Caine, Isci, and Brezinsky discloses the claimed invention as detailed above for claim 1, 10, and 14.
Brezinsky discloses:
The method of claim 15, wherein the second container enters a completed state when all calls registered to the SBC are finished [¶ [0103], a container that is consistent with at least some embodiments of the present disclosure is to “kill” the container after a single call application has been completed (e.g., after the application enters a “finished” state)].
Claim 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kristiansson (US 20190146833 A1) and Caine (US 20220374282 A1) and Isci (US 20190124144 A1) and Brezinsky (US 20170308361 A1)and in further view of Tylee (US 20220365854 A1).
As per claim 15, the combination of Kristiansson, Caine, Isci, and Brezinsky discloses the claimed invention as detailed above for claim 1, 10, 14, and 16 but does not explicitly teach:
The method of claim 14, wherein the first container and the second container form a session border controller (SBC) in the telecommunications network.
However, Tylee discloses:
The method of claim 14, wherein the first container and the second container form a session border controller (SBC) in the telecommunications network [¶ [0109], A method according to any preceding clause, wherein at least one of the first active virtual machine and the second active virtual machine provides a session border controller, SBC, function in the telecommunications network], [¶ [0103], the virtualised environment 300 comprises first and second VMs 302a, 304a. In alternative embodiments, the virtualised environment comprises one or more containers. VMs and containers are examples of virtual workloads].
Kristiansson, Caine, Isci, Brezinsky, and Tylee are in the same field of endeavor as they are all directed to virtualized network-function deployment and containerized telecommunications systems and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the system of Kristiansson, Caine, Isci, and Brezinsky to include where the two containers together operate as a session border controller in the network as taught by Tylee because to provide session border controller functions by distributing them cross two coordinated containers.
Motivation would be to improve telecommunications network performance by allowing the containers to jointly provide SBC functionality, enabling more efficient session handling and signaling coordination as taught by Tylee [¶ 0109, ¶ 0103].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dontu (US 11556372 B2) teaches “receiving, at a supervisor container orchestrator, a request for a first persistent volume lifecycle operation from a guest container orchestrator” (Abstract).
Beard (US 11720382 B2) teaches “the pod VM including a container engine supporting execution of containers in the pod VM” (Col. 15: 28-30).
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially Page 14 Application/Control Number: 18/582,274 Art Unit: 2198 teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tien Tram whose telephone number is (571) 270-3050. The examiner can normally be reached Mon-Fri, 8:00a-4:00p. 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, Pierre M. Vital can be reached at (571)272-4215. 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.
/TIEN THANH TRAM/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights