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 .
Herein after “it would have been obvious” should be read as “it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 11, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al PN 2018/0113764 in view of Kent PN 4,689,766.
In regards to claims 1-3, 11-12, 16-17: Bhandari et al teaches a method comprising: maintaining a health monitor timer (watchdog timer [0011] “The hypervisor provides a watchdog timer to each operating system in each partition. A watchdog timer generally refers to functionality including a timer that expires after a particular amount of time has elapsed, such as 5 minutes, and causes an operating system to reset in response to the timer expiring. A watchdog timer provided by the hypervisor is also referred to herein as a hypervisor watchdog timer. The hypervisor watchdog timer is a watchdog timer associated with a particular partition of the hypervisor, and a separate hypervisor watchdog timer is provided for each partition. In response to a hypervisor watchdog timer expiring, the watchdog timer resets the operating system in the associated partition. In order to avoid a hypervisor watchdog timer expiring, the operating system in the associated partition re-arms the hypervisor watchdog timer prior to the hypervisor watchdog timer expiring. If the operating system is operating correctly, the operating system repeatedly re-arms the hypervisor watchdog timer (e.g., every 1 to 2 minutes), keeping the hypervisor watchdog timer from resetting the operating system. However, if the operating system is not operating correctly and hangs, the hypervisor watchdog timer expires, causing the malfunctioning operating system to be reset. Resetting the malfunctioning operating system avoids battery drain that may result from prolonged operation of an incorrectly functioning operating system”) for a logical partition (partition) in a logical partition cluster (partition91) to partition(y)), wherein the health monitor timer (hypervisor watchdog timer) runs within a hypervisor (figure 1 shows the watchdog for partition(1) in hypervisor 102) associated with the logical partition (watchdog timer (1) is associated with partition (1) watchdog timer (y) is associated with partition (y)); periodically sending, from the logical partition (the operating system in partition (1) sends a re-arm every e.g. 1 to 2 minutes thus periodically) to the hypervisor (hypervisor), a timer reset to reset the health monitor timer (re-arms a watchdog timer is resetting the watchdog timer); identifying, by the hypervisor, a hung (hangs) logical partition after a timeout interval without receiving the timer reset from the logical partition (the operating system does not re-arm the watchdog); and resetting the hung logical partition (“causing the malfunctioning operating system to be reset”) based on a command of a reset type (the timeout of the watchdog timer). Bhandari et al only expressly teaches the command being of a reset type as opposed to being tunable/selectable. Kent teaches a programmable watchdog timer with a programmable time period that either sends a shutdown command or a restart command as desired. (column 1 line 34 et. seq. “ a software watchdog timer arrangement wherein a desired count is loaded into a timer count register during the power-up sequence. At one or more times during the main execution loop, the timer must be reloaded with the desired count before the timer overflows from the previous load or a timer-interrupt will occur. The timer-interrupt service software can perform the controlled system shutdown or, if desired, restart the system with the power-up sequence.”). It would have been obvious to tune the command to be either a restart/reset or a shutdown based upon a desire because this would have allowed for control of the time period and the function called when the watchdog times out.
In regards to claims 2, 12, 17: Bhandari et al teaches a hard resetting of the hung partition. Kent teaches either restarting the hung system.
In regards to claim 3: Kent teaches powering off/shutdown the hung system as desired.
Claim(s) 4, 13, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al PN 2018/0113764 in view of Kent PN 4,689,766 as applied to claim 1 above, and further in view of Wen PN 2013/0290789.
In regards to claims 4, 13, 18: Bhandari et al does not teach a dump being enabled upon the health monitor timer timing out. Wen teaches ([0026] “Specifically, the watchdog timer 216 is used to enable memory dump functionality in the embedded device 200 in the case of a system hang. During normal operation of the embedded device 200, the embedded device 200 regularly restarts the watchdog timer 216 to prevent the watchdog timer 216 from timing out. If, due to a system hang, the embedded device 200 fails to restart the watchdog timer 216, the watchdog timer 216 elapses and generates a timeout signal. The timeout signal is used to initiate corrective actions, such as a memory dump of the current contexts to a memory of the embedded device 200 and a restart of the embedded device 200”). It would have been obvious to enable a memory dump when the system hangs because this would have allowed for initiating corrective actions.
Claim(s) 5-6, 14, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al PN 2018/0113764 in view of Kent PN 4,689,766 as applied to claim 1 above, and further in view of Browning PN 6,654,781.
In regards to claims 5, 14, 19: Bhandari et al teaches plural partitions as well as a memory storing parameters/register values [0012] and configuration preferences [0029] and state information [0033] “This crash data can be any state or status information for the partition 106 and/or the computing device 100 that the hypervisor 102 has access to. This crash data can be stored on various storage devices included as part of the computing device 100 and/or coupled to the computing device 100 as discussed above”) but never mentions kernel extensions. Browning teaches (column 4 line 40 et. seq. “It is necessary to carefully partition the data in order to minimize the memory footprint of the thread. Each process has a single process structure 201 that contains information shared by each of the threads in the process such as its process ID and user ID. Each process also contains at least one thread structure. In the example, three thread structures 203, 205 and 207 are shown. Each thread structure contains information that is associated with a thread, such as its thread ID or execution state. The process and thread structures are themselves elements in tables which are located in the Kernel Extension Segment. That segment can be referenced at any time by any thread or even by an interrupt handler, provided that it is referenced in kernel mode. Segment register 14 is always loaded with the segment ID associated with the Kernel Extension Segment while in kernel mode”). It would have been obvious to store the kernel extension segments because this is used anytime a thread/partition uses an interrupt handler.
In regards to claim 6: Bhandari et al teaches storing a timeout interval/ expiration amount of time [0027] “For example, if the expiration amount of time is 5 minutes and the operating system is expected to re-arm the hypervisor watchdog timer 122 every 1.25 minutes, then this significant portion of the expiration amount of time is 2.5 minutes. This significant portion of the expiration amount of time can vary, and can optionally be provided to the hypervisor watchdog timer 122 by the operating system 108 in the associated partition 106”).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al PN 2018/0113764 in view of Kent PN 4,689,766 as applied to claim 1 above, and further in view of Gaonkar et al PN 2021/0089347 and Warkentin et al PN 2023/0229558.
In regards to clam 7: Bhandari et al teaches partitions and a hypervisor but never mentions “live partition mobility”, “live kernel update” and disabling the health monitor timer. Gaonkar et al teaches partitions including a hypervisor ([0052] “Live Partition Mobility (LPM) provides the ability to move the logical partition (LPAR) or virtual machine (VM) from one server to another without disrupting the infrastructure services and workload. The hypervisor of the system in collaboration with the Moving Service Partition (MSP) manages the activities of migrating the memory pages of the LPAR/VM from one system to another” [0092] “After the migration process has been completed, a surrogate LPAR will be used to store updates for the kernel update process. During the kernel update, a surrogate page table is used to track changed during the LKU”). It would have been obvious to enable LPM and LKU because this would have allowed for moving the partition to another machine. Warkentin et al teaches disabling the watchdog time during a boot process. ([0009] “Notably, when a boot loader (e.g., a UEFI boot loader) receives a notification from an operating system indicating the operating system will take over boot loading operations, existing specifications require the boot loader disable a hardware watchdog.”). it would have been obvious to disable a watchdog during boot/reboot because this would have prevented forcing a reboot while rebooting.
Claim(s) 8-9, 15, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al PN 2018/0113764 in view of Kent PN 4,689,766 as applied to claim 1 above, and further in view of Gaonkar et al PN 2021/0089347 and Pearlman et al PN 2003/0187520.
In regards to claims 8, 15, 20: Bhandari et al teaches sending the re-arm signals to the hypervisor to identify the health of the partitions instead of to each other partition. Pearlman teaches ([0044] “In the exemplary embodiment, at least one processor is programmed to execute a watchdog timer function for monitoring the health of the other processors. Processor generates a first "heartbeat" signal and transmits the heartbeat signal to each other processor or a predetermined number of the other processors. Each processor that receives the first heartbeat signal and is healthy, responds with a second heartbeat signal, which each processor transmits to the sending processor. The sending processor is programmed to determine the health of the other processors based on heartbeat signals received and the watchdog timer”). It would have been obvious to send the heartbeat/re-arm signal to other partitions because this would have allowed other partitions to know the partitions are healthy.
In regards to claim 9: Pearlman et al teaches determining the health of other processors (“The sending processor is programmed to determine the health of the other processors based on heartbeat signals received and the watchdog timer”).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al PN 2018/0113764 in view of Kent PN 4,689,766 as applied to claim 1 above, and further in view of Gaonkar et al PN 2021/0089347 and van Rietschote et al PN 7,213,246.
In regards to claim 10: Bhandari et al teaches handling hanging of logical partitions/virtual machines but does not teach failover. (Websters dictionary definition of failover (reliability) failover – Automatically switching to a redundant or standby server, system, or network upon the failure or abnormal termination of the currently-active server, system, or network (a “hot standby” or “warm standby”). Failover happens without human intervention. This feature is usually built-in to expensive systems which must be available continuously.). van Rietschote et al teaches Column 4 line 8 et. seq. “In this context, an application may fail due to an internal coding error in the application, an error in the operating system on which the application is running, an error in the virtual machine or the VM kernel on which the virtual machine is executing, an error in the hardware of the computer system on which the application is running, or a combination of any of the above errors. The errors may cause the application, or the operating system, to cease executing (e.g. a crash) or to stop functioning (e.g. a hang). It is noted that, in some embodiments, the computer systems 10A 10N may be configured to periodically checkpoint the virtual machines executing thereon, thus providing a set of possible images from which to resume when a failover occurs” Abstract “A first computer system may be configured to execute a first application in a first virtual machine. A second computer system may be coupled to the first computer system. In response to a failure, the first computer system is configured to failover the first virtual machine to the second computer system. A carrier medium comprises first instructions which, when executed, initiate a failover of a first virtual machine. An application executes on the first virtual machine. The failover occurs from a first computer system on which a failure occurs to a second computer system”). It would have been obvious to fail over a first hung partition/virtual machine to a second partition/virtual machine because this would have allowed tasks on a hung partition to continue to execute.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Multiple references are cited teaching handling hanging of virtual machines/logical partitions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R MYERS whose telephone number is (571)272-3639. The examiner can normally be reached telework M-F start 7-8 leave 4-5.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/Paul R. MYERS/ Primary Examiner, Art Unit 2176
Prosecution Insights