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 .
Response to Amendments
This final office action is in response to the amendments filed 02/25/2026. In
which, claims 1-14 and 16-19 have been amended, no claims have been cancelled, and claims 1-20 remain pending in the application.
Response to Amendment
The amendment filed on 02/25/2026 has been entered. See response to
amendments.
Response to Arguments
Examiner’s response to applicant’s 35 USC § 103 claim rejection remarks.
Applicant’s amendments and arguments in pages 10-13 regarding independent
claims 1, 17 and 19 are fully considered and are persuasive however arguments
are moot in view of new ground of rejection below.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 7, 14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ndu et al. (US-20210026948-A1 hereafter Ndu), in view of ZHOU et al. (CN-117112353-A hereafter ZHOU), in further view of Wu et al. (CN-114237831-A hereafter Wu).
Regarding claim 1 Ndu discloses a kernel monitoring device comprising (see Ndu par.0020: “the monitor is also able to verify the integrity of a hypervisor that is part of the OS,”, par.0030: “the interconnect endpoint device 108 can include a management controller such as a baseband management controller (BMC).”, par.0084: “The monitor 120 can monitor an integrity of a critical or static part of an OS kernel.”):
a communication interface to communicate with a processing resource that
executes a plurality of virtual machines (VMs) comprising a first VM and
a second VM (see Ndu par.0035: “electronic components can communicate over the communication interconnect 106 according to a Peripheral Component Interconnect Express (PCIe) protocol, which is a high-speed serial computer expansion bus standard.”, par.0039: “The processor 102 executes an OS 111. In some examples where virtualized environments are used, the OS 111 can include a hypervisor 114.”, furthermore: “the monitor 120 runs on a processor (108) that is separate from the processor 102 (first VM) or 104 (second VM) running the OS being monitored, the monitor 120 does not have to suspend the monitored OS. Not suspending the OS can reduce overhead associated with OS integrity monitoring.”); and
a device processor to (see Ndu par.0022: “monitors may be executed in a privileged execution mode of a processor, such as a system management mode (SMM), an Advanced Reduced Instruction Set Computing (RISC) Machine (ARM) EL3 privilege mode (which is a privilege level reserved for low-level firmware in security code, for example), and so forth.”):
detect that kernel monitoring of the first VM is to be performed (See Ndu par.0045: "The monitor 120 uses virtual addresses contained in the monitoring metadata 118 to look up physical addresses in the page table 122 (which maps the virtual addresses to the physical address). The virtual addresses included in the monitoring metadata 118 can include virtual addresses of OS invariant information to be monitored.”); and
measure the received information to determine an integrity of the kernel of the first VM. (See Ndu par.0055-0057: “The monitor 120 accesses (at 206) the page table 122 using the gathered information to obtain physical addresses for OS invariant information to be monitored. For example, the gathered information can include virtual addresses of the OS invariant information. The virtual addresses of the OS invariant information can be provided to the page table 122, and the monitor retrieves, based on the access of the page table 122, respective physical addresses of memory locations in the memory 112 where the OS invariant information 124 is stored. The monitor 120 monitors (at 208) the OS invariant information (retrieved from the memory locations of the physical addresses obtained by the monitor 120 by accessing the page table 122) and/or other data structures. The monitor 120 determines (at 210), based on the monitored OS invariant information and/or other data structures, whether a security issue is present in the computer system 100.”, Examiner interpret that memory access allocated in the OS variant is being measured to determine if there has been changes in the access page table of the memory locations of the OS. The invariant information include machine-readable instructions that are part of the kernel. Any change or deviation of the invariant information can indicate malware).
Ndu do not explicitly teach in response to the detecting, check whether a connection exists between the kernel monitoring device and another VM; based on detecting that a connection exists between the kernel monitoring device and the second VM, send a hot remove request from the kernel monitoring device to hot remove the kernel monitoring device from the second VM; based on receiving, at the kernel monitoring device, a confirmation that the kernel monitoring device has been hot removed from the second VM, trigger a hot add of the kernel monitoring device with respect to the first VM to enable communications between the kernel monitoring device and the first VM; after the hot add of the kernel monitoring device with respect to the first VM, receive, from the first VM, information associated with a kernel of the first VM;
In this instance examiner notes the teaching of prior art reference ZHOU.
With regards to applicant’s claim limitation of, in response to the detecting, check whether a connection exists between the kernel monitoring device and another VM (see ZHOU par.17-19 determining a target interface related to the virtual target device from a plurality of application program interfaces developed for the virtual machine monitor, and sending the hot plug request to the virtual machine monitor by calling the target interface. In a possible implementation manner, determining, by the virtual machine monitor, operation resource information corresponding to the hot plug request includes: establishing communication connection with the virtual target equipment, and determining a resource characteristic structure supported by the virtual target equipment by utilizing the communication connection;);
after the hot add of the kernel monitoring device with respect to the first VM, receive, from the first VM, information associated with a kernel of the first VM (ZHOU par.131: “After the hot plug thread is awakened, the driver corresponding to the preset hot plug device may be utilized to obtain the operation resource information from the operation queue (virtual queue). Then, if the request is for the hot plug of the virtual central processing unit, executing the specific hot plug logic of the virtual central processing unit by utilizing the hot plug thread in the Guest OS according to the acquired operation resource information; if the request is for the hot plug of the virtual device, the hot plug thread in the Guest OS can be utilized to execute the specific hot plug logic of the virtual device according to the acquired operation resource information”.);
Therefore It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Ndu teaching “"to access the OS invariant information in the physical memory, the monitor does not send requests to the OS to access the physical memory, but rather is able to communicate over an interconnect of the computer system with the physical memory. The ability to access OS invariant information in the physical memory independently of the OS allows for more secure monitoring of the OS invariant information.", (see Ndu par.0017) with ZHOU teaching because ZHOU teaching of “a device hot plug apparatus, including: the determining module is used for responding to the receiving of a hot plug request aiming at virtual target equipment in a virtual machine by a virtual machine monitor, and determining operation resource information corresponding to the hot plug request by using the virtual machine monitor; the operation resource information comprises resource information required to be used when the virtual target equipment is subjected to hot plug;”, (see ZHOU par.32-33). The motivation would have been to hot plugging a device without restarting.
Ndu in view of ZHOU do not explicitly teach based on detecting that a connection exists between the kernel monitoring device and the second VM, send a hot remove request from the kernel monitoring device to hot remove the kernel monitoring device from the second VM; based on receiving, at the kernel monitoring device, a confirmation that the kernel monitoring device has been hot removed from the second VM, trigger a hot add of the kernel monitoring device with respect to the first VM to enable communications between the kernel monitoring device and the first VM;
In this instance examiner notes reference the teaching of prior art reference Wu.
With regards to applicant’s claim limitation of, based on detecting that a connection exists between the kernel monitoring device and the second VM, send a hot remove request from the kernel monitoring device to hot remove the kernel monitoring device from the second VM (see Wu par.92 the virtual machine management informs the target number of the VCPUs to be unplugged corresponding to the hot-unplugging request to the virtual machine through the communication connection between the virtual machine management and the virtual machine, so that the virtual machine logs out and deletes the VCPUs to be unplugged according to the target number, and sends a hot-unplugging result indicating that the hot-unplugging is successful to the virtual machine manager.);
based on receiving, at the kernel monitoring device, a confirmation that the kernel monitoring device has been hot removed from the second VM, trigger a hot add of the kernel monitoring device with respect to the first VM to enable communications between the kernel monitoring device and the first VM (see Wu par.100: “according to the communication connection, sending the hot-plug result of the VCPU to be plugged obtained after deletion to the virtual machine manager. And finally, the virtual machine can send the hot plug result to the virtual machine manager according to the communication connection between the virtual machine manager and the virtual machine manager. The user can know whether the VCPU to be unplugged is successfully unplugged according to the prompt message displayed on the physical host computer…” par.124-126: “according to the hot plug request generated by the virtual machine manager, determining the target number of the VCPUs to be plugged corresponding to the hot plug request, so that the VCPUs to be plugged are hot-plugged in the virtual machine by the virtual machine according to the target number... receiving a hot plug result of the VCPU to be plugged, which is sent by the virtual machine, according to the communication connection between the virtual machine and the virtual machine manager.”);
Therefore It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Ndu in view of ZHOU teaching describe above with Wu teaching because Wu teaching of “the virtual machine manager may also determine validity of the hot-plug request and only respond to the valid hot-plug request.”, (see Wu par.137).
Regarding claim 2 Ndu in view of ZHOU, and Wu disclose the kernel monitoring device of claim 1, Ndu further teaches wherein the device processor is to obtain metadata relating to the information associated with the kernel of the first VM, the metadata comprising a memory map of the first VM, the memory map referring to a storage location of a memory containing the information associated with the kernel of the first VM to be monitored. (See Ndu par.0045: “The monitor 120 uses virtual addresses contained in the monitoring metadata 118 to look up physical addresses in the page table 122 (which maps the virtual addresses to the physical address). The virtual addresses included in the monitoring metadata 118 can include virtual addresses of OS invariant information to be monitored. The physical addresses returned by the page table 122 in response to the virtual addresses presented by the monitor 120 to the page table 122 are addresses of memory locations that contain the OS invariant information 124.”).
Regarding claim 3 Ndu in view of ZHOU, and Wu disclose the kernel monitoring device of claim 2, Ndu further teaches wherein the device processor is to (see Ndu par.0022: “monitors may be executed in a privileged execution mode of a processor, such as a system management mode (SMM), an Advanced Reduced Instruction Set Computing (RISC) Machine (ARM) EL3 privilege mode (which is a privilege level reserved for low-level firmware in security code, for example), and so forth.”):
receive the metadata from an agent in the first VM over a communication channel between the kernel monitoring device and the first VM (see Ndu par.0053-0054: “the agent 116 gathers (at 202) information related to OS monitoring. The agent 116 sends (at 204) the gathered information to the monitor 120. The gathered information that is sent includes the monitoring metadata 118 of FIG. 1, for example. Sending the gathered information to the monitor 120 can include writing the gathered information to the nonvolatile memory 126 of FIG. 1, for example, or any other type of transmission of information between the agent 116 and the monitor 120.”); and
use the metadata to monitor the information associated with the kernel. (See Ndu par.0092-0093: “the monitor 120 can monitor LKMs (also referred to as drivers). The monitor 120 can obtain a virtual address of an LKM from the monitoring metadata 118, and look up a corresponding physical address where the LKM is stored in the memory 112 from the page table 122. The monitor 120 can calculate a baseline value (e.g., a hash value) based on the content of the LKM retrieved from the memory 112 at the physical address (such as during early boot of the OS to be monitored), and subsequently, the monitor 120 can re-calculate a value based on the content of the LKM retrieved from the memory 112 at the physical address, and compare the re-calculated value to the baseline value to verify the integrity of the LKM.”).
Regarding claim 7 Ndu in view of ZHOU, and Wu disclose The kernel monitoring device of claim 1, Ndu further teaches wherein the device processor is to:
determine whether the measuring of the received information by the kernel
monitoring device is a first measurement of the first VM (see Ndu par.0086: “the monitor 120 can compute a baseline value based on the content of the given kernel part at a time when the kernel part is known to not be compromised,(first measurement) such as during an early boot process (such as during initial loading of the OS in the computer system 100). As an example, the monitor 120 can compute a hash of the content of the given kernel part, to produce a baseline hash value.”); and
based on a determination that the measuring of the received information by
the kernel monitoring device is the first measurement of the first VM (see Ndu par.0086: “the monitor 120 can compute a hash of the content of the given kernel part, to produce a baseline hash value.”), store measurement information produced by the measuring as a reference measurement in the kernel monitoring device. (See Ndu par.0088: “At a later time (after the OS has executed for some amount of time), the monitor can re-compute another value (e.g., another hash value) based on the content of the kernel part. The re-computed value can be compared by the monitor 120 to the baseline value.”). Examiner interpret that the compute baseline (first measurement) in the VM is store as reference measurement in the kernel monitoring device.
Regarding claim 14 Ndu in view of ZHOU, and Wu The kernel monitoring device of claim 1, Ndu further teaches wherein the device processor is to receive, from the first VM, a reference measurement of kernel information of the kernel of the first VM, wherein the measuring of the received information comprises generating a measurement of the kernel information of the kernel of the first VM, and wherein the determining of the integrity of the kernel of the first VM is based on a comparison of the generated measurement and the reference measurement. (see Ndu par.0086: "the monitor 120 can compute a baseline value based on the content of the given kernel part at a time when the kernel part is known to not be compromised,(first measurement) such as during an early boot process (such as during initial loading of the OS in the computer system 100). As an example, the monitor 120 can compute a hash of the content of the given kernel part, to produce a baseline hash value. The monitor 120 can compute a hash of the content of the given kernel part,
to produce a baseline hash value.", par.0088: "At a later time (after the OS has executed for some amount of time), the monitor can re-compute another value (e.g., another hash value) based on the content of the kernel part. The re-computed value can be compared by the monitor 120 to the baseline value." Examiner interpret that the compute baseline (reference measurement) in the VM is store as reference measurement in the kernel monitoring device.).
Regarding claim 16 Ndu in view of ZHOU, and Wu disclose The kernel monitoring device of claim 14 , Ndu further discloses wherein the kernel information comprises program code of the kernel. (See Ndu par.0013: “The invariant information can include program code (machine-readable instructions), which can include any or some combination of the following: a critical part of the kernel (a part of the kernel considered to be “critical” can be pre-specified), a static part of the kernel (a part of the kernel that is to remain unchanged during execution or should change in a predictable manner), a loadable kernel module (LKM), also referred to as a “driver” of the OS; an executable page of the OS (where the executable page is outside a region of the OS that includes LKMs or drivers).”).
Regarding claim 17 Ndu teaches an A non-transitory machine-readable storage medium comprising instructions that upon execution cause a kernel monitoring device to (see Ndu par.0020: “the monitor is also able to verify the integrity of a hypervisor that is part of the OS,”, par.0030: “the interconnect endpoint device 108 can include a management controller such as a baseband management controller (BMC).”, par.0084: “The monitor 120 can monitor an integrity of a critical or static part of an OS kernel.”, par.0137: “a non-transitory machine-readable or computer-readable storage medium 400 storing machine-readable instructions that upon execution cause a system to perform various tasks.”):
detect that kernel monitoring of a first virtual machine (VM) of a plurality of VMs is to be performed by the kernel monitoring device (see Ndu par.0035: “electronic components can communicate over the communication interconnect 106 according to a Peripheral Component Interconnect Express (PCIe) protocol, which is a high-speed serial computer expansion bus standard.”, par.0039: “The processor 102 executes an OS 111. In some examples where virtualized environments are used, the OS 111 can include a hypervisor 114.”, furthermore: “the monitor 120 runs on a processor (108) that is separate from the processor 102 (first VM) or 104 (second VM) running the OS being monitored, the monitor 120 does not have to suspend the monitored OS. Not suspending the OS can reduce overhead associated with OS integrity monitoring.” par.0045: "The monitor 120 uses virtual addresses contained in the monitoring metadata 118 to look up physical addresses in the page table 122 (which maps the virtual addresses to the physical address). The virtual addresses included in the monitoring metadata 118 can include virtual addresses of OS invariant information to be monitored.”);and
measure the received information to determine an integrity of the kernel of the first VM. (See Ndu par.0055-0057: “The monitor 120 accesses (at 206) the page table 122 using the gathered information to obtain physical addresses for OS invariant information to be monitored. For example, the gathered information can include virtual addresses of the OS invariant information. The virtual addresses of the OS invariant information can be provided to the page table 122, and the monitor retrieves, based on the access of the page table 122, respective physical addresses of memory locations in the memory 112 where the OS invariant information 124 is stored. The monitor 120 monitors (at 208) the OS invariant information (retrieved from the memory locations of the physical addresses obtained by the monitor 120 by accessing the page table 122) and/or other data structures. The monitor 120 determines (at 210), based on the monitored OS invariant information and/or other data structures, whether a security issue is present in the computer system 100.”, Examiner interpret that memory access allocated in the OS variant is being measured to determine if there has been changes in the access page table of the memory locations of the OS. The invariant information include machine-readable instructions that are part of the kernel. Any change or deviation of the invariant information can indicate malware).
Ndu do not explicitly teach in response to the detecting, check whether a connection exists between the kernel monitoring device and another VM of the plurality of VMs; based on detecting that a connection exists between the kernel monitoring device and a second VM of the plurality of VMs, send a hot remove request from the kernel monitoring device to hot remove the kernel monitoring device from the second VM; based on receiving, at the kernel monitoring device, a confirmation that the kernel monitoring device has been hot removed from the second VM, trigger a hot add of the kernel monitoring device with respect to the first VM to enable communications between the kernel monitoring device and the first VM; after the hot add of the kernel monitoring device with respect to the first
VM, receive, from the first VM, information associated with a kernel of the
first VM;
In this instance examiner notes the teaching of prior art reference ZHOU.
With regards to applicant’s claim limitation of, in response to the detecting, check whether a connection exists between the kernel monitoring device and another VM of the plurality of VMs; (see ZHOU par.17-19 determining a target interface related to the virtual target device from a plurality of application program interfaces developed for the virtual machine monitor, and sending the hot plug request to the virtual machine monitor by calling the target interface. In a possible implementation manner, determining, by the virtual machine monitor, operation resource information corresponding to the hot plug request includes: establishing communication connection with the virtual target equipment, and determining a resource characteristic structure supported by the virtual target equipment by utilizing the communication connection;);
after the hot add of the kernel monitoring device with respect to the first
VM, receive, from the first VM, information associated with a kernel of the
first VM (ZHOU par.131: “After the hot plug thread is awakened, the driver corresponding to the preset hot plug device may be utilized to obtain the operation resource information from the operation queue (virtual queue). Then, if the request is for the hot plug of the virtual central processing unit, executing the specific hot plug logic of the virtual central processing unit by utilizing the hot plug thread in the Guest OS according to the acquired operation resource information; if the request is for the hot plug of the virtual device, the hot plug thread in the Guest OS can be utilized to execute the specific hot plug logic of the virtual device according to the acquired operation resource information”.);
Therefore It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Ndu teaching “"to access the OS invariant information in the physical memory, the monitor does not send requests to the OS to access the physical memory, but rather is able to communicate over an interconnect of the computer system with the physical memory. The ability to access OS invariant information in the physical memory independently of the OS allows for more secure monitoring of the OS invariant information.", (see Ndu par.0017) with ZHOU teaching because ZHOU teaching of “a device hot plug apparatus, including: the determining module is used for responding to the receiving of a hot plug request aiming at virtual target equipment in a virtual machine by a virtual machine monitor, and determining operation resource information corresponding to the hot plug request by using the virtual machine monitor; the operation resource information comprises resource information required to be used when the virtual target equipment is subjected to hot plug;”, (see ZHOU par.32-33). The motivation would have been to hot plugging a device without restarting.
Ndu in view of ZHOU do not explicitly teach based on detecting that a connection exists between the kernel monitoring device and a second VM of the plurality of VMs, send a hot remove request from the kernel monitoring device to hot remove the kernel monitoring device from the second VM; based on receiving, at the kernel monitoring device, a confirmation that the kernel monitoring device has been hot removed from the second VM, trigger a hot add of the kernel monitoring device with respect to the first VM to enable communications between the kernel monitoring device and the first VM;
In this instance examiner notes reference the teaching of prior art reference Wu.
With regards to applicant’s claim limitation of, based on detecting that a connection exists between the kernel monitoring device and a second VM of the plurality of VMs, send a hot remove request from the kernel monitoring device to hot remove the kernel monitoring device from the second VM(see Wu par.92 the virtual machine management informs the target number of the VCPUs to be unplugged corresponding to the hot-unplugging request to the virtual machine through the communication connection between the virtual machine management and the virtual machine, so that the virtual machine logs out and deletes the VCPUs to be unplugged according to the target number, and sends a hot-unplugging result indicating that the hot-unplugging is successful to the virtual machine manager.);
based on receiving, at the kernel monitoring device, a confirmation that the kernel monitoring device has been hot removed from the second VM, trigger a hot add of the kernel monitoring device with respect to the first VM to enable communications between the kernel monitoring device and the first VM(see Wu par.100: “according to the communication connection, sending the hot-plug result of the VCPU to be plugged obtained after deletion to the virtual machine manager. And finally, the virtual machine can send the hot plug result to the virtual machine manager according to the communication connection between the virtual machine manager and the virtual machine manager. The user can know whether the VCPU to be unplugged is successfully unplugged according to the prompt message displayed on the physical host computer…” par.124-126: “according to the hot plug request generated by the virtual machine manager, determining the target number of the VCPUs to be plugged corresponding to the hot plug request, so that the VCPUs to be plugged are hot-plugged in the virtual machine by the virtual machine according to the target number... receiving a hot plug result of the VCPU to be plugged, which is sent by the virtual machine, according to the communication connection between the virtual machine and the virtual machine manager.”);
Therefore It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Ndu in view of ZHOU teaching describe above with Wu teaching because Wu teaching of “the virtual machine manager may also determine validity of the hot-plug request and only respond to the valid hot-plug request.”, (see Wu par.137).
Regarding claim 18 Ndu in view of ZHOU, and Wu teach the non-transitory machine-readable storage medium of claim 17, Ndu further teaches wherein the instructions upon execution cause the kernel monitoring device to:
receive, from the first VM, a reference measurement of kernel information of the kernel of the first VM,
wherein the measuring of the received information comprises generating a
measurement of the kernel information of the kernel of the first VM, and
wherein the determining of the integrity of the kernel of the first VM is based on a comparison of the generated measurement and the reference measurement. (See Ndu par.0086: "the monitor 120 can compute a baseline value based on the content of the given kernel part at a time when the kernel part is known to not be compromised,(first measurement) such as during an early boot process (such as during initial loading of the OS in the computer system 100). As an example, the monitor 120 can compute a hash of the content of the given kernel part, to produce a baseline hash value. The monitor 120 can compute a hash of the content of the given kernel part, to produce a baseline hash value.", par.0088: "At a later time (after the OS has executed for some amount of time), the monitor can re-compute another value (e.g., another hash value) based on the content of the kernel part. The re-computed value can be compared by the monitor 120 to the baseline value." Examiner interpret that the compute baseline (reference measurement) in the VM is store as reference measurement in the kernel monitoring device.).
Claims 4 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Ndu in view of ZHOU, and Wu as applied to claim 1, in further view of Kaplan et al. (US-10423437-B2 hereafter Kaplan).
Regarding claim 4 Ndu in view of ZHOU, and Wu disclose the kernel monitoring device of claim 1, Ndu in view of ZHOU, and Wu do not explicitly teach however Kaplan teaches wherein the hot remove request is sent from the kernel monitoring device to a VM manager or a hypervisor. (see Kaplan Col.8 lines 45-49: “the VF hot-plugging module 208 may send a request to the virtualization manager 115 so that the VFs 215 are released by the vNICs, such as vNIC 235, assigned to the VMs, such as VM 230.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, and Wu teaching of claim 1, with Kaplan teaching because Kaplan teaching of, “The disclosure provides techniques for hot-plugging of virtual functions in a virtual environment. In a virtualized environment, a virtual machine (VM) may comprise one or more "virtual devices," each of which may be associated with a physical device ( e.g., a network interface device, an I/O device such as a CD-ROM drive, a disk array, etc.) of a host machine. A virtualization management system, or "virtualization manager," can manage the allocation of the host resources to the VMs, monitor the status of the VMs, as well as the progress of commands and processes being executed by the VMs, and generally manage operations in the system.”, (see Kaplan Col.1 lines 51-62). The reason to combine would have been to send the hot remove request to the correct VM based on the collected information.
Regarding claim 6 Ndu in view of ZHOU, and Wu disclose the kernel monitoring device of claim 1, Ndu in view of ZHOU, and Wu do not explicitly teach however Kaplan teaches wherein the hot add of the kernel monitoring device by a hypervisor establishes a pass-through connection of the kernel monitoring device to the first VM, and wherein the pass-through connection enables a direct connection of the kernel monitoring device and the first VM without passing through the hypervisor. (See Kaplan Col.5 lines 27-32: “Hypervisor 140 may include a SR-IOV component interface 149 that provides SR-IOV specification support. Virtual networking with an SR-IOV-enabled NIC may be referred to as supporting a pass-through mode for assigning I/O devices, such as SR-IOV NIC 150-A, to VMs 130A-130N.”, lines 48-58: “the number of VFs (e.g., VFs 158) that may be supported by a given device (e.g., device 150A) may be limited by the underlying hardware of the device. In an illustrative example, a single Ethernet port may be mapped to multiple VFs that can be shared by one or more of the VMs 130A-130N. An I/O device, such as a virtual NIC device (vNIC) 135, associated with one of the VMs 130A-130N may be provided via a VF, thus bypassing the virtual networking on the host in order to reduce the latency between the VMs 130A-130N and the underlying SR-IOV NIC (e.g., device 150A).”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, and Wu teaching of claim 1, with Kaplan teaching “SR-IOV-enabled NIC may be referred to as supporting a pass-through mode for assigning I/O devices to VMs. In some implementations, a virtual device, such as a virtual NIC (vNIC), associated with a virtual machine can be connected directly ( e.g., as opposed to being connect via the virtualization layer of the host machine) to a virtual function using the SR-IOV. This may reduce data transfer latency between the VM and a physical device due to various issues, such as a virtualization layer associated with a host machine or lower CPU utilization devoted to data packet transfers”, (see Kaplan Col.2, lines 26-36).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ndu in view of ZHOU, and Wu as applied to claim 1, in further view of Schilling et al. (US-20170149807-A1 hereafter Schilling).
Regarding claim 5 Ndu in view of ZHOU, and Wu disclose The kernel monitoring device of claim 1, Ndu further teaches wherein the device processor is to (See Ndu par.0015: “an OS is also considered to include a hypervisor (also referred to as a “virtual machine monitor (VMM)”) in examples where a virtualized environment is provided in a computer system. A hypervisor includes machine-readable instructions that are able to run virtual machines (VMs).”, par.0015: “The hypervisor can manage sharing of the physical resources (including processors, storage devices, network interface controllers, graphics controllers, etc.) among multiple VMs.”):
Ndu in view of ZHOU, and Wu do not explicitly teach detect that kernel monitoring of the first VM is to be performed based on selecting, using a selection criterion, the first VM from among the plurality of VMs to monitor; determine whether the first VM is currently running, wherein the checking of whether the connection exists between the kernel monitoring device and another VM is based on a determination that the first VM is currently running.
In this instant Examiner notes the teaching of prior art reference Schilling.
With regards to applicant’s claim limitation element of, detect that kernel monitoring of the first VM is to be performed based on selecting, using a selection criterion, the first VM from among the plurality of VMs to monitor (See Schilling par.0021: “The detection system may periodically collect information (e.g., metadata or any other appropriate data) from one or more guest virtual machines to determine whether any malicious activity is present. The detection system employs a hypervisor for a guest virtual machine to communicate the instructions for collecting metadata from the guest virtual machine and to forward the collected metadata to a virtual vault machine within a secure region of the virtual network for processing.); and
determine whether the first VM is currently running .(see Schilling par.0050: “A target profile may comprise a repository of measurements which may be used to determine a current state of a guest virtual machine 104. The current state (e.g. healthy or compromised) of a guest virtual machine 104 may be used to in the determination of whether a particular guest virtual machine 104 is trusted or untrusted.”),
wherein the checking of whether the connection exists between the kernel
monitoring device and another VM is based on a determination that the first VM is currently running, (See Schilling par.0050: “Trusted measurement machine 108 is configured to process the virtual machine operating characteristics metadata and to create a target profile for each guest virtual machines 104 and their respective virtual machine operating characteristics. A target profile may comprise a repository of measurements which may be used to determine a current state of a guest virtual machine 104. The current state (e.g. healthy or compromised) of a guest virtual machine 104 may be used to in the determination of whether a particular guest virtual machine 104 is trusted or untrusted.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, and Wu teaching of claim 1, with Schilling teaching because Schilling teaching of, “Trusted measurement machine 108 to perform a comparative analysis on virtual machine operating characteristics metadata to determine the health or state of a guest virtual machine 104. In one embodiment, analysis tool 132 may forward the virtual machine operating characteristics metadata to trusted measurement machine 108 for a comparative analysis when analysis tool 132 classifies virtual machine operating characteristics metadata as unknown or is unable to determine the health of a guest virtual machine 104.”, (see Schilling par.0097).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ndu in view of ZHOU, and Wu as applied to claim 7, in further view of Moffie et al. (US-8719936-B2 hereafter Moffie), in further view of Xu et al. (US-8832682-B2 hereafter Xu).
Regarding claim 8 Ndu in view of ZHOU, and Wu disclose the kernel monitoring device of claim 7, Ndu in view of ZHOU, and Wu appear to be silence however Moffie teaches wherein the device processor is to:
check running state information of the first VM, the running state information including time information indicating a time length of execution of the first VM (see Moffie Col.7 lines 12-34: “the VIDS 202 has access to the following types of raw run time information which are used to generate events: VM architectural state information such as the VCPU 116 architectural state (for example its registers) and virtual devices 124 architectural state such as the virtual disk 122 and memory 120. Virtualization layer state, i.e., the VMM state, including, for example, the number of VMs running, state of each VM, etc. Another class of information available in the VMM includes the execution state of the VM. In some VMMs, this execution state indicates whether the code running in the VM is executed directly on the hardware or if it is being emulated. System state that can include time of day timers, CPU usage, and other runtime metrics. The VIDS 202 tracks the execution of the VM and can monitor events corresponding to changes to the architectural, virtualization layer and system software state. These changes include for example: a write to a virtual register, or an access (read to, write from, control of) virtual device (VM architectural state changes), operations such as VM create or destruct (in the context of software virtualization layer) and system software state changes such as the current time.”),
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, and Wu teaching of claim 1, with Moffie teaching “Advantageously, embodiments of the present invention provide a VMM-based Intrusion Detection System (VIDS) that utilizes the virtual machine monitor (VMM) layer in a virtualized system to extract VMM-level semantics or information during runtime. By extracting VMM-level information that, in one embodiment, is optimized to a particular VMM and architecture, the IDS is easier to deploy and manage as a part of a VMM.”, (see Moffie Col.2 lines: 52-59).
Ndu in view of ZHOU, and Wu, and Moffie appear to be silence however Xu teaches
wherein the determination that the measuring of the first VM by the kernel monitoring device is the first measurement of the first VM is based on the running state information including the time information. (See Xu Col.2 lines 62-67 and Col.3 lines 1-20: “VM 200-1 executes a workload (the workload comprises a set of instructions to carry out one or more processes by VM 200-1), the virtualization layer, for example, VMM 300-1( monitoring device), captures information related to non-deterministic events, and logs the information in event log 280 (for example, and without limitation, event log 280 may be disk storage). In accordance with one or more embodiments of the present invention, event log 280 includes an indication of a known state from which logging of non-deterministic events began. The known state may be, for example and without limitation, an initial power up state of the system or a system “checkpoint.” As is well known, a checkpoint is a stored data structure that captures a system state, including register values, memory content, etc. In accordance with one or more embodiments, beginning, for example, from the known state of VM 200-1, the virtualization layer, for example, VMM 300-1, detects each non-deterministic event, and stores an indication of each such non-deterministic event (including data relevant to the event, for example and without limitation, a packet of data) in event log 280 together with a current execution point of VM 200-1. An execution point provides information that serves as a measure of progress of VM 200-1 from the known state of the VM 200-1, and can be used (as described below) as a “timing” mechanism to record precisely when the non-deterministic event occurred in the execution sequence of VM 200-1.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, Wu, and Moffie teaching described above, with Xu teaching “a method for logging events to capture an execution trace of a workload on a virtual machine (for example, VM 200-1) in accordance with one or more embodiments of the present invention VMM 300-1 records an initial state of VM 200-1 to event log 280. Recording the initial state may entail, for example, recording a reference to a stored checkpoint or other known state ( e.g., the power up state) or it may entail capturing and storing a new checkpoint. At decision step 504, throughout an execution sequence, VMM 300-1 monitors for the occurrence of a non-deterministic even ”, (see Xu Col.6 lines: 48-59).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Ndu in view of ZHOU, Wu, Moffie, and Xu as applied to claim 8, in further view of Guo et al. (CN-108763935-A hereafter Guo).
Regarding claim 9 Ndu in view of ZHOU, Wu, Moffie, and Xu disclose the kernel monitoring device of claim 8, Ndu in view of ZHOU, Wu, Moffie, and Xu do not explicitly teach however Guo teaches wherein the device processor is to:
determine that the kernel of the first VM has been tampered with responsive to detecting based on the time information that the time length of execution of the first VM has been reduced. (See Guo par.39: “the security monitoring module 1 may Including: detection sub-module 11 and control sub-module 12”, par.44-45: “the detection sub-module 11 is to obtain the state data of the kernel object in the virtual machine system, check its integrity and return the check result to the control sub-module. The control sub-module 12 may be the control center of the monitoring system. The control sub-module 12 receives the inspection result of the virtual machine system running status (information that the time length of execution) by the detection sub-module, the detection result may include: when the status data matches the baseline snapshot data of the kernel object backed up in advance, it is determined that the kernel object in the virtual machine system is normal; when the status data matches the baseline snapshot data of the kernel object backed up in advance When the data does not match,(has been reduced) it is determined that the kernel object in the virtual machine system is abnormal. Wherein, the abnormality of the kernel object may include: the kernel object has been tampered with and/or a malicious module is hidden in the virtual machine system.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, Wu, Moffie, and Xu teaching of claim 8, with Guo teaching “a security monitoring module; the security monitoring module may include: a detection submodule and a control submodule; the detection submodule is used to obtain the state of the kernel object in the virtual machine system data; compare the status data with the baseline snapshot data of the kernel object backed up in advance; detect the integrity of the kernel object according to the comparison result.”, (see Guo par.29 ).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Ndu in view of ZHOU, and Wu as applied to claim 1, in further view of Tsirkin et al. (US-20120102252-A1 hereafter Tsirkin).
Regarding claim 10 Ndu in view of ZHOU, and Wu disclose The kernel monitoring device of claim 1, Ndu in view of ZHOU, and Wu appear to be silence however Tsirkin teaches wherein the device processor is to:
after the measuring of the received information, send a hot remove request
from the kernel monitoring device to a VM manager or a hypervisor to hot remove of the kernel monitoring device from the first VM. (See Tsirkin par.0023: “In response, the hotplug manager 128 sends a hotplug request to the guest 140, indicating that the device 150 is to be removed from the control of the guest 140 (block 320). Before the hotplug manager 128 receives an acknowledgment from the guest 140, the hotplug manager 128 also monitors the commands issued from the guest 140 that are to be executed on the CPU 170 (block 330).”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu in view of ZHOU, and Wu teaching of claim 1, with Tsirkin teaching “The hotplug manager 128 then sends an indication to the source of the hotplug command (e.g., by sending or displaying a message on the control console of a system administrator), indicating that the device 150 can be (if it is a physical device), or has been (if it is an emulated device), safely removed from the guest 140 (block 370). As a result, a device can be hotplug removed from the control of a guest without delay even when the guest needs to be rebooted during the hotplugging process.”, (see Tsirkin par.0023).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Ndu et al. (US-20210026948-A1 hereafter Ndu), in view of Smith et al. (US-9426147-B2 hereafter Smith).
Regarding claim 19 Ndu teaches A computing system comprising (see Ndu par.0016: “In accordance with some implementations of the present disclosure, a monitor is executed in a computer system, where the monitor is separate from an OS of the computer system.”):
a processing resource to execute a virtual machine (VM) comprising an operating system (OS) kernel (see Ndu par.0015: “In the present disclosure, an OS is also considered to include a hypervisor (also referred to as a "virtual machine monitor (VMM)") in examples where a virtualized environment is provided in a computer system. A hypervisor includes machine-readable instructions that are able to run virtual machines (VMs).”);
a VM agent in the VM to (see Ndu par.0040: “The OS 111 can also include an agent 116 that collects various information that can be used for monitoring OS invariant information, according to some implementations of the present disclosure.”):
Ndu appear to be silence however Smith teaches
receive an indication of a Communication hot add of a kernel monitoring device with respect to the VM (see Smith Col.24 lines 45-47: “If a device is hot-plugged into the platform, the VM 810 or 820 that received the device assignment is identified in the audit event record.”), and based on the indication, of the hot add of the kernel monitoring device with respect to the VM, send information of the OS kernel to the kernel monitoring device for monitoring of an integrity of the OS kernel, the information of the OS kernel sent to the kernel monitoring device comprising a reference measurement of kernel information of the OS kernel, wherein a determination of the integrity of the OS kernel is based on the reference measurement. (See Smith Col.24 lines 31-42: “when a new device is hot-plugged into the platform, VMM 830 assigns the device to a VM 810 or 820. To perform auditing within chipset/secure partition 120 in a virtualized environment such as that described in FIG. 8, VMM 830 manages an audit mask profile for each of VMs 810 and 820. When a device is assigned to either VM 810 or 820, the respective audit mask profile for the VM is associated with the chipset/secure partition 120. Each time the VM audit mask profile associated with chipset/secure partition 120 changes, VMM 830 generates an audit event record. In this way, the VM 810 or 820 that initiates an auditable event is represented in the audit event records. For example, the VM 810 or 820 that issues storage I/O commands to the device is identified in the audit event records.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu teaching “to access
the OS invariant information in the physical memory, the monitor does not send requests to the OS to access the physical memory, but rather is able to communicate over an interconnect of the computer system with the physical memory. The ability to access OS invariant information in the physical memory independently of the OS allows for more secure monitoring of the OS invariant information.”, (see Ndu par.0017), with Smith teaching “VMM 830 ensures that transient VM environments do not result in unauthorized assignment of drives. In one embodiment, VMM 830 generates a GUID (globally unique ID) for each VM 810 and 820.”, (Smith Col.24 lines65-67-Col.24 line 1)
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Ndu in view of Smith as applied to claim 19, in further view of Apfelbaum et al. (US-20230101885-A1 hereafter Apfelbaum).
Regarding claim 20 Ndu in view of Smith teach the computing system of claim 19, Ndu in view of Smith do not explicitly teach however Apfelbaum teaches wherein the indication is:
received by the VM agent from a hot plug agent in the VM that detects hot plug events associated with the VM, or received by the VM agent from the OS kernel. (See Apfelbaum par.0025: “Once the hypervisor 125 determines that the registers of the virtual machine 132a are ready for the hot-plugging of devices, the hypervisor 125 may transmit an indication to the VM agent 164 that the virtual machine 132a is ready for the hot-plugging of devices. Upon receipt of the indication, the VM agent 164 may issue a device hot-plug operation to the cloud agent 162 that causes the cloud agent 162 to attach the device associated with the device attachment request to the virtual machine 132a via a hot-plug operation. Because the VM agent has issued the device hot-plug operation to the cloud agent 162 after receiving the indication that the virtual machine 132a is ready for the hot-plugging of devices, the probability that the device may be successfully hot-plugged to virtual machine 132a is increased.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ndu view of Smith teaching of claim 19 with Apfelbaum teaching “The VM agent 164 may receive device attachment requests for VM based containers from the cloud agent 162. The VM agent 164 may further monitor the VM based container to determine when the VM based container is ready for the hot-plugging of device(s) associated with the device attachment requests. The VM agent 164 may issue device attachment operations upon determining that the VM cased container is ready for the hot-plugging of the devices.”, (see Apfelbaum par.0021). The reason to combine would have been to have dedicated agent to handle the hot adding communication.
Allowable Subject Matter
Claims 11-13, and 15 are objected to as being dependent upon a rejected base claim, but would be allowable if written in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Kaplan (US-10423437-B2) and Tsirkin (US-20120102252-A1), Kaplan discloses a VF hot plugging module that can create virtualized instances and is able to hot add and hot remove VF instances. The VF hot-plugging module 208 may send a request to the virtualization manager 115 so that the VFs 215 are released by the vNICs, such as vNIC 235, assigned to the VMs, such as VM 230. Also, the VF management component 170 may hot-plug an available VF 355 into a device 350 associated with the second hypervisor 390 using, for example, the management computing system 200 and Tsirkin discloses a hotplug manager that can hotplug remove a device such as any device. However none the prior arts of record individually or in reasonable combination discloses:
a virtualized instance of the kernel monitoring device, wherein the hot remove comprises hot removing the VF from the second VM, and the hot add comprises hot adding the VF with respect to the first VM, and the measuring of the received information to determine the integrity of the kernel of the first VM is performed by the VF. A monitoring device compose of a virtualized instance of the kernel, where the virtualized monitoring device first will need to be detach using hot remove from an the second VM in order to be added to the first VM using hot plug, and determining the first VM integrity, for claim 11, and
a plurality of virtualized instances of the kernel monitoring device wherein the hot remove comprises hot removing a first VF of the plurality of VFs from the second VM, and the hot add comprises hot adding the first VF to the first VM. A monitoring device compose of a plurality virtualized instance of the kernel, where a single virtualized monitoring device of the plurality will need to be detach using hot remove from the second VM in order to be added to the first VM using hot plug, for claim 12 (claims 13 and 15 depend on claim 12).
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
Montague et al. (US-8387046-B1) a system is provided comprising a hypervisor coupled to one or more protected virtual machines (VMs), each protected VM comprising a guest operating system (OS). A security VM is coupled to the protected VMs via a private communication channel. Within this channel, a split kernel loader provides an end-to-end communication between a front-end and a back-end. The front-end consists of a Para virtualized security device driver, or "symbiont", for each said guest OS. The back-end consists of the security VM.
ZOU et al. (CN-108469984-A) The system has a security virtual machine (1) provided with a monitoring frame (11), where the monitoring frame is provided with an extracting module, an learning module and a monitoring module. The secure virtual machine and a target virtual machine (2) are connected by a virtual machine management layer (3). The secure virtual machine process an operating portion in a target virtual machine by a virtual machine management layer using WMI technology. The target virtual machine receives a state value and a change events of a target object of interest in the security virtual machine. The virtual machine manager is connected to the extracting module. A control stream data is processed according to an appointed detection process.
Zhang et al. (CN-111638936-B) the security independent device measures the security of the host system and virtualization software to ensure the trustworthiness of the host system/virtualization software; Perform security measurement on the content of the core file of the virtual machine to generate a measurement value; the virtual machine core files that need to be measured includes, but is not limited to: virtual machine startup configuration files, system kernel files, user information files, and other virtual machine user-defined files.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 9:30 - 5:00Pm.
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, Eleni A Shiferaw can be reached at (571) 272-3867. 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.
/DUILIO MUNGUIA/Examiner, Art Unit 2497
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights