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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/08/2024 and 05/15/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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.
Claims 1, 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Benjaponpitak et al ” Enabling Live Migration of Containerized Applications Across Clouds”, hereafter Benjaponpitak in view of Kondo (US 20210294632 A1), hereafter Kondo.
Regarding claim 1, Benjaponpitak teaches:
A container migration device which migrates a container that conducts data processing from a migration source apparatus to a migration destination apparatus, (Page 2529, Abstract we focus on the design and implementation of live migration of containers across cloud providers. CloudHopper, our proof-of-concept live migration ser vice for containers to hop around between Amazon Web Services, Google Cloud Platform, and Microsoft Azure is evaluated using a common web-based workload.)
the migration source apparatus being an apparatus in which a migration source container and a migration source proxy operate, the migration destination apparatus being an apparatus in which a migration destination container and a migration destination proxy operate, (Page 2533, Container images are placed at the target before migration to set the persistent storage’s initial state. HAProxy is also set up on both sides to forward traffic to the application. Refer back to Figure 1 for the initial state before a migration takes place. E.N: Benjaponpitak teaches a source container and destination containers with proxies on both side to forward and receive requests.)
and transferring the received data to the migration source container being a request destination container, to a queuing mode of saving the data instead of transferring, (Page 2532. In our system, we build a web application to hold connections called the holding application and use HAProxy [33] to handle redirection. HAProxy is already used to handle incoming connections at the host to support multiple container networking as to be discussed later in Section IV-A2. During normal operations, HAProxy would forward incoming client connections to the web server container. However, during migration, new incoming client connections are instead for warded from HAProxy to the holding application. the HAProxy instance on the source host will also be polling the target backend, so the remaining connections in its own queue will also be automatically dispatched to the (now online) target. To ensure that the holding application does not become overloaded, HAProxy will send only a few (5-10) connections to the holding application while the remaining client connections will wait in HAProxy’s queue. The holding application is not as robust as HAProxy, so we use HAProxy to handle the)
to cause, after the operation mode of the migration source proxy transitions to the queueing mode and the migration destination container is activated, (Page 2533. Restore after the transfer completes. We instruct the target host to immediately restore the container. When migrating interdependent containers, we must be careful about when we issue restores. We do not want the web container up and running, handling client requests while the database container is still being migrated over, as that would cause application-level errors. E.N: Benjaponpitak teaches restoring and making the container operational before queued traffic is sent)
the operation mode of the migration source proxy to transition to a queue sendout mode of sending out the saved data to the migration destination proxy, ( Page 2532. During the same time, the HAProxy instance on the source host will also be polling the target backend, so the remaining connections in its own queue will also be automatically dispatched to the (now online) target. E.N: Benjaponpitak teaches HAProxy transitioning from holding queued traffic to automatically dispatching the queued connections to the target after it becomes online.)
Benjaponpitak does not appear to explicitly teach: the container migration device comprising: processing circuitry to cause an operation mode of the migration source proxy, to transition from a transfer mode of: receiving data being transmitted from a request source container that requests the data processing; and to cause, after sendout of the saved data is completed, the request source container to change a data transmission destination from the migration source proxy to the migration destination proxy.
However, Kondo teaches [0051] The plurality of containers may be executed on a virtual machine that operates in the information processing device 20. The plurality of containers includes containers 21 to 26. The container 21 calls the container 22. The container 22 calls the containers 23 and 25. The container 23 calls the container 24. The container 25 calls the container 26. In this way, when the containers cooperate with each other, chained calls are performed between the containers, for example, the first container calls the second container, the second container calls the third container [0067] For example, the processing unit 12 arranges images of the containers 25 and 26 that belong to the container group B1 in the information processing device 30 and activates the containers 25 and 26 in the information processing device 30. At the same time, the processing unit 12 notifies the information processing device 20 to change a communication destination for the container 25 by the container 22 to the information processing device 30. Moreover, the processing unit 12 stops the containers 25 and 26 on the information processing device 20. Therefore, the containers 25 and 26 are moved from the information processing device 20 to the information processing device 30. Furthermore, in the information processing device 20, when the containers 25 and 26 are stopped, resources used for operations of the containers 25 and 26 are released, and a load of the information processing device 20 is reduced.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Benjaponpitak and Kondo before them, to include modify Benjaponpitak container migration system such that the request handled by the source side proxy originate from another container, as taught by Kondo, and to cause the communication destination used by the requesting container to be changed to the migrated container at the destination after migration. Benjaponpitak teaches migrating containers and holding request during migration while Kondo teaches cooperating containers and changing the communication destination when a container is moved. It would have been obvious to combine the teachings to maintain communication between cooperating containers and reduce communication delay caused by migration as taught by Kondo [0044].
Regarding claim 3, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 5, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Claims 2 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Benjaponpitak et al ” Benjaponpitak ”, in view of Kondo (US 20210294632 A1), and further view of Enguehard (US 20200089526 A1) hereafter Enguehard.
Regarding claim 2, Benjaponpitak teaches:
The container migration device according to claim 1, wherein the processing circuitry causes the migration destination apparatus to generate the migration destination container and the migration destination proxy. (page 2533, Assuming that the source host is already running the Wordpress and MySQL containers, our automated workflow provisions target hosts and VPN hosts on both sides. Then it configures the cloud provider’s VPN (i.e., AWS VPC) settings to have the source and target hosts use the respective source and target VPN hosts as gateways. Container images are placed at the target before migration to set the persistent storage’s initial state. HAProxy is also set up on both sides to forward traffic to the application. Refer back to Figure 1 for the initial state before a migration takes place.)
migrates a volume from the migration source container to the migration destination container after the migration source container is stopped, and activates activate the migration destination container after the volume is migrated. (page 2531, putting pre-migration and migration together, we have i Pre-dump: checkpoint the container’s memory using CRIU’s pre-dump capabilities, ii Pre-copy: transfer the pre-dumped memory state and the container’s local persistent storage from the source to the target, iii Checkpoint: perform a memory checkpoint, freezing the container and dumping memory state changes to a set of files called a “checkpoint image” using CRIU’s iterative checkpoint, iv Transfer: transfer the checkpointed memory state changes and the container’s local persistent storage changes from the source to the target using rsync, v Restore: restore the container at the target. E.N: Benjaponpitak teaches a 5step process to migrate the container storage)
Benjaponpitak does not appear to explicitly teach: stops the migration source container after the operation mode of the migration source proxy transitions to the queuing mode,
However, Enguehard teaches: [0051-0052][0055] [0057] In some examples, each successful deployment of each container file image layer may cause the destination node to transmit a container interest (for example, via migration channel 210). As a result, once the last container interest is received by the origin node, the application container at the origin node may be shut down (operation 308). In some examples, various “state” may be associated with the application container at the origin node such as, for example and without imputing limitation, side containers, configuration files, user variables, and the like. Any remaining state may be transmitted from the origin node to the destination node (operation 310).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Benjaponpitak, Kondo and Enguehard before them to further modify Benjaponpitak’s request holding to begin buffering incoming request before shutting down the migration source container as taught by Enguehard. Enguehard expressly teaches buffering application request for later processing during migration and shutting down the source application container. Enguehard’s migration technique is directed to live migration while continuing to serve incoming request streams and avoid packet loss. See Enguehard[0017][0055-0057]
Regarding claim 4, Benjaponpitak teaches:
A container migration method of migrating a container that conducts data processing from a migration source apparatus to a migration destination apparatus, the migration source apparatus being an apparatus in which a migration source container and a migration source proxy operate, the migration destination apparatus being an apparatus in which a migration destination container and a migration destination proxy operate, the container migration method comprising: receiving data being transmitted from a request source container that requests the data processing; and transferring the received data to the migration source container being a request destination container; (page 2532, During normal operations, HAProxy would forward incoming client connections to the web server container. However, during migration, new incoming client connections are instead for warded from HAProxy to the holding application. The holding application keeps the connections alive until it detects that the target is up. It then redirects all held connections to the target.)
after receiving an instruction to transition from a transfer mode to a queueing mode, receiving the data being transmitted from the request source container; and saving the received data instead of transferring; (page 2532. During the same time, the HAProxy instance on the source host will also be polling the target backend, so the remaining connections in its own queue will also be automatically dispatched to the (now online) target. To ensure that the holding application does not become overloaded, HAProxy will send only a few (5-10) connections to the holding application while the remaining client connections will wait in HAProxy’s queue. The holding application is not as robust as HAProxy, so we use HAProxy to handle the majority of the load.)
Benjaponpitak does not appear to explicitly teach: and after receiving an instruction to transition from the queuing mode to a queue sendout mode, sending out the saved data to the migration destination proxy.( [0031][0052] In some examples, the final buffered transmissions may be flagged in order to update pending interest table (PIT) entries across an ICN. Further, in some examples, app 110B may, upon being started, update forwarding information base (FIB) entries throughout the ICN. Receipt of a FIB update at base station 104A may signal to base station 104A to transmit flagged buffered transmissions to base station 104C for processing by app 110B and in order to update PIT entries at nodes along the path to base station 104C (discussed further in relation to FIG. 4 below). Once app 110B has received the buffered transmissions, the buffered transmissions may be processed by app 110B in the order they are received. In some examples, app 110B may buffer received requests as it awaits the request buffer from app 110A, for example, in cases where the order of service request processing in important or necessary to the processing of the requests themselves.)
Same motivation as claim 2.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
(US 20200034254 A1) – relevant because it teaches migration of stateful containers with associated persistent volumes.
(US 20180074748 A1) – teaches live migration of software containers, including transfer of data volumes and redirection of communications from source to target container
(US 20210089495 A1) – relevant because it teaches migration of stateful containers involving creation of a target container and switching operation from source to target container.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights