DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 09/03/2024. Claims 1-9 have been examined.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With regards to claims 1,8,9, the claims recite “ where the at least one support module is configured to provide transmission” it is unclear what” the least one support module” is referring to because the claims recite “deploying at least one support module on at least two sender runtimes , on at least one receiver runtime and on at least one orchestrator” It is unclear if the at least one support module that is configured to provide transmission refers to the support module on the sender runtimes, the support module on the receiver runtime or the support module on orchestrator. Therefore, the examiner is unable to determine the metes and bounds of the claim language.
With regards to claims 1, 8,9, the claims recite “….. using the least one support module” it is unclear what” the least one support module” is referring to because the claims recites “deploying at least one support module on at least two sender runtimes , on at least one receiver runtime and on at least one orchestrator” It is unclear if the at least one support module refers to the support module on the sender runtime, the support module on the receiver runtime or the support module on orchestrator. Therefore, the examiner is unable to determine the metes and bounds of the claim language.
With regards to claim 2 , the claim recites “….. using the least one support module” it is unclear what” the least one support module” is referring to because claim 1 which claim 2 depends on recites “deploying at least one support module on at least two sender runtimes , on at least one receiver runtime and on at least one orchestrator” It is unclear if the at least one support module refers to the support module on the sender runtime, the support module on the receiver runtime or the support module on orchestrator. Therefore, the examiner is unable to determine the metes and bounds of the claim language.
With regards to claim 8, the claim recites “a data processing device …. The data processing device is configured to deploy.. analyze, … and initiate ”. It is unclear which components/structures within the data processing device are performing the limitations of deploying, analyzing and initiating. Therefore, the examiner is unable to determine the metes and bounds of the claim language.
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.
Claims 1-4,8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Sanakkayala et al. Publication No. US 20190340088 A1 ( Sanakkayala hereinafter) in view of Massa et al. Publication No. US 2003/0182592 A1 (Massa hereinafter)
Regarding claim 1,
Sanakkayala teaches a method for managing a connection loss for a distributed system (Figs.4-7, Fig.12), comprising the following steps:
deploying at least one support module on at least two sender runtimes, on at least one receiver runtime, and on at least one orchestrator of the distributed system (¶ 0348 & ¶ 0365 and Claim 27 discloses worker heartbeat monitoring nodes (support nodes ) assigned to plurality of Target VMs (sender and receiver runtimes) and master heartbeat node assigned to master node ( orchestrator);
wherein the at least one support module is configured to provide transmission of a signal on an additional communication channel (¶ 0007 -VM heartbeat monitoring system comprises an illustrative ping monitoring logic that worker monitor nodes use for determining whether their target VMs are operational. To optimize operational efficiency, a master monitor node can be configured to also operate as a worker monitor node, thus performing a dual role – ¶ 0447 -At block 1906, the present worker monitor node executes ping monitoring logic 610 relative to the assigned target VM(s) (e.g., 411). This includes continuously sending customized packets to each target VM, waiting for a responsive packet, analyzing the response, if any, and provisionally determining that the target VM has failed when no response is received, followed by confirmation. More details are given in other figures herein (see, e.g., FIGS. 20, 20A) – See Also ¶ 0459 – Note: these ping packets are different from the regular data traffic);
wherein the orchestrator is configured to manage regular communication between the at least two sender runtimes and the at least one receiver runtime (Fig.4 & 5, Abstract -an illustrative master monitor node triggers an enhanced storage manager to initiate failover for the failed VM. The enhanced storage manager communicates with the heartbeat monitor nodes and also manages VM failovers and other storage management operations in the system. Special features for cloud-to-cloud failover scenarios enable a VM in a first region of a public cloud to fail over to a second region. – See Also ¶ 0006 – ¶ 0007, ¶ 0352-discloses that the Master monitor node and the storage manager coordinate health of the system, task assignment, and configuration);
analyzing the additional communication channel between the at least two sender runtimes and the orchestrator to detect a connection loss of at least one of the at least two sender runtimes in each case based on a detection of the transmitted signal on the additional communication channel (¶ 0006-Upon detecting a target-VM failure and confirming the failure with the VM's host server and/or VM data center controller to ensure that the VM is really in a failed state that requires failover, the illustrative worker monitor node notifies the master monitor node - -¶ 0466-¶ 0467 -Illustratively, the Max_ packet_ loss_ threshold is initialized to 75%, thus allowing for up to 75% packet loss for the given target VM. If the packet loss percentage exceeds this threshold, the ping monitoring logic assumes that the target VM is not reachable and the Manage Packets Thread confirms the given VM's status by illustratively querying the VM data center and/or the VM's host/server (e.g., 401) to check the VM's power state. If the VM power state is confirmed to be offline then the target VM is considered to be down. The Manage Packets Thread updates this down state to the worker monitor node ( e.g., by updating data structure 802 in the/Worker PS-node of distributed file system 545); in turn, this change is picked up by the watch process 922 of the/Master PS-node, and cause the master monitor node to notify storage manager 340 to call failover of the given VM (e.g., block 1708) – See ¶ 0477, Claim 3);
initiating at least one countermeasure in the case of the detected connection loss, wherein the at least one countermeasure […] between the at least one of the at least two sender runtimes with the detected connection loss and the at least one receiver runtime using the at least one support module to manage the connection loss in the distributed system (¶ 0007 - The master monitor node re-distributes target VMs when a worker monitor node fails - ¶ 0354 -VM Distribution Back End Thread #1 distributes a few VMs in case of any worker failures. The master monitor node distributes a failed worker's target VMs ("orphaned target VMs") to another healthy worker(s). This back end thread runs continuously and master thread will communicate with the VMs to re-distribute by filling up vmQueue2. This thread gets the orphaned target VMs to re-distribute from the vmQueue2 and identifies the currently alive workers at that point in time).
However, Sanakkayala does not explicitly teach
stopping the regular communication between the at least one of the at least two sender with the detected connection loss and the at least one receiver using the at least one support module to manage the connection loss in the distributed system.
Massa teaches
stopping the regular communication between the at least one of the at least two sender with the detected connection loss and the at least one receiver using the at least one support module to manage the connection loss in the distributed system (¶ 0041 Upon the detection of a network failure, the CDML may perform a disk array analysis to determine which disk arrays, if any, are still useable. Each array of drives may be checked by testing access to the member disks. If the network failure caused loss of a disk member of a nonredundant cluster drive, for example a single disk RAID 0 array, the drive is set to offline and any access to this drive is cancelled – ¶0042 -If the network failure caused a loss of more than one member disk of a redundant RAID 4 or RAID 5 disk array, the associated disk array is set to offline and any access to this array is cancelled. This is because data in a RAID 4 or RAID 5 system may not be recoverable in the event of multiple disk failures in the RAID array - See Also ¶0021 – ¶0022, ¶0025- ¶0026, ¶0036-¶ 0037).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Massa. The motivation for doing so is to allow the system to prevent the failed node from transmitting data that could corrupt the system (Massa – ¶0041-¶0043).
Regarding claim 2,
Sanakkayala teaches
initiating the transmission of the signal on the additional communication channel in an interval using the at least one support module (¶ 0459 - ping monitoring logic 610 uses nonblocking sockets to send/receive heartbeat packets ( e.g., 2001) continuously and concurrently to optimize packet distribution across VMs efficiently. Advantageously, shorter wait times are achieved when there is a network partition and VMs are not responsive – ¶ 0460 - Heartbeat packets (e.g., 2001) are filled in the Send Queue by the Manage Packet Tread. In a first round, the first heartbeat packet for each target VM are sent. In the next iteration, the second heartbeat packet for each target VM are sent. This iterative process repeats until a last (preferably tenth) round of transmissions is completed, without limitation. By using this technique, pings are distributed to all target VMs with reduced wait times and not ignoring any target VMs. The ping monitoring threads are described in more detail next. – See Also ¶ 0460); and
analyzing a presence of the transmitted signal in order to detect the connection loss, wherein the presence of the transmitted signal is analyzed by the at least two sender runtimes and/or the orchestrator (¶ 0462 - Process Packet Thread runs continuously and constantly listens to the recv () non-blocking socket forming an event loop. Whenever a responsive echo reply packet arrives to the socket, this thread picks it up and puts in the Receive Queue. If the socket is suddenly closed, this thread re-opens the non-blocking socket to continue monitoring – ¶ 0463 - . Receive Packet Thread runs continuously and picks up echo reply packets put in the Receive Queue. It unpacks each echo reply packet and validates the receive times of echo reply packets and updates the synchronized map. If the echo reply packet arrives within a pre-defined maximum packet timeout period, then the packet's entries in the synchronized map are deleted; otherwise (arrival past the timeout period) the packet's entries are updated in the synchronized map for the Manage Packet Thread to analyze - See Also ¶ 0464).
Regarding claim 3,
Sanakkayala teaches
defining the interval in which the signal is transmitted, wherein the interval is defined manually or automatically, according to at least one requirement (¶ 0234 – ¶ 0235 - while storage policies are typically associated with moving and storing data, other policies may be associated with other types of information management operations. The following is a non-exhaustive list of items that information management policies 148 may specify: schedules or other timing information, e.g., specifying when and/or how often to perform information management operations – ¶ 0139 & 0222 & 0231 using the GUI to monitor components and configure schedule parameters);
defining a time period for the transmitted signal after which the connection loss is detected (¶ 0466 - Packet Analyzing Logic. Entries in the synchronized map illustratively comprise: destination VM IP address, packet number, start time, end time, and maximum timeout for each heartbeat packet (e.g., 2001). These are filled in by the Send Packet Thread. Whenever the echo reply packet arrives after the timeout period or no echo reply packet is received at all - ¶ 0470 - ping monitoring logic 610 waits for and processes responsive echo reply packets arriving from target VMs in response to the groups of packets transmitted thereto at block 2022, e.g., using the Process Packet Thread, and the Receive Packet Thread).
Regarding claim 4,
Sanakkayala teaches
wherein at least one of the following three types of support modules is deployed on the at least two sender runtimes, and/or on the at least one receiver runtime, and/or on the at least one orchestrator: (i) an emitter, wherein the emitter (E) transmits the signal (¶ 0459-0461 - Send Packet Thread in the worker monitor node runs continuously and picks up the packets to be sent to target VMs from the Send Queue; constructs heartbeat packets ( e.g., 2001) and sends heartbeat packets continuously through send ( ) non-blocking socket. It also updates packet statistics in the synchronized map. Each heartbeat packet sent out via the non-blocking socket is tracked in the synchronized map);
(ii) a detector, wherein the detector detects the signal transmitted by the emitter (¶ 0462 - Process Packet Thread runs continuously and constantly listens to the recv () non-blocking socket forming an event loop. Whenever a responsive echo reply packet arrives to the socket, this thread picks it up and puts in the Receive Queue. If the socket is suddenly closed, this thread re-opens the non-blocking socket to continue monitoring – ¶ 0463 - Receive Packet Thread runs continuously and picks up echo reply packets put in the Receive Queue. It unpacks each echo reply packet and validates the receive times of echo reply packets and updates the synchronized map. If the echo reply packet arrives within a pre-defined maximum packet timeout period).
Sanakkayala teaches temporary suspending monitoring between the at least one of the at least two sender runtimes and the at least one receiver runtime (¶ 0476). However, Sanakkayala does not explicitly
(iii) a mute switch, wherein the mute switch stops the regular communication between the at least one of the at least two sender runtimes and the at least one receiver runtimes.
Massa teaches
(iii) a mute switch, wherein the mute switch stops the regular communication between the at least one of the at least two sender and the at least one receiver (¶ 0041 Upon the detection of a network failure, the CDML may perform a disk array analysis to determine which disk arrays, if any, are still useable. Each array of drives may be checked by testing access to the member disks. If the network failure caused loss of a disk member of a nonredundant cluster drive, for example a single disk RAID 0 array, the drive is set to offline and any access to this drive is cancelled – ¶0042 -If the network failure caused a loss of more than one member disk of a redundant RAID 4 or RAID 5 disk array, the associated disk array is set to offline and any access to this array is cancelled. This is because data in a RAID 4 or RAID 5 system may not be recoverable in the event of multiple disk failures in the RAID array - See Also ¶0021 – ¶0022, ¶0025- ¶0026, ¶0036-¶ 0037.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Massa. The motivation for doing so is to allow the system to prevent the failed node from transmitting data that could corrupt the system (Massa – ¶0041-¶0043).
Regarding claim 8,
Sanakkayala teaches a data processing device configured to manage connection loss for a distributed system (Figs.4-7, Fig.12), the data processing device configured to:
deploy at least one support module on at least two sender runtimes, on at least one receiver runtime, and on at least one orchestrator of the distributed system (¶ 0348 & ¶ 0365 and Claim 27 discloses worker heartbeat monitoring nodes (support nodes ) assigned to plurality of Target VMs Z(sender and receiver runtimes) and master heartbeat node assigned to master node ( orchestrator);
wherein the at least one support module is configured to provide transmission of a signal on an additional communication channel (¶ 0007 -VM heartbeat monitoring system comprises an illustrative ping monitoring logic that worker monitor nodes use for determining whether their target VMs are operational. To optimize operational efficiency, a master monitor node can be configured to also operate as a worker monitor node, thus performing a dual role – ¶ 0447 -At block 1906, the present worker monitor node executes ping monitoring logic 610 relative to the assigned target VM(s) (e.g., 411). This includes continuously sending customized packets to each target VM, waiting for a responsive packet, analyzing the response, if any, and provisionally determining that the target VM has failed when no response is received, followed by confirmation. More details are given in other figures herein (see, e.g., FIGS. 20, 20A) – See Also ¶ 0459 – Note: these ping packets are different from the regular data traffic);
wherein the orchestrator is configured to manage regular communication between the at least two sender runtimes and the at least one receiver runtime (Fig.4 & 5, Abstract -an illustrative master monitor node triggers an enhanced storage manager to initiate failover for the failed VM. The enhanced storage manager communicates with the heartbeat monitor nodes and also manages VM failovers and other storage management operations in the system. Special features for cloud-to-cloud failover scenarios enable a VM in a first region of a public cloud to fail over to a second region. – See Also ¶ 0006 – ¶ 0007, ¶ 0352-discloses that the Master monitor node and the storage manager coordinate health of the system, task assignment, and configuration);
analyze the additional communication channel between the at least two sender runtimes and the orchestrator to detect a connection loss of at least one of the at least two sender runtimes in each case based on a detection of the transmitted signal on the additional communication channel (¶ 0006-Upon detecting a target-VM failure and confirming the failure with the VM's host server and/or VM data center controller to ensure that the VM is really in a failed state that requires failover, the illustrative worker monitor node notifies the master monitor node - -¶ 0466-¶ 0467 -Illustratively, the Max_ packet_ loss_ threshold is initialized to 75%, thus allowing for up to 75% packet loss for the given target VM. If the packet loss percentage exceeds this threshold, the ping monitoring logic assumes that the target VM is not reachable and the Manage Packets Thread confirms the given VM's status by illustratively querying the VM data center and/or the VM's host/server (e.g., 401) to check the VM's power state. If the VM power state is confirmed to be offline then the target VM is considered to be down. The Manage Packets Thread updates this down state to the worker monitor node ( e.g., by updating data structure 802 in the/Worker PS-node of distributed file system 545); in turn, this change is picked up by the watch process 922 of the/Master PS-node, and cause the master monitor node to notify storage manager 340 to call failover of the given VM (e.g., block 1708) – See ¶ 0477, Claim 3);
initiate at least one countermeasure in the case of the detected connection loss, wherein the at least one countermeasure […] between the at least one of the at least two sender runtimes with the detected connection loss and the at least one receiver runtime using the at least one support module to manage the connection loss in the distributed system (¶ 0007 - The master monitor node re-distributes target VMs when a worker monitor node fails - ¶ 0354 -VM Distribution Back End Thread #1 distributes a few VMs in case of any worker failures. The master monitor node distributes a failed worker's target VMs ("orphaned target VMs") to another healthy worker(s). This back end thread runs continuously and master thread will communicate with the VMs to re-distribute by filling up vmQueue2. This thread gets the orphaned target VMs to re-distribute from the vmQueue2 and identifies the currently alive workers at that point in time).
However, Sanakkayala does not explicitly teach
stopping the regular communication between the at least one of the at least two sender runtimes with the detected connection loss and the at least one receiver runtimes using the at least one support module to manage the connection loss in the distributed system.
Massa teaches
stopping the regular communication between the at least one of the at least two sender with the detected connection loss and the at least one receiver using the at least one support module to manage the connection loss in the distributed system(¶ 0041 Upon the detection of a network failure, the CDML may perform a disk array analysis to determine which disk arrays, if any, are still useable. Each array of drives may be checked by testing access to the member disks. If the network failure caused loss of a disk member of a nonredundant cluster drive, for example a single disk RAID 0 array, the drive is set to offline and any access to this drive is cancelled – ¶0042 -If the network failure caused a loss of more than one member disk of a redundant RAID 4 or RAID 5 disk array, the associated disk array is set to offline and any access to this array is cancelled. This is because data in a RAID 4 or RAID 5 system may not be recoverable in the event of multiple disk failures in the RAID array - See Also ¶0021 – ¶0022, ¶0025- ¶0026, ¶0036-¶ 0037).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Massa. The motivation for doing so is to allow the system to prevent the failed node from transmitting data that could corrupt the system (Massa – ¶0041-¶0043).
Regarding claim 9,
Sanakkayala teaches a non-transitory computer-readable storage medium on which are stored instructions for managing a connection loss for a distributed system, the instructions, when executed by a computer, (Figs.4-7, Fig.12), causing the computer to perform the following steps:
deploying at least one support module on at least two sender runtimes, on at least one receiver runtime, and on at least one orchestrator of the distributed system (¶ 0348 & ¶ 0365 and Claim 27 discloses worker heartbeat monitoring nodes (support nodes ) assigned to plurality of Target VMs Z(sender and receiver runtimes) and master heartbeat node assigned to master node ( orchestrator);
wherein the at least one support module is configured to provide transmission of a signal on an additional communication channel (¶ 0007 -VM heartbeat monitoring system comprises an illustrative ping monitoring logic that worker monitor nodes use for determining whether their target VMs are operational. To optimize operational efficiency, a master monitor node can be configured to also operate as a worker monitor node, thus performing a dual role – ¶ 0447 -At block 1906, the present worker monitor node executes ping monitoring logic 610 relative to the assigned target VM(s) (e.g., 411). This includes continuously sending customized packets to each target VM, waiting for a responsive packet, analyzing the response, if any, and provisionally determining that the target VM has failed when no response is received, followed by confirmation. More details are given in other figures herein (see, e.g., FIGS. 20, 20A) – See Also ¶ 0459 – Note: these ping packets are different from the regular data traffic);
wherein the orchestrator is configured to manage regular communication between the at least two sender runtimes and the at least one receiver runtime (Fig.4 & 5, Abstract -an illustrative master monitor node triggers an enhanced storage manager to initiate failover for the failed VM. The enhanced storage manager communicates with the heartbeat monitor nodes and also manages VM failovers and other storage management operations in the system. Special features for cloud-to-cloud failover scenarios enable a VM in a first region of a public cloud to fail over to a second region. – See Also ¶ 0006 – ¶ 0007, ¶ 0352-discloses that the Master monitor node and the storage manager coordinate health of the system, task assignment, and configuration);
analyzing the additional communication channel between the at least two sender runtimes and the orchestrator to detect a connection loss of at least one of the at least two sender runtimes in each case based on a detection of the transmitted signal on the additional communication channel (¶ 0006-Upon detecting a target-VM failure and confirming the failure with the VM's host server and/or VM data center controller to ensure that the VM is really in a failed state that requires failover, the illustrative worker monitor node notifies the master monitor node - -¶ 0466-¶ 0467 -Illustratively, the Max_ packet_ loss_ threshold is initialized to 75%, thus allowing for up to 75% packet loss for the given target VM. If the packet loss percentage exceeds this threshold, the ping monitoring logic assumes that the target VM is not reachable and the Manage Packets Thread confirms the given VM's status by illustratively querying the VM data center and/or the VM's host/server (e.g., 401) to check the VM's power state. If the VM power state is confirmed to be offline then the target VM is considered to be down. The Manage Packets Thread updates this down state to the worker monitor node ( e.g., by updating data structure 802 in the/Worker PS-node of distributed file system 545); in turn, this change is picked up by the watch process 922 of the/Master PS-node, and cause the master monitor node to notify storage manager 340 to call failover of the given VM (e.g., block 1708) – See ¶ 0477, Claim 3);
initiating at least one countermeasure in the case of the detected connection loss, wherein the at least one countermeasure […] between the at least one of the at least two sender runtimes with the detected connection loss and the at least one receiver runtime using the at least one support module to manage the connection loss in the distributed system (¶ 0007 - The master monitor node re-distributes target VMs when a worker monitor node fails - ¶ 0354 -VM Distribution Back End Thread #1 distributes a few VMs in case of any worker failures. The master monitor node distributes a failed worker's target VMs ("orphaned target VMs") to another healthy worker(s). This back end thread runs continuously and master thread will communicate with the VMs to re-distribute by filling up vmQueue2. This thread gets the orphaned target VMs to re-distribute from the vmQueue2 and identifies the currently alive workers at that point in time).
However, Sanakkayala does not explicitly teach
stopping the regular communication between the at least one of the at least two sender with the detected connection loss and the at least one receiver using the at least one support module to manage the connection loss in the distributed system.
Massa teaches
stopping the regular communication between the at least one of the at least two sender with the detected connection loss and the at least one receiver using the at least one support module to manage the connection loss in the distributed system(¶ 0041 Upon the detection of a network failure, the CDML may perform a disk array analysis to determine which disk arrays, if any, are still useable. Each array of drives may be checked by testing access to the member disks. If the network failure caused loss of a disk member of a nonredundant cluster drive, for example a single disk RAID 0 array, the drive is set to offline and any access to this drive is cancelled – ¶0042 -If the network failure caused a loss of more than one member disk of a redundant RAID 4 or RAID 5 disk array, the associated disk array is set to offline and any access to this array is cancelled. This is because data in a RAID 4 or RAID 5 system may not be recoverable in the event of multiple disk failures in the RAID array - See Also ¶0021 – ¶0022, ¶0025- ¶0026, ¶0036-¶ 0037.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Massa. The motivation for doing so is to allow the system to prevent the failed node from transmitting data that could corrupt the system (Massa – ¶0041-¶0043).
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Sanakkayala in view of Massa further in view of Juneja et al. Publication No. US 2025/0021437 A1 ( Juneja hereinafter)
Regarding claim 5,
Sanakkayala further teaches
activating regular communication between at least one of the at least two sender runtimes in which no connection loss is detected and the at least one receiver runtime ( ¶ 0497 - reporting to a master monitor node that the second virtual machine has been confirmed failed, wherein the reporting comprises updating, by the first worker monitor node, a data structure in a distributed file system having an instance on the first worker monitor node and on the master monitor node. The above recited method further comprising: if, responsive to the querying, the operational status of the second virtual machine is reported to be active, resuming the transmitting of data packets by the first worker monitor node to the second virtual machine).
However, Sanakkayala does not explicitly teach
wherein the at least one countermeasure further includes activating temporary regular communication between at least one of the at least two sender runtimes in which no connection loss is detected and the at least one receiver runtime.
Juneja teaches
a at least one countermeasure further includes activating temporary regular communication between at least one of the at least two sender runtimes in which no connection loss is detected and the at least one receiver runtime (¶ 0018– The updated pod information in this example indicates pod 103, which was previously on standby, is now active and associated with unique application identifier 1, which was previously assigned to pod 102. Pod 103 is now active because pod 102 failed and application 111 activated pod 103 to take the place of pod 102 in active pods 122. When activating pod 103, application 111 assigns the unique application identifier of failed pod 102 to the newly activated pod 103 so that application 111 on pod 103 can take over the tasks for application 111 on pod 102. Instances of application 111 on the remaining pods may negotiate among themselves to determine which of standby pods 123 should be activated upon determining pod 102 failed or a controlling instance of application 111 may determine which of standby pods 123 should be activated. ¶ 0024 In response to determining that pod 322 failed, application controller 312 reassigns unique application identifier 2, which was assigned to pod 322, to pod 324 and changes the role of pod 324 to active at step 5. Application controller 312 may have determined pod 322 failed because pod 322 stopped responding to messages from application controller 312, application controller 312 stopped receiving heartbeat messages from pod 322, or based on some other indication that pod 322 has failed - ¶ 0026 – ¶ 0027 -Pod 322 recovers from the failure described above (e.g., is respawned by the container orchestration platform). Upon application controller 312 recognizing the pod 322 has recovered, application controller 312 reassigns unique application identifier 4 to pod 322 and places pod 322 on standby at step 9. Unique application identifier 4 was previously the unique application identifier assigned to pod 324 prior to pod 324 being activated).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Juneja. The motivation for doing so is to allow the system to enables a service manager of a container orchestration platform to handle failovers of pods executing an application in a high availability mode (Juneja– Abstract).
Regarding claim 6,
Sanakkayala does not explicitly teach
wherein the activating of the temporary regular communication between the at least one of the at least two sender runtimes in which no connection loss is detected and the at least one receiver runtime is carried out by the orchestrator.
However, Juneja teaches
wherein the activating of the temporary regular communication between the at least one of the at least two sender runtimes in which no connection loss is detected and the at least one receiver runtime is carried out by the orchestrator (¶ 0024 In response to determining that pod 322 failed, application controller 312 reassigns unique application identifier 2, which was assigned to pod 322, to pod 324 and changes the role of pod 324 to active at step 5. Application controller 312 may have determined pod 322 failed because pod 322 stopped responding to messages from application controller 312, application controller 312 stopped receiving heartbeat messages from pod 322, or based on some other indication that pod 322 has failed.. ¶ 0026 – ¶ 0027 -Pod 322 recovers from the failure described above (e.g., is respawned by the container orchestration platform). Upon application controller 312 recognizing the pod 322 has recovered, application controller 312 reassigns unique application identifier 4 to pod 322 and places pod 322 on standby at step 9. Unique application identifier 4 was previously the unique application identifier assigned to pod 324 prior to pod 324 being activated).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Juneja. The motivation for doing so is to allow the system to enables a service manager of a container orchestration platform to handle failovers of pods executing an application in a high availability mode (Juneja– Abstract).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Sanakkayala in view of Massa further in view of Sadu et al. Publication No. US 20220166696 A1 (Sadu hereafter )
Regarding claim 7,
Sanakkayala further teaches
analyzing the additional communication channel between the at least two sender runtimes to detect the connection loss of the at least one of the at least two sender runtimes (¶ 0006, ¶ 0466-¶ 0467, ¶ 0477)
However, Sanakkayala does not explicitly teach
analyzing the additional communication based on the transmission of the signal between the at least two sender runtimes
Sadu teaches
analyzing the additional communication based on the transmission of the signal between the at least two sender runtimes (¶ 0075 - heartbeat actor, which runs on every runtime, in other words the subnetwork monitoring unit, regularly checks whether other runtimes are functioning or not. When a runtime, in other words a subnetwork monitoring unit, fails, all other runtimes in the same network will discover the fault since they are not receiving a heartbeat signal from
the failed runtime -¶ 0076 - All other runtimes in the same network stop their periodic migration. See Also ¶ 0146)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sanakkayala to include the teachings of Sadu. The motivation for doing so is to allow the system to provide a decentralized peer to peer analysis where healthy runtimes discover the fault (Sadu – ¶ 0075).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Barszczak et al. – Publication No. US 2020/0112628 A1
Gomez et al. – Publication No. US 2004/0267901 A1
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445