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 .
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, 2, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al. Pub. No. US 20180113764 A1 (hereafter Bhandari), in view of Naineni et al. Pub. No. US 20190332684 A1 (hereafter Naineni), in view of Vastrad et al. Pub. No. US 20220019372 A1 (hereafter Vastrad), in view of Ki et al. Pub. No. US 20210349780 A1 (hereafter Ki)
With regard to claim 1, Bhandari a computer-implemented method, comprising: monitoring, by a computing process executing at a host machine, the computing process being deployed to the host machine as part of the hypervisor monitoring function “A hypervisor watchdog timer associated with a partition is re-armed in response to a re-arm request from an operating system in the partition. If the hypervisor watchdog timer expires, the operating system is reset.” [0003]. Bhandari further states “the techniques discussed herein support diagnosing operating system malfunctions (e.g., hangs) on computing devices that do not have a hardware (physical) watchdog timer.” [0042].
Bhandari further teaches a boot volume associated with a hypervisor (“The computing device 100 includes a hypervisor 102 and at least one (shown as multiple (x)) components 104. The hypervisor is a virtual machine monitor that manages access to the functionality provided by the components 104. The components 104 can include […] one or more memory components (e.g., volatile and/or nonvolatile memory), one or more storage devices (e.g., optical and/or magnetic disks, flash memory drives) ” [0018]. Bhandari further teaches “The components 104 are virtualized to the partitions 106, and access to the components 104 is managed by the hypervisor 102.” [0019]. Bhandari further teaches “Each partition 106 can run a different instance of the same operating system” [0020]. Bhandari further teaches “Resetting the operating system 108 refers to restarting the operating system…the operating system 108 is re-booted, analogous to power cycling a physical system” [0023]).
Bhandari does not teach monitoring a boot volume.
However, in analogous art, Naineni teaches monitoring a boot volume, associated with a file system server, by a file system client that tracks a mounted export’s state and checks every incoming request against it (“file system client 410 mounts file system export 425 from file system server 420 as file system export/mount 415. After file system client 410 successfully mounts the file system export/mount 415, in addition to its usual operations, file system client 410 saves the access type 416 (read-only/read-write) of the mounted file system” [0057]. Naineni further states “While working on each file system request for mounted file system export 415, file system client 410 determines whether each file system request is a modification request. [0058]”. Naineni shows repeated state check “for each modification request, file system client 410 checks access type 416.” [0059]. Naineni also shows what type of resource being monitored “server 104 provides data, such as boot files, operating system images, and applications to the clients” [0038])..
Naineni further teaches detecting…that the boot volume is operating in a read-only mode based at least in part on receiving one or more error codes, the one or more error codes being received in response to at least one of the one or more write requests, via an EROFS error received in response to a modification (write) request: (“NFS client sends the modification request to the NFS server. As the export is read-only, the NFS server errors out, indicating that it is a read-only file system.” [0019]. Naineni further states “the NFS client can cache the “Read Only File System” (EROFS) error it got for file modification operation” [0025]. Naineni adds “The file system client monitors the response from the file system server. If the results of the operation is an error EROFS, then the file system client sets the EROFS_flag as true and notes the current time” [0031])..
Naineni further teaches verifying…that the boot volume associated with the hypervisor is operating in the read-only mode, by re-confirming a previously detected read-only condition through a second, independent check: (“file system client 410 allows a predetermined time period to expire before checking the access type of file system export 425.” [0060]). Naineni further states: “the file system client determines whether the time interval for which the file system client should not send modification requests to the file system server has expired… If the time period has expired…then operation proceeds to block 605 to send the request to the server as usual.” [0073]. Examiner’s Note: this is the same actor as the detecting limitation above, performing a second, distinct act.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog to incorporate Naineni’s boot-volume monitoring, detecting, and verifying mechanism described above, resulting in a computing process that monitors a boot volume associated with a hypervisor, detects that the boot volume is operating in a read-only mode based at least in part on receiving one or more error codes received in response to at least one or more write requests, and verifies that the boot volume associated with the hypervisor is operating in a read-only mode. A person having ordinary skill in the art would have been motivated to make this combination because as Bhandari’s frames its problem “bugs or problems with the components or programs can result in situations in which a computing device hangs, not progressing with program execution as intended.” [0001] and a boot volume going read only is a root cause. Naineni tracks the read-only condition efficiently; it detects the state from a response it’s getting, and confirms before acting, without adding overhead to the very system the watchdog is supposed to protect and flags this efficiency tradeoff “Overhead involved in sending attribute check requests from the NFS client to the NFS server results in wasted network bandwidth.” [0020]. A watchdog has to stay lightweight, so the technique of Naineni would improve Bhandari.
Bhandari and Naineni do not teach executing, by the computing process, one or more write requests to the boot volume associated with the hypervisor.
Vastrad, in analogous art, teaches executing, by the computing process, one or more write requests to the boot volume associated with the hypervisor: “The storage proxy is configured to make multiple attempts to write a data block intercepted from a client application. This aspect provides substantial resiliency.” [007]. Vastrad further teaches “a robust fault handling approach that is designed to withstand node failures and still continue to accept write requests from client applications.” [0009].
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system of Bhandari and Naineni so the computing process itself executes write requests to the boot volume using Vastrad’s resilient multiple attempts write technique. A person having ordinary skill in the art would have been motivated to make this combination because a probing write that silently fails produces a false negative and Vastrad’s multiple attempt retry technique prevents that. Vastrad states the technique “provides substantial resiliency.” [007] and “designed to withstand node failures and still continue to accept write requests” [0009]. Applying this technique directly improves the reliability of Bhandari’s own watchdog, ensuring its probing write to the boot volume isn’t lost to a transient failure the watchdog wasn’t designed to catch.
Bhandari, Naineni, and Vastrad do not teach responsive to verifying that the boot volume associated with the hypervisor is operating in the read-only mode, executing, by the computing process, operations for rebooting the hypervisor.
However, in analogous art, Ki teaches responsive to verifying that the boot volume associated with the hypervisor is operating in the read-only mode, a read only condition is recognized trigger for a system-level remedial operation: “there is a need for a system and method for resilient operations associated with storage devices and/or systems containing storage devices” [0005]. Ki further states: “the disclosed systems can be configured to perform live migration of virtual machines even if the source device is not in a full read-only mode of operation, but rather, is in a partial read-only mode of operation” [0035] and “can be configured to perform certain opportunistic recovery operations associated with the data on the fault resilient source device that experiences a fault and is in the partial read-only mode of operation” [0035]. Ki additionally confirms “some example live migration operations can hold for device having a read only mode of operation without error” [0080]. Examiner’s Note: Ki doesn’t teach a reboot. It establishes that a verified read-only condition is treated as a trigger for remedial action. Bhandari below supplies the reboot
Bhandari teaches executing, by the computing process, operations for rebooting the hypervisor, in response to fault condition: “The hardware watchdog timer 202 operates as a watchdog timer to the hypervisor 102…If the hardware watchdog timer 202 expires, the hardware watchdog timer 202 resets the hypervisor 102” and “202 can reset the hypervisor 102 in various manners, such as by issuing a hardware reset in the computing device 100.” [0045].
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that, responsive to the verified read-only condition, it performs Bhandari’s existing reset operation as claimed. A person having ordinary skill in the art would have been motivated to make this combination because as Ki states the need directly “there is a need for a system and method for resilient operations associated with storage devices” [0005] and treats a verified read-only condition worth a remedial response.
With regards to claim 2, Bhandari, Vastrad, Naineni, and Ki teach the computer-implemented method of claim 1.
Naineni further teaches wherein the one or more error codes comprises at least one of 1) an Error - Input/Output (EIO) error code or 2) an Error – Read-Only File System (EROFS) error code “the NFS client can cache the “Read Only File System” (EROFS) error it got for file modification operation” [0025]. Naineni adds “The file system client monitors the response from the file system server. If the results of the operation is an error EROFS, then the file system client sets the EROFS_flag as true and notes the current time” [0031]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so the error code detected is specifically EROFS error. A person having ordinary skill in the art would have been motivated to make this combination because EROFS is the specific, standardized error type that indicates read-only condition. As Naineni states “the export is read-only, the NFS server errors out, indicating that it is a read-only file system [0019]” the error itself carries the diagnosis, not just a fault signal that would require further interpretation unlike a generic I/O error.
With regards to claim 7, Bhandari, Vastrad, Naineni, and Ki teach the computer-implemented method of claim 1.
Bhandari further teaches the boot volume associated with the hypervisor, as in claim 1: (“The computing device 100 includes a hypervisor 102 and at least one (shown as multiple (x)) components 104. The hypervisor is a virtual machine monitor that manages access to the functionality provided by the components 104. The components 104 can include […] one or more memory components (e.g., volatile and/or nonvolatile memory), one or more storage devices (e.g., optical and/or magnetic disks, flash memory drives) ” [0018]. Bhandari further teaches “The components 104 are virtualized to the partitions 106, and access to the components 104 is managed by the hypervisor 102.” [0019]. Bhandari further teaches “Each partition 106 can run a different instance of the same operating system” [0020]. Bhandari further teaches “Resetting the operating system 108 refers to restarting the operating system…the operating system 108 is re-booted, analogous to power cycling a physical system” [0023]).
Bhandari doesn’t teach that the boot volume associated with the hypervisor is remote with respect to the host machine and accessible via one or more networks.
Naineni further teaches Network File System is remote with respect to the host machine and accessible via one or more networks “Network File System (NFS) is one example of a distributed file system protocol allowing a user on a client computer to access files over a computer network much like local storage is accessed [0003]”. Examiner’s Note: the boot volume associated with the hypervisor is provided by Bhandari as explained in claim 1, resulting in wherein the boot volume associated with the hypervisor is remote with respect to the host machine and accessible via one or more networks.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so the boot volume being monitored is remote and network accessible. A person having ordinary skill in the art would have been motivated to make this combination because Naineni treats network accessible storage as functionally equivalent to local storage “much like local storage is accessed” meaning extending Bhandari’s watchdog to a remote boot volume requires no new architecture, just applying the same monitoring approach to storage reached over a network instead of locally.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari in view of Naineni, in view of Vastrad, in view of Ki, in view of Rosoff et al. Pub. US 20210311764 A1 (hereafter Rosoff).
With regards to claim 3, Bhandari, Vastrad, Naineni, and Ki teach the computer-implemented method of claim 1.
Naineni further teaches a second computing process executing at a second host machine, configured to monitor a boot volume: “clients 110, 112, and 114 are also connected to network 102. These clients 110, 112, and 114 may be, for example, personal computers, network computers, or the like” [0038]. Naineni further teaches that each device independently runs its own instance of the same read-only monitoring technique established for claim 1 “one or more of the computing devices, e.g., client 110-114, may be specifically configured to optimize file system client operation for read-only exports/mounts to reduce network utilization and improve performance” [0040]. Examiner’s Note: This shows more than one client machine in the same system, each independently configured to carry the same file system client role established in claim 1 resulting in, wherein the computing process is a first computing process executing at a first host machine, the first computing process being separate from a second computing process executing at a second host machine, and wherein the second computing process is configured to monitor a corresponding boot volume.
Naineni does not teach respective hypervisor executing at the second host machine.
However, in analogous art, Rosoff teaches a respective hypervisor executing at the second host machine: “System 100 includes a cluster 118 of hosts 120,” that “a hardware platform 122 of each host 120 includes conventional components of a computing device, such as one or more central processing units (CPUs) 160, system memory…,one or more network interface controllers (NICs) 164, and optionally local storage 163” [0023]; “A software platform 124 of each host 120 provides a virtualization layer, referred to herein as a hypervisor 150, which directly executes on hardware platform 122” [0025]. Examiner’s Note: Each host in Rosoff’s cluster has its own hardware platform and its own hypervisor directly executing on that hardware, a respective hypervisor per host machine.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so multiple, so that multiple separate host machines., each running its own hypervisor per Rosoff’s cluster architecture, each run their own independent instance of the watchdog process established in claim 1, per Naineni’s multi-client configuration technique. A person having ordinary skill in the art would have been motivated to make this combination because Naineni’s states the benefit as configuring each client this way may “reduce network utilization and improve performance” [0040]. A benefit that applies independently to each host running its own instance like the one Rosoff describes.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari in view of Naineni, in view of Vastrad, in view of Ki, in view of Hunt et al. Pub. No. US 10313257 B1 (hereafter Hunt).
With regards to claim 4, Bhandari, Vastrad, Naineni, and Ki teach the computer-implemented method of claim 1.
Naineni teaches verifying that the boot volume associated with the hypervisor is operating in the read-only mode, same as claim 1 cited again to show “responsive to”: “file system client 410 allows a predetermined time period to expire before checking the access type of file system export 425.” [0060]). Naineni further states: “the file system client determines whether the time interval for which the file system client should not send modification requests to the file system server has expired… If the time period has expired…then operation proceeds to block 605 to send the request to the server as usual.” [0073].”
Bhandari, Vastrad, Naineni, and Ki do not teach transmitting, by the computing process to at least one logging service, logging data indicating the boot volume associated with the hypervisor is operating in the read-only mode, wherein the logging data is transmitted utilizing Domain Name Server (DNS) data, a Transport Layer Security (TLS) certificate, and a Public Key Infrastructure (PKI) certificate that are stored in local memory of the host machine.
However, in analogous art, Hunt teaches transmitting, by the computing process to at least one logging service, logging data: “The exemplary computing environment 100 includes a number of agent data consumers 190, including, but not limited to, a compliance server 191, a log server 192, a policy server 193 …” [34]; “The compliance server 191 can also include a security information and event management (STEM) tool that is used to centralize the storage and interpretation of events, logs, or compliance reports observed and generated in an IT management infrastructure” [38]; Hunt describes transmitting part itself, by the agent, to that compliance server: “a method of controlling message flow in a computer network…comprising…sending at least one of the messages to a selected one or more of the agent data consumers” [4]; Hunt further states that the agents connect directly to the compliance server for this purpose: “Agents…can establish a network connection (e.g., to a number of agent data consumers 190, including the compliance server 191, the log server 192, the policy server 193, the change management server 194, etc.) to the agent bridge 160.” [122]. Examiner’s Note: Hunt teaches the logging service object and the transmitting act; the content that is being transmitted, the boot volume associated with the hypervisor is operating in the read-only mode, comes from the already established Bhandari/ Naineni combination above.
Hunt also states the same transmission mechanism further teaches the logging data is transmitted utilizing Domain Name Server (DNS) data “The agent can be configured dynamically using, for example, Domain Name System (DNS) Service records (SRV records) or a configuration file…using DNS SRV records for configuration is preferred when data for a particular DNS domain is sent to a single compliance server[73]”; Further, “The message broker 170 can be used to route messages between the agent bridge 160 and any of the agent data consumers 190 [122]”: Examiner’s Note: Same compliance server the logging data is addressed to above. There’s no direct line from agent to compliance server so every message headed there, including the logging data, goes agent -> bridge -> broker -> compliance server. Whatever applies to that path also applies to logging data since it’s the only road available.
Hunt further teaches a Transport Layer Security (TLS) certificate “data in messages sent from the agent to the bridge is encrypted using, e.g., transport layer security (TLS) encryption. [118]”; “The agent connection to the agent bridge 160 can be encrypted using, e.g., Transport Layer Security, Secure Sockets Layer, or other suitable encryption scheme” [122]: Examiner’s Note: [118] isn’t limited by message type and since logging has no path to the compliance server except through the bridge, it’s necessarily one of the messages covers this. Hunt further teaches that this same certificate is a Public Key Infrastructure (PKI) certificate…that are stored in local memory of the host machine: “the agent checks to determine whether it has already been registered. If the agent has not been registered, then the agent generates keys and a certificate signing request (CSR) [145]”; “the agent platform server signs the CSR, and sends the signed CSR to the agent in an agent registration response message [147]” and “the agent converts the signed CSR to a Privacy Enhanced Mail (PEM) format certificate and stores the PEM certificate in a local computer readable storage media” [148]; Further, “the agent loads an agent identification certificate [156]”. Further, “generation of a certificate 610 by the agent platform server based on both the agent identification certificate 620 loaded at act 512 and the bridge identification certificate 630 sent with the agent platform server hello message at act 540” and “The certificate 610 can be used to authenticate communications between agents and agent bridges [159]”. Examiner’s Note: Same certificate throughout loaded again later as the “agent identification certificate”. That certificate is then used to build one that authenticates agent bridge communications, same connection the logging data rides on, covering both TLS and PKI. Hunt doesn’t says “PKI” but based on the process itself, key generated, CSR signed by a server, certificate issued back, is the standard PKI workflow.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that, responsive to verifying the read only condition as Naineni teaches, it transmits logging data to a logging service the way Hunt describes (located via DNS, secured by a TLS/PKI certificate held in local memory) as claimed. A person having ordinary skill in the art would have been motivated to make this combination because Naineni’s own architecture already ties a response to this exact verification step, “If the mount type is read-only, then the file system client returns a version specific EROFS error to the user (block 610) [0072]” once the time period check confirms the condition holds. So that verify then report structure is already there. Substituting Hunt’s DNS/TLS/PKI secured transmission for Naineni’s error return verification is just a straightforward substitution.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari in view of Naineni, in view of Vastrad, in view of Ki, in view of Tsai et al. Pub. No. US 20160119180 A1 (hereafter Tsai).
With regards to claim 5, Bhandari, Vastrad, Naineni, and Ki teach the computer-implemented method of claim 1.
Naineni teaches verifying that the boot volume associated with the hypervisor is operating in the read-only mode, same as claim 1 cited again to show “responsive to”: “file system client 410 allows a predetermined time period to expire before checking the access type of file system export 425.” [0060]). Naineni further states: “the file system client determines whether the time interval for which the file system client should not send modification requests to the file system server has expired… If the time period has expired…then operation proceeds to block 605 to send the request to the server as usual.” [0073].”
Bhandari, Vastrad, Naineni, and Ki do not teach transmitting, by the computing process to a baseboard management controller of the host machine, one or more console messages indicating the boot volume associated with the hypervisor is operating in the read-only mode, wherein the baseboard management controller persists the one or more console messages in local memory at the host machine.
However, in analogues art, Tsai teaches transmitting, by the computing process to a baseboard management controller of the host machine, one or more console messages:
“a service processor (e.g., a baseboard management controller) is an independent and embedded microcontroller that monitors and manages the operation status of a server” [0017]; and “service controller 114 can be a baseboard management controller that implements all or part of the Intelligent Platform Management Interface (IPMI) specification” [0021]; “the service controller can receive console messages (e.g., system error messages) generated by the main CPU (e.g., primary controller) and/or the operating system or BIOS of the monitored server.” [0015];
“server 102 can generate system log messages (e.g., error messages) that are transmitted to the serial port of server 102. Service controller 114 can receive the system log messages destined for the serial port and redirect the system log messages to a network interface controller [0022].” Tsai further states “the service controller can be a baseband management controller (BMC) embedded in the motherboard of the computing device” [0014].
Tsai further teaches the baseboard management controller persists the one or more console messages in local memory at the host machine “log manager 210 can store the system log messages in log buffer 212. Log buffer 212 can be a non-volatile storage medium (e.g., flash memory) associated with service controller” [0025]. Examiner’s Note: Since Tsai’s BMC is “embedded in the motherboard of the computing device,” this non-volatile storage medium is local memory at the host machine itself.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that, responsive to verifying the read-only condition taught by Naineni, it transmits console messages to a BMC that persists them locally. A person having ordinary skill in the art would have been motivated to make this combination because as Tsai states the problem “If the system administrator is not monitoring or not connected to the computing device to receive the console messages, the console messages may be lost because the console messages are merely streamed out and not stored. If the console messages are lost, the system administrator will not be able to debug the problem with the computing device based on the console messages [0002].” Bhandari’s watchdog faces the same risk since a diagnostic message is worthless if its lost before anyone reads it. The substitution is also structurally natural since Naineni already responds to this exact verification step “the file system client returns a version specific EROFS error to the user (block 610) [0072]”, and Tsai responds to its own detected trigger the same way by the same actor “the service controller can detect that the computing device..is being powered on [0038]” then “upon rebooting..the computing device, the service controller can copy the console messages stored in non-volatile memory to persistent storage [0016]”. So triggering Tsai’s persist to local memory technique off Naineni’s verification is a straightforward substitution.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari in view of Naineni, in view of Vastrad, in view of Ki, further in view of Lipinski et al. Pub. No. US 20110083004 A1 (hereafter Lipinski)
With regards to claim 6, Bhandari, Vastrad, Naineni, and Ki teach the computer-implemented method of claim 1.
Bhandari, Vastrad, Naineni, and Ki do not teach that wherein executing the operations for rebooting the hypervisor causes the hypervisor to enter a wait-for-recovery mode during which a boot loop is executed, wherein executing the boot loop causes the hypervisor to wait for a network dependency on the boot volume to be met prior to attempting to boot from the boot volume.
However, in analogues art, Lipinski teaches enter a wait-for-recovery mode during which a boot loop is executed, wherein executing the boot loop causes…wait for a network dependency…to be met prior to attempting to boot: “the boot selection program 124 boots…the headless server computer 100 into recovery mode, in which the PXE client 126 is started” [0033]. Further states “It is determined whether the PXE server 140 is detected or the PXE client 126 has timed out…if the PXE client 126 has timed out and exited, control proceeds back to task 207, where the PXE client 126 is re-started by the boot selection program 124 in the headless server computer 100… Tasks 208 and 209 are then repeated. However, once the PXE server 140 starts and the PXE client 126 detects (at 209) the PXE server 140, the process proceeds to task 210” [0036]. Further confirms this repeats until the network dependency resolves “re-invocation of the PXE client 126 can be retried an indefinite number of times until the PXE server 140 is detected” [0037]. Examiner’s Note: In the combined system of claim 1, the same looping wait for network dependency mechanism is applied to the boot volume resulting in, the hypervisor to wait for a network dependency on the boot volume to be met prior to attempting to boot from the boot volume.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so that, upon rebooting the hypervisor, the hypervisor enters a recovery mode that executes Lipinski‘s repeating wait-and-retry loop for the network dependency needed to reach the boot volume before attempting to boot from it. A person having ordinary skill in the art would have been motivated to make this combination so the hypervisor does not attempt to boot from a boot volume it cannot yet reach over the network, as Lipinski teaches that “the network boot allows for loading of software to successfully start the computer” [0020], and attempting to boot before network dependency is detected would defeat successful start, which is what the wait-and-retry mechanism is designed to avoid.
Claims 8, 9, 14, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari in view of Naineni, in view of Ki.
With regards to claim 8, Bhandari teaches a watchdog daemon associated with a hypervisor of a computing device, the computing device comprising: one or more processors; and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the watchdog daemon to (“computing device 100 includes a hypervisor 102 and at least one (shown as multiple (x)) components 104…the components 104 can include one or more processors or processor cores, one or more memory components (e.g., volatile and/or nonvolatile memory)” [0018]. Bhandari further states “A hypervisor watchdog timer associated with a partition is re-armed in response to a re-arm request from an operating system in the partition. If the hypervisor watchdog timer expires, the operating system is reset.” [0003]).
Bhandari further teaches a boot volume associated with a hypervisor of the computing device (“the components 104 can include…one or more storage devices (e.g., optical and/or magnetic disks, flash memory drives)…Various components or modules running on the computing device 100, including hypervisor 102, can access this functionality managed by components 104” [0018]. Bhandari further teaches “Resetting the operating system 108 refers to restarting the operating system…the operating system 108 is re-booted, analogous to power cycling a physical system” [0023]).
Bhandari does not teach transmit, via a network, a first write request corresponding to a boot volume.
However, in analogous art, Naineni teaches transmit, via a network, a first write request corresponding to a boot volume “Network File System (NFS) is one example of a distributed file system protocol allowing a user on a client computer to access files over a computer network much like local storage is accessed [0003]”. Naineni further states “the NFS client sends the modification request to the NFS server. As the export is read-only, the NFS server errors out, indicating that it is a read-only file system [0019]”.
Naineni further teaches detect a first error code corresponding to the first write request, the first error code indicating that the boot volume…is operating in a read-only mode “states “the NFS client can cache the “Read Only File System” (EROFS) error it got for file modification operation [0025]”. Naineni further states “The file system client monitors the response from the file system server. If the results of the operation is an error EROFS, then the file system client sets the EROFS_flag as true and notes the current time. [0031]”.
Naineni further teaches in response to detecting the first error code, transmit a second write request corresponding to the boot volume “by re-confirming a previously detected read-only condition through a second, independent check: (“file system client 410 allows a predetermined time period to expire before checking the access type of file system export 425.” [0060]). Naineni further states: “the file system client determines whether the time interval for which the file system client should not send modification requests to the file system server has expired… If the time period has expired…then operation proceeds to block 605 to send the request to the server as usual.” [0073]. Examiner’s Note: this is the same actor as the detecting limitation above, performing a second, distinct act.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that it transmits a write request to the boot volume over a network, detects an error code from the response indicating a read-only condition, and transmits a second write request. A person having ordinary skill in the art would have been motivated to make this combination because as Bhandari’s frames its problem “bugs or problems with the components or programs can result in situations in which a computing device hangs, not progressing with program execution as intended.” [0001] and a boot volume going read only is a root cause. Naineni supplies a low overhead technique for detecting and re-confirming that condition without adding load to the system as Naineni flags this efficiency tradeoff “Overhead involved in sending attribute check requests from the NFS client to the NFS server results in wasted network bandwidth.” [0020]. A watchdog has to stay lightweight, so the technique of Naineni would improve Bhandari.
Bhandari and Naineni do not teach in response to detecting at least the first error code, execute one or more operations associated with rebooting the hypervisor.
However, in analogous art, Ki teaches that a read only condition is recognized trigger for a system-level remedial operation: “there is a need for a system and method for resilient operations associated with storage devices and/or systems containing storage devices” [0005]. Ki further states: “the disclosed systems can be configured to perform live migration of virtual machines even if the source device is not in a full read-only mode of operation, but rather, is in a partial read-only mode of operation” [0035] and “can be configured to perform certain opportunistic recovery operations associated with the data on the fault resilient source device that experiences a fault and is in the partial read-only mode of operation” [0035]. Ki additionally confirms “some example live migration operations can hold for device having a read only mode of operation without error” [0080]. Examiner’s Note: Ki doesn’t teach a reboot. It establishes that a verified read-only condition is treated as a trigger for remedial action. Bhandari below supplies the reboot
Bhandari teaches execute one or more operations associated with rebooting the hypervisor, in response to fault condition: “The hardware watchdog timer 202 operates as a watchdog timer to the hypervisor 102…If the hardware watchdog timer 202 expires, the hardware watchdog timer 202 resets the hypervisor 102” and “202 can reset the hypervisor 102 in various manners, such as by issuing a hardware reset in the computing device 100.” [0045].
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that, responsive to detecting at least the first error code, it performs Bhandari’s existing reset operation as claimed. A person having ordinary skill in the art would have been motivated to make this combination because as Ki states the need directly “there is a need for a system and method for resilient operations associated with storage devices” [0005] and treats a verified read-only condition worth a remedial response.
With regards to claim 9, Bhandari, Naineni, and Ki teach the computer-implemented method of claim 8.
Bhandari further teaches the watchdog daemon was deployed to the computing device as part of the hypervisor “The computing device 502 also includes hypervisor with hypervisor watchdog timers 514. The hypervisor with hypervisor watchdog timers 514 provides various watchdog timer functionality to operating systems running in partitions on the computing device 502 [0079]”.
With regards to claim 14, Bhandari teaches a non-transitory computer-readable medium comprising one or more memories storing computer-executable instructions corresponding to a watchdog daemon that, when executed by one or more processors of a computing device, causes the watchdog daemon to “A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se” [0063].” Bhandari further teaches (“computing device 100 includes a hypervisor 102 and at least one (shown as multiple (x)) components 104…the components 104 can include one or more processors or processor cores, one or more memory components (e.g., volatile and/or nonvolatile memory)” [0018]. Bhandari further states “A hypervisor watchdog timer associated with a partition is re-armed in response to a re-arm request from an operating system in the partition. If the hypervisor watchdog timer expires, the operating system is reset.” [0003]).
Bhandari further teaches to a boot volume associated with a hypervisor executing at the computing device ( “the components 104 can include one or more processors or processor cores, one or more memory components (e.g., volatile and/or nonvolatile memory), one or more storage devices (e.g., optical and/or magnetic disks, flash memory drives)…Various components or modules running on the computing device 100, including hypervisor 102, can access this functionality managed by components 104” [0018]. Bhandari further teaches “Resetting the operating system 108 refers to restarting the operating system…the operating system 108 is re-booted, analogous to power cycling a physical system” [0023]).
Bhandari does not teach monitor access to a boot volume, or transmit, via one or more networks, periodic requests to the boot volume
However, in analogous art, Naineni teaches monitor access to boot volume, by a file system client that tracks a mounted export’s state and checks every incoming request against it (“file system client 410 mounts file system export 425 from file system server 420 as file system export/mount 415. After file system client 410 successfully mounts the file system export/mount 415, in addition to its usual operations, file system client 410 saves the access type 416 (read-only/read-write) of the mounted file system” [0057]. Naineni further states “While working on each file system request for mounted file system export 415, file system client 410 determines whether each file system request is a modification request. [0058]”. Naineni shows repeated state check “for each modification request, file system client 410 checks access type 416.” [0059]. Naineni also shows what type of resource being monitored “server 104 provides data, such as boot files, operating system images, and applications to the clients” [0038]).
Naineni teaches transmit, via one or more networks, periodic requests to the boot volume “Network File System (NFS) is one example of a distributed file system protocol allowing a user on a client computer to access files over a computer network much like local storage is accessed [0003]”. Naineni further states “file system client 410 allows a predetermined time period to expire before checking the access type of file system export 425.” [0060], and “If the time period has expired…then operation proceeds to block 605 to send the request to the server as usual.” [0073].”)
Naineni further teaches receive a response to a request of the periodic requests, the response indicating that the boot volume…is in a read-only mode “NFS client sends the modification request to the NFS server. As the export is read-only, the NFS server errors out, indicating that it is a read-only file system.” [0019]. Naineni adds “The file system client monitors the response from the file system server. If the results of the operation is an error EROFS, then the file system client sets the EROFS_flag as true and notes the current time” [0031] ).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that it monitors access to the boot volume, transmits periodic network requests to it, and receives responses indicating a read-only condition. A person having ordinary skill in the art would have been motivated to make this combination because as Bhandari’s frames its problem “bugs or problems with the components or programs can result in situations in which a computing device hangs, not progressing with program execution as intended.” [0001] and a boot volume going read only is a root cause. Naineni supplies a low overhead technique for detecting and re-confirming that condition without adding load to the system as Naineni flags this efficiency tradeoff “Overhead involved in sending attribute check requests from the NFS client to the NFS server results in wasted network bandwidth.” [0020]. A watchdog has to stay lightweight, so the technique of Naineni would improve Bhandari.
Bhandari and Naineni do not teach perform one or more remedial actions based at least in part on receiving the response indicating that the boot volume associated with the hypervisor is in the read-only mode.
However, in analogous art, Ki teaches perform one or more remedial actions based at least in part on receiving the response indicating that the boot volume…is in the read-only mode: “there is a need for a system and method for resilient operations associated with storage devices and/or systems containing storage devices” [0005]. Ki further states: “the disclosed systems can be configured to perform live migration of virtual machines even if the source device is not in a full read-only mode of operation, but rather, is in a partial read-only mode of operation” [0035], and Ki additionally confirms “some example live migration operations can hold for device having a read only mode of operation without error” [0080].
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that, responsive to detecting the read only condition, it performs Ki’s live migration as one of the remedial actions. A person having ordinary skill in the art would have been motivated to make this combination because as Ki states the need directly “there is a need for a system and method for resilient operations associated with storage devices” [0005] and treats a verified read-only condition worth a remedial response.
With regards to claim 16, Bhandari, Naineni, and Ki teach the non-transitory computer-readable medium of claim 14.
Naineni further teaches receive a second response to a second request of the periodic requests, the second response indicating that the boot volume…is in a read-only mode “file system client 410 allows a predetermined time period to expire before checking the access type of file system export 425.” [0060]). Naineni further states: “If the time period has expired…then operation proceeds to block 605 to send the request to the server as usual.” [0073] and “The file system client monitors the response from the file system server. If the results of the operation is an error EROFS, then the file system client sets the EROFS_flag as true and notes the current time” [0031])”.
Ki further teaches the one or more remedial actions are performed further based at least in part on receiving the second response indicating that the boot volume…is in the read-only mode. Ki states “The host 105 may poll the storage devices 110 on a predetermined schedule [0060]” and that “the storage device 110 posts the status upon request from the host 105 based on an application programming interface (API)… the host 105 routes data of a given type to the storage device 110 or to a different storage device 110 at a given bandwidth based on the status. [0058]”.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so the remedial action established in claim 14 is triggered based on both the first and second responses rather than the first alone, per Naineni’s recheck mechanism and Ki’s own polling based status routing. A person having ordinary skill in the art would have been motivated to make this combination because Ki itself is built around repeating checking “The host 105 may poll the storage devices 110 on a predetermined schedule” rather than relying on one status report. The same rationale already supporting Naineni’s own interval based recheck, that a single response is provisional and worth reconfirming before a remedial action is taken.
With regards to claim 19, Bhandari, Naineni, and Ki teach the non-transitory computer-readable medium of claim 14.
Naineni further teaches wherein the response comprises an input/output error or a read-only filesystem error, and wherein the input/output error or the read-only filesystem error provide an indication that file system export 425 is in the read-only mode. “the NFS client can cache the “Read Only File System” (EROFS) error it got for file modification operation” [0025]. Naineni adds “the NFS server errors out, indicating that it is a read-only file system.” [0019]. Examiner’s Note: Bhandari provides the boot volume associated hypervisor resulting in, the read-only filesystem error provide an indication that the boot volume associated with the hypervisor is in the read-only mode.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so the error code detected is specifically EROFS error. A person having ordinary skill in the art would have been motivated to make this combination because EROFS is the specific, standardized error type that indicates read-only condition. As Naineni states “the export is read-only, the NFS server errors out, indicating that it is a read-only file system [0019]” the error itself carries the diagnosis, not just a fault signal that would require further interpretation unlike a generic I/O error.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari, in view of Naineni , in view of Ki, further in view of Wills et al. Pub. No. US 12190139 B1 (hereafter Wills)
With regards to claim 10, Bhandari, Naineni, and Ki teach the watchdog daemon of claim 8.
Bhandari, Naineni, and Ki do not teach that wherein the watchdog daemon operates as a background process at the computing device, and wherein execution of the watchdog daemon is initiated by a system manager of an operating system of the computing device.
However, in analogues art, Wills teaches wherein the watchdog daemon operates as a background process at the computing device: “The purpose of watchdog 648 is to maintain the uptime of Zero Agent 610 and other managed non-language agents” [122], and “it is the responsibility of the entity to keep it up and running by integrating it with their known lifecycle management tools. [124]”. Examiner’s Note: A process that has to stay running on its own to continuously maintain another process’s uptime, not one a user kicks off each time, is operating as a background process.
Wills further teaches wherein execution of the watchdog daemon is initiated by a system manager of an operating system of the computing device “watchdog 648 binary may be installed and integrated with systemd 604, if allowed” [122] and “Watchdog 648 itself may be managed via systemd 604, if such an integration is allowed” [124].
It would have been obvious to a person having ordinary skill in the art prior to the effective filling date of the claimed invention to modify Bhandari’s watchdog daemon so that it runs as a background process initiated by the operating system’s system manager, in the manner Wills describes. A person having ordinary skill in the art would have been motivated to make this combination because as Wills states without systemd integration “it is the responsibility of the entity to keep it up and running by integrating it with their known lifecycle management tools” [124]. Letting the operating system’s system manager initiate and maintain removes the manual burden with is what Bhandari’s watchdog would benefit from.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari, in view of Naineni , in view of Ki , further in view of Domrow et al. Pub. No. US 20180131562 A1 (hereafter Domrow)
With regards to claim 11, Bhandari, Naineni, and Ki teach the watchdog daemon of claim 8.
Bhandari, Naineni, and Ki do not teach wherein the watchdog daemon is configured to detect, based at least in part on detecting the first error code, at least one of: expiration of a Small Computer System Interface (SCSI) command timer, expiration of an Internet Small Computer System Interface (iSCSI) replacement timer, or an iSCSI session logout.
However, in analogous art, Domrow teaches detect…expiration of a Small Computer System Interface (SCSI) command timer “The underlying problem in a SAN often does not produce a red light error indication so symptoms of a failure may be limited to symptoms such as a small computer system interface (SCSI) command time-out visible at the server” [0005]. Domrow further states detection itself “a SCSI command timeout or adapter error is detected, such as, but not limited to: transport dead, transport fault, no device response, adapter hardware failure, and adapter software failure” [0037] and “then processing continues at block 314 to determine if there is a command timeout (e.g., a SCSI command timeout). If there is a command timeout, then processing continues at block 316 to determine whether there have been multiple command timeouts within a specific time interval” [0038]. Examiner’s Note: In the combined system, this SCSI timeout check is added as an additional diagnostic mode the watchdog runs alongside its Naineni EROFS detection (claim 8 first error code), so that detecting the first error code is what leads the watchdog to also check the SCSI layer for a timeout condition resulting in, wherein the watchdog daemon is configured to detect, based at least in part on detecting the first error code, at least one of: expiration of a Small Computer System Interface (SCSI) command timer, expiration of an Internet Small Computer System Interface (iSCSI) replacement timer, or an iSCSI session logout.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply Domrow’s SCSI command-timeout detection technique to the combined system’s already-established error-code detection, resulting in a watchdog daemon that detects expiration of SCSI command timer based at least in part on detecting the first error code. A person having ordinary skill in the art would have been motivated to make this combination because, as Domrow teaches “The underlying problem in a SAN often does not produce a red light error indication so symptoms of a failure may be limited to symptoms such as…(SCSI) command time-out visible at the server”[0005]. A watchdog that already detected one fault signal (EROFS error) benefits from checking this additional signal rather than relying on a single error.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari, in view of Naineni , in view of Ki, further in view of Attaluri et al. Pub. No. US 11615083 B1 (hereafter Attaluri)
With regards to claim 12, Bhandari, Naineni, and Ki teach the watchdog daemon of claim 8.
Bhandari, Naineni, and Ki do not teach wherein a number of tasks, memory usage, and disk storage corresponding to the watchdog daemon is limited.
However, in analogous art, Attaluri teaches wherein a number of tasks, memory usage, and disk storage corresponding to the watchdog daemon is limited: the process “may be done in a standalone process, with a software “jail” built around it, using a downgraded security context, seccomp, cgroups, and potentially other hostile code execution mitigation techniques, in embodiments” [64] referring to it as “a process (e.g., a daemon)” [65]. Attaluri further states the memory and task limit “a process (e.g., a daemon) for query processing may have a hard limit of the memory and CPU footprint, to guard against resource drain” [65]. Attaluri further states the disk storage limit for the same process “storage nodes may limit the resources consumed by individual requests and instances to avoid causing service degradation for other tenants on the storage node” [83].
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify Bhandari’s watchdog so that its tasks, memory usage, and disk storage are limited, in the manner Attaluri describes, as claimed. A person having ordinary skill in the art would have been motivated to make this combination because Attaluri states purpose directly as “to avoid causing service degradation for other tenants” [83]. A watchdog carries same risk if left without limit making Attaluri’s technique a natural apply to Bhandari’s watchdog.
Claim(s) 13 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari, in view of Naineni, in view of Ki, further in view of Rathbone et al. Pub. No. US 10002041 B1 (hereafter Rathbone).
With regards to claim 13, Bhandari, Naineni, and Ki teach the watchdog daemon of claim 8.
Bhandari, Naineni, and Ki do not teach wherein the watchdog daemon is restricted from rebooting the hypervisor unless the hypervisor has been executing for a period of time that exceeds a threshold period of time.
However, in analogues art, Rathbone restricted from rebooting the hypervisor unless the hypervisor has been executing for a period of time that exceeds a threshold period of time: “Information pertaining to the length of time a client machine has been running since the last reboot may be retrieved…in order to determine…whether a designated time threshold value has been exceeded…a trigger specification may be set that requires a reboot of the client machine at least once every 48 hours (i.e., the time threshold value)” [31]. Rathbone further teaches “When the time lapsed since the last reboot is determined, at block 406, to exceed the designated time threshold value, a health-risk event and a corresponding notification may be generated…the action to remedy the detected health-risk event representative of an uptime exceeding desired uptime parameters for optimal performance may be a required reboot of the client machine” [32].
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system of claim 8 so that it is restricted from rebooting the hypervisor unless this same uptime threshold has been exceeded. A person having ordinary skill in the art would have been motivated to make this combination because Rathbone itself treats an unrestricted reboot as something to avoid when necessary “the client machine may be automatically restarted in the off hours when the end user is not using the client machine. [33]” showing a deliberate design choice to hold back a reboot until conditions justify it rather than doing it immediately. Bhandari’s watchdog would do the same way to avoid disrupting a hypervisor that hasn’t yet had a fair chance to run.
With regards to claim 17, Bhandari, Naineni, and Ki teach the non-transitory computer-readable medium of claim 14. As established in claim 14, Ki teaches performing one or more remedial actions responsive to receiving the response indicating that the boot volume is in a read-only mode.
Bhandari, Naineni, and Ki, do not teach wherein executing the computer-executable instructions corresponding to the watchdog daemon further causes the watchdog daemon to: identify a time at which the hypervisor was last booted; and responsive to determining that a threshold time has elapsed since the time at which the hypervisor was last booted, reboot the hypervisor as part of performing the one or more remedial actions.
However in analogous art, Rathbone teaches identifying a time at which a machine was last booted, and responsive to determining that a threshold time has elapsed since that time, rebooting the machine: “Information pertaining to the length of time a client machine has been running since the last reboot may be retrieved…in order to determine…whether a designated time threshold value has been exceeded…a trigger specification may be set that requires a reboot of the client machine at least once every 48 hours (i.e., the time threshold value)” [31]. Rathbone further states “If the action required is not taken by the end user within the allotted time period, health monitoring agent module 210 may automatically take action…deploying the uptime plug-in residing on the client machine to engage a reboot command [33]”. Examiner’s Note: Rathbone’s reboot target is generic (the client machine), the specific object being rebooted comes from the Hypervisor from Bhandari already established in claims 1/8/14: “The hardware watchdog timer 202 operates as a watchdog timer to the hypervisor 102…If the hardware watchdog timer 202 expires, the hardware watchdog timer 202 resets the hypervisor 102” and “202 can reset the hypervisor 102 in various manners, such as by issuing a hardware reset in the computing device 100.” [0045, resulting in wherein executing the computer-executable instructions corresponding to the watchdog daemon further causes the watchdog daemon to: identify a time at which the hypervisor was last booted; and responsive to determining that a threshold time has elapsed since the time at which the hypervisor was last booted, reboot the hypervisor as part of performing the one or more remedial actions.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so that the watchdog daemon tracks time since the hypervisor’s last boot and reboots once a threshold is exceeded, in the manner Rathbone describes, as claimed. A person having ordinary skill in the art would have been motivated to make this combination to because as Rathbone states the gap “there is little or no monitoring of the health of machines on a computer network. Generally, machines on a computer network are monitored by human operators who are alerted to detected problems on a machine-by-machine basis as they arise. This approach requires a large investment in human resources…[and] human operators are prone to mistakes, which can result in further end-user frustration and potential loss of data. [2]” A watchdog that reboots proactively removes the need for human to notice and act, addressing exact problem Rathbone describes.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari in view of Naineni, in view of Ki, in view of Hunt.
With regards to claim 15, Bhandari, Naineni, and Ki teach the non-transitory computer-readable medium of claim 14.
Bhandari, Naineni, and Ki do no teach wherein the one or more remedial actions comprise transmitting logging data to one or more logging services, wherein transmitting the logging data to the one or more logging services causes a status corresponding to the boot volume to be presented at a user interface, the status indicating the boot volume is operating in the read-only mode.
However, in analogous art, Hunt teaches transmitting logging data to one or more logging services: “the CCC tool can store detected change event data in an event log or transmit the event data as soon as it is detected or shortly after it is detected. [36]”. Hunt further identifies a dedicated logging service as the recipient “The exemplary computing environment 100 includes a number of agent data consumers 190, including, but not limited to, a compliance server 191, a log server 192, a policy server 193, a change management server 194 [34]”.
Hunt further teaches causes a status…to be presented at a user interface, the status indicating the boot volume is operating in the read-only mode “The compliance-related reports generated by the CCC tool can, in some instances, comprise a score for a node that indicates the relative compliance status of the node as a numerical value in a range of possible values” generated from “one or more reports concerning the monitored nodes showing a wide variety of information [36]”. Examiner’s Note: Hunt’s status reflects whatever event data was transmitted. Here the event data is the boot volume’s read-only condition established by Naineni above, so resulting in wherein transmitting the logging data to the one or more logging services causes a status corresponding to the boot volume to be presented at a user interface, the status indicating the boot volume is operating in the read-only mode.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to modify the combined system so that Ki’s remedial action is carried out specifically as Hunt’s log transmission and status reporting mechanism as claimed. A person having ordinary skill in the art would have been motivated to make this combination as Hunt states value of presenting status at a user interface directly “The SIEM can be used to provide a consistent central interface that an IT administrator can use to more efficiently monitor and manage activity and configuration changes in an IT network [38]”. A boot volume stuck in read only mode is the kind of activity an administrator needs visibility into.
Claims 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari, in view of Naineni, in view of Ki, in view of Rathbone, further in view of Tsai.
With regards to claim 18, Bhandari, Naineni, Ki, and Rathbone teach the non-transitory computer-readable medium of claim 17.
Bhandari, Naineni, Ki, and Rathbone do not teach wherein executing the computer-executable instructions corresponding to the watchdog daemon further causes the watchdog daemon to print a message to a console prior to rebooting the hypervisor.
However, in analogues art, Tsai teaches a host-side process that print a message to a console prior to rebooting/crash event: “the computing device will generate console messages leading up to the crash that can give clues as to the cause of the crash” [0002] and “the service controller can receive console messages (e.g., system error messages) generated by the main CPU (e.g., primary controller) and/or the operating system or BIOS of the monitored server” [0015]. Examiner’s Note: Tsai’s console message are generic and teach the print-to console mechanism and its “leading upto timing”. The hypervisor reboot triggered by Rathbone’s elapsed time threshold comes from already established Bhandari/Rathbone claim 17 resulting in, wherein executing the computer-executable instructions corresponding to the watchdog daemon further causes the watchdog daemon to print a message to a console prior to rebooting the hypervisor.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combined system so that, prior to Rathbone’s threshold triggered reboot, the watchdog daemon prints a message to the console in the manner Tsai describes, resulting in a watchdog daemon that prints a message to a console prior to rebooting the hypervisor. A person having ordinary skill in the art would have been motivated to make this combination so the printed message can give clues as to the cause of the condition prompting the reboot, as Tsai teaches that “console messages leading up to the crash that can give clues as to the cause of the crash” [0002].
Claims 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari, in view of Naineni, in view of Ki, further in view of Beebe et al. Pub. US 20110060948 A1 (hereafter Beebe).
With regards to claim 20, Bhandari, in view of Naineni, in view of Ki teaches the non-transitory computer-readable medium of claim 14.
Bhandari, Naineni, and Ki do not teach wherein executing the computer-executable instructions corresponding to the watchdog daemon further causes the watchdog daemon to transmit one or more metrics to one or more logging services prior to rebooting the hypervisor.
However, in analogous art, Beebe teaches transmit one or more metrics to one or more logging services “The captured data may include significant status metrics, including other serious error conditions, such as: memory status (periodical, high and low stats); timeouts (DNS, Registration, SIP Proxy); module restarts; module critical errors; MOS score of previous calls; and error codes/log numbers (minimal size of data)” [0048].
Bhandari, as established in claim 1 and 8 above, separately teaches rebooting the hypervisor. “The hardware watchdog timer 202 operates as a watchdog timer to the hypervisor 102…If the hardware watchdog timer 202 expires, the hardware watchdog timer 202 resets the hypervisor 102” and “202 can reset the hypervisor 102 in various manners, such as by issuing a hardware reset in the computing device 100.” [0045]. Beebe’s metric capture occurs before Bhandari’s reset is executed, resulting in transmit one or more metrics to one or more logging services prior to rebooting the hypervisor.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention so that watchdog daemon transmits Beebe’s status metrics to a logging service before Bhandari’s reset executes, as claimed. A person having ordinary skill in the art would have been motivated to make this combination because Beebe ties this exact data capture to the same kind of event “an automated trigger may occur in the event of a abnormal reboot (crash); a communications device 12 reboot… approaching memory usage thresholds… or other abnormal events. [0049]”. A reboot can erase the operating conditions that led to it so capturing and transmitting metrics first, the way Beebe describes, preserves that before it's lost.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11921699 B1
Teaches
Database failover via time-limited “consistency leases”
US 11953985 B1
Teaches
Auto recovers a VM’s guest OS by running template driven recovery steps
US 11126563 B1
Teaches
Tracks write to virtual memory page via a monitoring process
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEZMURE DAWIT whose telephone number is (571)270-5581. The examiner can normally be reached Mon-Fri 7:30am-5pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. visit: https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service
Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MEZMURE DAWIT/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights