DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed 03/31/2026.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 15 recites the limitation "execute the instructions using the data" in line 4. There is insufficient antecedent basis for this limitation in the claim. Neither instructions nor data have been mentioned prior in the claim. Examiner will interpret this limitation to mean “execute instructions using data”.
Claims 16-20 depend, directly or indirectly, from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for at least the same reasons.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4, 8-9, 11, 15-16, and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Poothia (US 2019/0278714).
With regard to claim 1, Poothia teaches:
A processor comprising: circuitry configured to: “Upon execution of the computer-readable instructions by a processor, the computer-readable instructions may cause a node to perform the operations” [Poothia ¶ 53].
execute a guest virtual machine (VM) “FIG. 6 shows a flow diagram of an example process 600 for executing a virtual machine based on a virtual non-uniform memory access architecture” [Poothia ¶ 49]. “In addition, the first user VM 202 can include a first guest operating system (OS) 210 that can run a first set of software applications 212 (Appl, App2, App3, and App4)” [Poothia ¶ 32]. “Referring again to the first user VM 202 and the second user VM 204, the virtual processors and the virtual memory within these virtual machines also can be structured in a non-uniform memory access architecture. For example, the hypervisor 206 can present the virtual machines a virtual NUMA (or vNUMA) architecture” [Poothia ¶ 37].
that includes a plurality of virtual components corresponding to respective hardware components of a host system; “In one or more embodiments, the vNUMA structure can mirror the pNUMA structure provided by the physical hardware resources 208. For example, the number of vCPU cores and vRAM banks in a vNUMA node can be equal to the pCPU cores and pRAM banks in the pNUMA” [Poothia ¶ 43]. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs (virtual components) to the pCPUs and the pRAMs (hardware components) in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46]. “The one or more virtual machines utilize the hardware resources of the underlying one or more host machines” [Poothia ¶ 2]. “One or more of the first node 105, the second node 110, and the third node 115 may also be organized in a variety of network topologies, and may be termed as a "host" or "host machine."” [Poothia ¶ 24].
access data describing communication relationships between pairs of endpoint-device hardware components of the host system, “The virtual machine can obtain the latency times associated with the physical processing nodes from a hypervisor. The virtual machine can be configured to update the latency times associated with the virtual processing nodes if changes in the mapping information or changes in the latency times associated with the physical processing nodes is detected” [Poothia ¶ 17]. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies (data describing communication relationships) between any CPU core and a RAM bank” [Poothia ¶ 37]. “The method further includes obtaining, by a computing system, a first set of latency values associated with the non-uniform memory access times between the plurality of physical processors and the plurality of physical memories” [Poothia ¶ 3]. “The hardware resources 208 can represent a multi-socket processing board where each socket corresponds to a pNUMA node, and each pNUMA node includes multiple processing cores. For example, the first pNUMA node 234 can have processor socket including two CPU cores pCPU1 240 and pCPU2 242, and two memory banks pRAM1 244 and pRAM2 246, while the second pNUMA node 236 can have a processor socket including four CPU cores pCPU3 248, pCPU4 250, pCPU5 252, and pCPU6 254 and two memory banks pRAM3 256 and pRAM4 258” [Poothia ¶ 35].
the data being based on a physical hardware topology of the host system rather than a guest VM topology of the guest VM; “One technical problem encountered in such computing systems is the lack of latency information associated with virtual processing cores and virtual memory banks available at the virtual machine. The NUMA architecture at the physical level can have non-uniform latencies or access times between the physical processing cores and the physical memory banks. A hypervisor can map virtual processing cores and virtual memory banks to physical processing cores and physical memory banks … The virtual machine is configured to obtain latency information associated with the physical processing nodes, and generate latency information associated with the virtual processing nodes based on the latency information associated with the physical processing nodes and mapping information between the virtual processing nodes and the physical processing nodes” [Poothia ¶ 15-16]. “It should be understood that the latencies within the physical latency table 300 are based on the particular NUMA architecture, and can depend, in part, upon interconnect speeds between the CPU cores and the RAM banks in the hardware resources 208” [Poothia ¶ 38].
and cause execution of an operation involving a selected pair of the virtual components, “The first and the second user VMs 202 and 204, by maintaining the first and second virtual latency tables 400 and 500 can leverage the vNUMA architecture and the associated non-uniform latency values to assign the first and second set of applications 212 and 216 to the appropriate virtual CPUs and virtual RAM banks. For example, if App1 were a critical application or an application requiring a high quality of service, the first user VM 202 may assign the App1 (or the associated program threads) to the virtual CPU and virtual RAM bank pair having the lowest latency value” [Poothia ¶ 47]. “Also, although not shown, one or more of the first node 105, the second node 110, and the third node 115 may include one or more processing units configured to execute instructions … The term "execution" is, for example, the process of running an application or the carrying out of the operation called for by an instruction” [Poothia ¶ 25].
wherein the selected pair is: selected based at least in part on the data; “The hypervisor 206 can advantageously use the non-uniform latencies between various pCPU cores and pRAM banks in the hardware resources 208 in processor and memory virtualization. In particular, the hypervisor may map vCPUs to pCPUs and vRAMs to pRAMs based on the known latencies between the pCPUs and the pRAMs. For example, the hypervisor 206 may run critical applications on pCPUs and pRAMs pairs having the lowest latencies” [Poothia ¶ 36].
and identified as corresponding to a pair of the endpoint-device hardware components by data“In one or more embodiments, the mapping data structure can include a table that lists identifiers (such as a name or a unique ID) associated with the vNUMA nodes, and the identifiers of the pNUMA nodes to which each of the vNUMA nodes are mapped. For example, referring to FIG. 2, the first vNUMA node 270 is mapped to the first pNUMA node 234. The table can include the identity of the first vNUMA node 270 in association with an identity of the first pNUMA node 234. The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46].
Regarding claim 2, Poothia teaches:
The processor as recited in claim 1, as referenced above.
wherein the circuitry is further configured to generate a request for the data indicative of communication relationships, “For example, the operating systems running on the first and second user VMs 202 and 204 can use advanced configuration and power interface (ACPI) to request the physical latency information from the hypervisor 206 or the hardware resources 208” [Poothia ¶ 42].
and to receive a response comprising the data from a topology manager of the host system. “In particular, the hypervisor 206 can provide the first and second user VMs 202 and 204 with the latency values included in the physical latency table 300” [Poothia ¶ 42].
Regarding claim 4, Poothia teaches:
The processor as recited in claim 1, as referenced above.
wherein the data indicative of communication relationships includes latency information for a subset of the hardware components of the host system, “The virtual machine can obtain the latency times associated with the physical processing nodes from a hypervisor. The virtual machine can be configured to update the latency times associated with the virtual processing nodes if changes in the mapping information or changes in the latency times associated with the physical processing nodes is detected” [Poothia ¶ 17]. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
the latency information being associated with physical identifiers of the hardware components of the subset. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46, fig. 3 Examiner notes the physical identifiers at the heads of each row and column in figure 3, such as pCPU1 and pRAM1].
With regard to claim 8, Poothia teaches:
A method comprising: executing, by circuitry of a processor, “Upon execution of the computer-readable instructions by a processor, the computer-readable instructions may cause a node to perform the operations” [Poothia ¶ 53].
execute a guest virtual machine (VM) “FIG. 6 shows a flow diagram of an example process 600 for executing a virtual machine based on a virtual non-uniform memory access architecture” [Poothia ¶ 49]. “In addition, the first user VM 202 can include a first guest operating system (OS) 210 that can run a first set of software applications 212 (Appl, App2, App3, and App4)” [Poothia ¶ 32]. “Referring again to the first user VM 202 and the second user VM 204, the virtual processors and the virtual memory within these virtual machines also can be structured in a non-uniform memory access architecture. For example, the hypervisor 206 can present the virtual machines a virtual NUMA (or vNUMA) architecture” [Poothia ¶ 37].
that includes a plurality of virtual components corresponding to respective hardware components of a host system; “In one or more embodiments, the vNUMA structure can mirror the pNUMA structure provided by the physical hardware resources 208. For example, the number of vCPU cores and vRAM banks in a vNUMA node can be equal to the pCPU cores and pRAM banks in the pNUMA” [Poothia ¶ 43]. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs (virtual components) to the pCPUs and the pRAMs (hardware components) in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46]. “The one or more virtual machines utilize the hardware resources of the underlying one or more host machines” [Poothia ¶ 2]. “One or more of the first node 105, the second node 110, and the third node 115 may also be organized in a variety of network topologies, and may be termed as a "host" or "host machine."” [Poothia ¶ 24].
accessing, by the processor, data describing communication relationships between pairs of endpoint-device hardware components of the host system, “The virtual machine can obtain the latency times associated with the physical processing nodes from a hypervisor. The virtual machine can be configured to update the latency times associated with the virtual processing nodes if changes in the mapping information or changes in the latency times associated with the physical processing nodes is detected” [Poothia ¶ 17]. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies (data describing communication relationships) between any CPU core and a RAM bank” [Poothia ¶ 37]. “The method further includes obtaining, by a computing system, a first set of latency values associated with the non-uniform memory access times between the plurality of physical processors and the plurality of physical memories” [Poothia ¶ 3]. “The hardware resources 208 can represent a multi-socket processing board where each socket corresponds to a pNUMA node, and each pNUMA node includes multiple processing cores. For example, the first pNUMA node 234 can have processor socket including two CPU cores pCPU1 240 and pCPU2 242, and two memory banks pRAM1 244 and pRAM2 246, while the second pNUMA node 236 can have a processor socket including four CPU cores pCPU3 248, pCPU4 250, pCPU5 252, and pCPU6 254 and two memory banks pRAM3 256 and pRAM4 258” [Poothia ¶ 35].
the data being based on a physical hardware topology of the host system rather than a guest VM topology of the guest VM; “One technical problem encountered in such computing systems is the lack of latency information associated with virtual processing cores and virtual memory banks available at the virtual machine. The NUMA architecture at the physical level can have non-uniform latencies or access times between the physical processing cores and the physical memory banks. A hypervisor can map virtual processing cores and virtual memory banks to physical processing cores and physical memory banks … The virtual machine is configured to obtain latency information associated with the physical processing nodes, and generate latency information associated with the virtual processing nodes based on the latency information associated with the physical processing nodes and mapping information between the virtual processing nodes and the physical processing nodes” [Poothia ¶ 15-16]. “It should be understood that the latencies within the physical latency table 300 are based on the particular NUMA architecture, and can depend, in part, upon interconnect speeds between the CPU cores and the RAM banks in the hardware resources 208” [Poothia ¶ 38].
and causing, by the processor, execution of an operation involving a selected pair of the virtual components, “The first and the second user VMs 202 and 204, by maintaining the first and second virtual latency tables 400 and 500 can leverage the vNUMA architecture and the associated non-uniform latency values to assign the first and second set of applications 212 and 216 to the appropriate virtual CPUs and virtual RAM banks. For example, if App1 were a critical application or an application requiring a high quality of service, the first user VM 202 may assign the App1 (or the associated program threads) to the virtual CPU and virtual RAM bank pair having the lowest latency value” [Poothia ¶ 47]. “Also, although not shown, one or more of the first node 105, the second node 110, and the third node 115 may include one or more processing units configured to execute instructions … The term "execution" is, for example, the process of running an application or the carrying out of the operation called for by an instruction” [Poothia ¶ 25].
wherein the selected pair is: selected based at least in part on the data; “The hypervisor 206 can advantageously use the non-uniform latencies between various pCPU cores and pRAM banks in the hardware resources 208 in processor and memory virtualization. In particular, the hypervisor may map vCPUs to pCPUs and vRAMs to pRAMs based on the known latencies between the pCPUs and the pRAMs. For example, the hypervisor 206 may run critical applications on pCPUs and pRAMs pairs having the lowest latencies” [Poothia ¶ 36].
and identified as corresponding to a pair of the endpoint-device hardware components by datacomponents of the host system. “In one or more embodiments, the mapping data structure can include a table that lists identifiers (such as a name or a unique ID) associated with the vNUMA nodes, and the identifiers of the pNUMA nodes to which each of the vNUMA nodes are mapped. For example, referring to FIG. 2, the first vNUMA node 270 is mapped to the first pNUMA node 234. The table can include the identity of the first vNUMA node 270 in association with an identity of the first pNUMA node 234. The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46].
Regarding claim 9, Poothia teaches:
The method as recited in claim 8, as referenced above.
further comprising: generating, by the processor, a request for the data indicative of communication relationships; “For example, the operating systems running on the first and second user VMs 202 and 204 can use advanced configuration and power interface (ACPI) to request the physical latency information from the hypervisor 206 or the hardware resources 208” [Poothia ¶ 42].
and receiving, by the processor, a response comprising the data from a topology manager of the host system. “In particular, the hypervisor 206 can provide the first and second user VMs 202 and 204 with the latency values included in the physical latency table 300” [Poothia ¶ 42].
Regarding claim 11, Poothia teaches:
The method as recited in claim 8, as referenced above.
wherein the data indicative of communication relationships includes latency information for a subset of the hardware components of the host system, “The virtual machine can obtain the latency times associated with the physical processing nodes from a hypervisor. The virtual machine can be configured to update the latency times associated with the virtual processing nodes if changes in the mapping information or changes in the latency times associated with the physical processing nodes is detected” [Poothia ¶ 17]. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
the latency information being associated with physical identifiers of the hardware components of the subset. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46, fig. 3 Examiner notes the physical identifiers at the heads of each row and column in figure 3, such as pCPU1 and pRAM1].
With regard to claim 15, Poothia teaches:
A computing system comprising: a plurality of hardware components; “In particular, the hardware resources 208 can be structured as a physical NUMA (pNUMA). The pNUMA can include several NUMA nodes, such as first pNUMA node 234 and a second pNUMA node 236 interconnected by an interconnect 238. The hardware resources 208 can represent a multi-socket processing board where each socket corresponds to a pNUMA node, and each pNUMA node includes multiple processing cores. For example, the first pNUMA node 234 can have processor socket including two CPU cores pCPU1 240 and pCPU2 242, and two memory banks pRAM1 244 and pRAM2 246, while the second pNUMA node 236 can have a processor socket including four CPU cores pCPU3 248, pCPU4 250, pCPU5 252, and pCPU6 254 and two memory banks pRAM3 256 and pRAM4 258” [Poothia ¶ 35].
and a processor comprising circuitry configured to: execute the instructions using the data; “Upon execution of the computer-readable instructions by a processor, the computer-readable instructions may cause a node to perform the operations” [Poothia ¶ 53].
execute a guest virtual machine (VM) “FIG. 6 shows a flow diagram of an example process 600 for executing a virtual machine based on a virtual non-uniform memory access architecture” [Poothia ¶ 49]. “In addition, the first user VM 202 can include a first guest operating system (OS) 210 that can run a first set of software applications 212 (Appl, App2, App3, and App4)” [Poothia ¶ 32]. “Referring again to the first user VM 202 and the second user VM 204, the virtual processors and the virtual memory within these virtual machines also can be structured in a non-uniform memory access architecture. For example, the hypervisor 206 can present the virtual machines a virtual NUMA (or vNUMA) architecture” [Poothia ¶ 37].
that includes a plurality of virtual components corresponding to respective hardware components of a host system; “In one or more embodiments, the vNUMA structure can mirror the pNUMA structure provided by the physical hardware resources 208. For example, the number of vCPU cores and vRAM banks in a vNUMA node can be equal to the pCPU cores and pRAM banks in the pNUMA” [Poothia ¶ 43]. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs (virtual components) to the pCPUs and the pRAMs (hardware components) in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46]. “The one or more virtual machines utilize the hardware resources of the underlying one or more host machines” [Poothia ¶ 2]. “One or more of the first node 105, the second node 110, and the third node 115 may also be organized in a variety of network topologies, and may be termed as a "host" or "host machine."” [Poothia ¶ 24].
access data describing communication relationships between pairs of endpoint-device hardware components of the host system, “The virtual machine can obtain the latency times associated with the physical processing nodes from a hypervisor. The virtual machine can be configured to update the latency times associated with the virtual processing nodes if changes in the mapping information or changes in the latency times associated with the physical processing nodes is detected” [Poothia ¶ 17]. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies (data describing communication relationships) between any CPU core and a RAM bank” [Poothia ¶ 37]. “The method further includes obtaining, by a computing system, a first set of latency values associated with the non-uniform memory access times between the plurality of physical processors and the plurality of physical memories” [Poothia ¶ 3]. “The hardware resources 208 can represent a multi-socket processing board where each socket corresponds to a pNUMA node, and each pNUMA node includes multiple processing cores. For example, the first pNUMA node 234 can have processor socket including two CPU cores pCPU1 240 and pCPU2 242, and two memory banks pRAM1 244 and pRAM2 246, while the second pNUMA node 236 can have a processor socket including four CPU cores pCPU3 248, pCPU4 250, pCPU5 252, and pCPU6 254 and two memory banks pRAM3 256 and pRAM4 258” [Poothia ¶ 35].
the data being based on a physical hardware topology of the host system rather than a guest VM topology of the guest VM; “One technical problem encountered in such computing systems is the lack of latency information associated with virtual processing cores and virtual memory banks available at the virtual machine. The NUMA architecture at the physical level can have non-uniform latencies or access times between the physical processing cores and the physical memory banks. A hypervisor can map virtual processing cores and virtual memory banks to physical processing cores and physical memory banks … The virtual machine is configured to obtain latency information associated with the physical processing nodes, and generate latency information associated with the virtual processing nodes based on the latency information associated with the physical processing nodes and mapping information between the virtual processing nodes and the physical processing nodes” [Poothia ¶ 15-16]. “It should be understood that the latencies within the physical latency table 300 are based on the particular NUMA architecture, and can depend, in part, upon interconnect speeds between the CPU cores and the RAM banks in the hardware resources 208” [Poothia ¶ 38].
and cause execution of an operation involving a selected pair of the virtual components, “The first and the second user VMs 202 and 204, by maintaining the first and second virtual latency tables 400 and 500 can leverage the vNUMA architecture and the associated non-uniform latency values to assign the first and second set of applications 212 and 216 to the appropriate virtual CPUs and virtual RAM banks. For example, if App1 were a critical application or an application requiring a high quality of service, the first user VM 202 may assign the App1 (or the associated program threads) to the virtual CPU and virtual RAM bank pair having the lowest latency value” [Poothia ¶ 47]. “Also, although not shown, one or more of the first node 105, the second node 110, and the third node 115 may include one or more processing units configured to execute instructions … The term "execution" is, for example, the process of running an application or the carrying out of the operation called for by an instruction” [Poothia ¶ 25].
wherein the selected pair is: selected based at least in part on the data; “The hypervisor 206 can advantageously use the non-uniform latencies between various pCPU cores and pRAM banks in the hardware resources 208 in processor and memory virtualization. In particular, the hypervisor may map vCPUs to pCPUs and vRAMs to pRAMs based on the known latencies between the pCPUs and the pRAMs. For example, the hypervisor 206 may run critical applications on pCPUs and pRAMs pairs having the lowest latencies” [Poothia ¶ 36].
and identified as corresponding to a pair of the endpoint-device hardware components by datacomponents of the host system. “In one or more embodiments, the mapping data structure can include a table that lists identifiers (such as a name or a unique ID) associated with the vNUMA nodes, and the identifiers of the pNUMA nodes to which each of the vNUMA nodes are mapped. For example, referring to FIG. 2, the first vNUMA node 270 is mapped to the first pNUMA node 234. The table can include the identity of the first vNUMA node 270 in association with an identity of the first pNUMA node 234. The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46].
Regarding claim 16, Poothia teaches the computing system as recited in claim 15, as referenced above. Poothia further teaches:
wherein causing execution of the operation comprises scheduling the operation for execution by a given pair of the virtual components, “The respective guest OSs, given the vNUMA architecture, can then schedule and map their respective applications based on the latencies between the various vCPUs and vRAMs provided by the hypervisor 206” [Poothia ¶ 37].
and wherein the processor is further configured to schedule a given operation that transfers data between the given pair of virtual components “The virtual machine can provide the generated latency information to the operating system. In tum, the operating system can assign processes and threads to virtual processing cores and virtual memory banks based, in part, on the latency information” [Poothia ¶ 16]. “As another example, the first user VM 202 may assign program threads associated with a database application analyzing data sets, which may include repeated memory access, may be assigned, to a virtual CPU and virtual RAM bank pair having a low latency value” [Poothia ¶ 47].
responsive to determining, based on the data indicative of communication relationships, that a latency associated with the given pair of virtual components is less than any latency associated with each other pair of virtual components. “For example, if App1 were a critical application or an application requiring a high quality of service, the first user VM 202 may assign the App1 (or the associated program threads) to the virtual CPU and virtual RAM bank pair having the lowest latency value” [Poothia ¶ 47].
Regarding claim 18, Poothia teaches:
The computing system as recited in claim 15, as referenced above.
wherein the data indicative of communication relationships includes latency information for a subset of the hardware components, “The virtual machine can obtain the latency times associated with the physical processing nodes from a hypervisor. The virtual machine can be configured to update the latency times associated with the virtual processing nodes if changes in the mapping information or changes in the latency times associated with the physical processing nodes is detected” [Poothia ¶ 17]. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
the latency information being associated with physical identifiers of the hardware components of the subset. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46, fig. 3 Examiner notes the physical identifiers at the heads of each row and column in figure 3, such as pCPU1 and pRAM1].
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 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Poothia (US 2019/0278714) in view of Cui (US 2021/0014706 A1).
Regarding claim 3, Poothia teaches the processor as recited in claim 1, as referenced above.
Poothia fails to teach wherein the data indicative of communication relationships identifies at least one pair of hardware components of the host system that are physically incapable of directly communicating with one another.
However, Cui teaches wherein the data indicative of communication relationships identifies at least one pair of hardware components of the host system that are physically incapable of directly communicating with one another. “In some embodiments, the connection monitor component 610 monitors both the wire and wireless connections with the macro cell 302 (FIG. 3). In some embodiments, the connection monitor component 610 detects a failure in a backhaul communication link between a first node device and a second node device if there is no data traffic or using various connection monitoring techniques to detect if the connection to macro cell 302 has failed. For example, in some embodiments, when the random-access node cannot communicate with core network because there is no downlink or uplink traffic (e.g., no downlink message/ data received or unable to transmit uplink message/data), the monitor component 610 may consider that as the self-backhaul link is down.” [Cui ¶ 67].
Cui is considered to be analogous to the claimed invention because it is in the same field of task scheduling taking into account communication capabilities. Poothia teaches the collection of data indicative of communication relationships between pairs of hardware components. Cui teaches monitoring communication between pairs of hardware components to determine when they are incapable of communicating with each other. The data indicative of communication relationships of Poothia can be modified to include this determination of Cui. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Cui and include that the data indicative of communication relationships identifies at least one pair of hardware components of the host system that are physically incapable of directly communicating with one another. Doing so would allow for the system to identify connection failures for remedy. Implementing such an architecture would bring performance advancements. “The relay device transmits signal to the macro cell, wherein the signal comprises a message indicating connection failure and request for new resources to establish a new connection” [Cui ¶ 34].
Regarding claim 10, Poothia teaches the method as recited in claim 8 as referenced above. Poothia fails to teach wherein the data indicative of communication relationships identifies at least one pair of hardware components of the host system that are physically incapable of directly communicating with one another.
However, Cui teaches wherein the data indicative of communication relationships identifies at least one pair of hardware components of the host system that are physically incapable of directly communicating with one another. “In some embodiments, the connection monitor component 610 monitors both the wire and wireless connections with the macro cell 302 (FIG. 3). In some embodiments, the connection monitor component 610 detects a failure in a backhaul communication link between a first node device and a second node device if there is no data traffic or using various connection monitoring techniques to detect if the connection to macro cell 302 has failed. For example, in some embodiments, when the random-access node cannot communicate with core network because there is no downlink or uplink traffic (e.g., no downlink message/ data received or unable to transmit uplink message/data), the monitor component 610 may consider that as the self-backhaul link is down.” [Cui ¶ 67].
Poothia teaches the collection of data indicative of communication relationships between pairs of hardware components. Cui teaches monitoring communication between pairs of hardware components to determine when they are incapable of communicating with each other. The data indicative of communication relationships of Poothia can be modified to include this determination of Cui. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Cui and include that the data indicative of communication relationships identifies at least one pair of hardware components of the host system that are physically incapable of directly communicating with one another. Doing so would allow for the system to identify connection failures for remedy. Implementing such an architecture would bring performance advancements. “The relay device transmits signal to the macro cell, wherein the signal comprises a message indicating connection failure and request for new resources to establish a new connection” [Cui ¶ 34].
Regarding claim 17, Poothia teaches the computing system as recited in claim 15, as referenced above. Poothia fails to teach wherein the data indicative of communication relationships identifies at least one pair of the hardware components that are physically incapable of directly communicating with one another.
However, Cui teaches wherein the data indicative of communication relationships identifies at least one pair of the hardware components that are physically incapable of directly communicating with one another. “In some embodiments, the connection monitor component 610 monitors both the wire and wireless connections with the macro cell 302 (FIG. 3). In some embodiments, the connection monitor component 610 detects a failure in a backhaul communication link between a first node device and a second node device if there is no data traffic or using various connection monitoring techniques to detect if the connection to macro cell 302 has failed. For example, in some embodiments, when the random-access node cannot communicate with core network because there is no downlink or uplink traffic (e.g., no downlink message/ data received or unable to transmit uplink message/data), the monitor component 610 may consider that as the self-backhaul link is down.” [Cui ¶ 67].
Poothia teaches the collection of data indicative of communication relationships between pairs of hardware components. Cui teaches monitoring communication between pairs of hardware components to determine when they are incapable of communicating with each other. The data indicative of communication relationships of Poothia can be modified to include this determination of Cui. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Cui and include that the data indicative of communication relationships identifies at least one pair of the hardware components that are physically incapable of directly communicating with one another. Doing so would allow for the system to identify connection failures for remedy. Implementing such an architecture would bring performance advancements. “The relay device transmits signal to the macro cell, wherein the signal comprises a message indicating connection failure and request for new resources to establish a new connection” [Cui ¶ 34].
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Poothia (US 2019/0278714) in view of Boyle (US 2016/0098372 A1).
Regarding claim 5, Poothia teaches the processor as recited in claim 1, as referenced above. Poothia fails to teach wherein the guest virtual machine represents the virtual components under a single virtual root complex, and the host system comprises a plurality of physical root complexes.
However, Boyle teaches:
wherein the guest virtual machine represents the virtual components under a single virtual root complex, and the host system comprises a plurality of physical root complexes. “With the advent of single root I/O virtualization (SR-IOV) PCIe devices, an application has appeared which allows multiple root complexes as described to access the virtual functions of single root I/O virtualization devices from separate domains” [Boyle ¶ 26].
Boyle is considered to be analogous to the claimed invention because it is in the same field of virtualization. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Boyle and include that the guest virtual machine represents the virtual components under a single virtual root complex, and the host system comprises a plurality of physical root complexes. Doing so would allow for the use of a high-speed interconnect. “The memory access to BARs and the programming of the "PCIe bus" side or DMA addresses are transparently handled and the operational benefit of speed through the PCIe fabric has been gained” [Boyle ¶ 46].
Regarding claim 12, Poothia teaches the method as recited in claim 8, as referenced above. Poothia fails to teach wherein the guest virtual machine represents the virtual components under a single virtual root complex, and the host system comprises a plurality of physical root complexes.
However, Boyle teaches:
wherein the guest virtual machine represents the virtual components under a single virtual root complex, and the host system comprises a plurality of physical root complexes. “With the advent of single root I/O virtualization (SR-IOV) PCIe devices, an application has appeared which allows multiple root complexes as described to access the virtual functions of single root I/O virtualization devices from separate domains” [Boyle ¶ 26].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Boyle and include that the guest virtual machine represents the virtual components under a single virtual root complex, and the host system comprises a plurality of physical root complexes. Doing so would allow for the use of a high-speed interconnect. “The memory access to BARs and the programming of the "PCIe bus" side or DMA addresses are transparently handled and the operational benefit of speed through the PCIe fabric has been gained” [Boyle ¶ 46].
Claims 6-7, 13-14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Poothia (US 2019/0278714) in view of Liu (CN 112256395A) [Examiner notes that an English translation of Liu has been provided and all citations are made to this translation].
Regarding claim 6, Poothia teaches the processor as recited in claim 1, as referenced above. Poothia further teaches wherein the data indicative of communication relationships is received from a topology manager “In particular, the hypervisor 206 can provide the first and second user VMs 202 and 204 with the latency values included in the physical latency table 300” [Poothia ¶ 42].
Poothia fails to explicitly teach comprising a security processor of the host system.
However, Liu teaches comprising a security processor of the host system. “In step S18, the security processor establishes a mapping relationship corresponding to the security memory in the security page table. establishing the corresponding mapping relationship in the security page table, so that the security virtual machine accesses the security memory based on the security page table; realizing the access of the security virtual machine to the security memory” [Liu P 27, Lines 8-12].
Liu is considered to be analogous to the claimed invention because it is in the same field of task input/output management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Liu and include a security processor of the host system. This would improve the security of the virtual machine. “In order to improve the security of virtual machine data, security virtualization technology can protect the memory of the virtual machine security…” [Liu P 23, Lines 12 and 13].
Regarding claim 7, Poothia in view of Liu teaches the processor as recited in claim 6, as referenced above. Additionally, Poothia teaches:
wherein the circuitry is further configured to: collect, via the security processor, physical identifiers of components of the host system from a host processor not allocated to the guest VM; “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46]. “In one or more embodiments, the first and second user VMs 202 and 204 can receive an indication from the hypervisor 206 if there is any change in the mappings or any change in one or more latency values in the physical latency table 300. The indication may also include the updated mappings and the updated latency values” [Poothia ¶ 45]. “The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46].
determine, using the physical identifiers, data indicative of communication relationships among the hardware components based on physical placement of the hardware components within the host system; “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
and store the data indicative of the communication relationships. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
Poothia fails to teach via the security processor.
However, Liu teaches via the security processor “In step S18, the security processor establishes a mapping relationship corresponding to the security memory in the security page table. establishing the corresponding mapping relationship in the security page table, so that the security virtual machine accesses the security memory based on the security page table; realizing the access of the security virtual machine to the security memory” [Liu P 27, Lines 8-12].
Regarding claim 13, Poothia teaches the method as recited in claim 8 as referenced above. Poothia further teaches wherein the data indicative of communication relationships is received from a topology manager “In particular, the hypervisor 206 can provide the first and second user VMs 202 and 204 with the latency values included in the physical latency table 300” [Poothia ¶ 42].
Poothia fails to explicitly teach comprising a security processor of the host system.
However, Liu teaches comprising a security processor of the host system. “In step S18, the security processor establishes a mapping relationship corresponding to the security memory in the security page table. establishing the corresponding mapping relationship in the security page table, so that the security virtual machine accesses the security memory based on the security page table; realizing the access of the security virtual machine to the security memory” [Liu P 27, Lines 8-12].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Liu and include a security processor of the host system. This would improve the security of the virtual machine. “In order to improve the security of virtual machine data, security virtualization technology can protect the memory of the virtual machine security…” [Liu P 23, Lines 12 and 13].
Regarding claim 14, Poothia in view of Liu teaches the method as recited in claim 13, as referenced above. Additionally, Poothia teaches:
further comprising: collecting, via the security processor, physical identifiers of components of the host system from a host processor not allocated to the guest VM; “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46]. “In one or more embodiments, the first and second user VMs 202 and 204 can receive an indication from the hypervisor 206 if there is any change in the mappings or any change in one or more latency values in the physical latency table 300. The indication may also include the updated mappings and the updated latency values” [Poothia ¶ 45]. “The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46].
determining, by the security processor using the physical identifiers, the data indicative of communication relationships among the hardware components based on physical placement of the hardware components within the host system; “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
and storing the data indicative of the communication relationships. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
Poothia fails to teach via the security processor and by the security processor.
However, Liu teaches via the security processor and by the security processor “In step S18, the security processor establishes a mapping relationship corresponding to the security memory in the security page table. establishing the corresponding mapping relationship in the security page table, so that the security virtual machine accesses the security memory based on the security page table; realizing the access of the security virtual machine to the security memory” [Liu P 27, Lines 8-12].
Regarding claim 19, Poothia teaches the computing system as recited in claim 15, as referenced above. Poothia further teaches further comprising a topology manager configured to provide the data indicative of communication relationships, the topology manager “In particular, the hypervisor 206 can provide the first and second user VMs 202 and 204 with the latency values included in the physical latency table 300” [Poothia ¶ 42].
Poothia fails to explicitly teach comprising at least a security processor.
However, Liu teaches comprising at least a security processor. “In step S18, the security processor establishes a mapping relationship corresponding to the security memory in the security page table. establishing the corresponding mapping relationship in the security page table, so that the security virtual machine accesses the security memory based on the security page table; realizing the access of the security virtual machine to the security memory” [Liu P 27, Lines 8-12].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Poothia to incorporate the teachings of Liu and include a security processor. This would improve the security of the virtual machine. “In order to improve the security of virtual machine data, security virtualization technology can protect the memory of the virtual machine security…” [Liu P 23, Lines 12 and 13].
Regarding claim 20, Poothia in view of Liu teaches the computing system as recited in claim 19, as referenced above. Additionally, Poothia teaches:
wherein the processor is further configured to: cause the security processor to collect physical identifiers of the hardware components from a host processor not allocated to the guest VM; “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure. The hypervisor 206 can communicate the mapping data structure to the first and the second user VMs 202 and 204 so that the mapping information can be used to update the virtual latency tables” [Poothia ¶ 46]. “In one or more embodiments, the first and second user VMs 202 and 204 can receive an indication from the hypervisor 206 if there is any change in the mappings or any change in one or more latency values in the physical latency table 300. The indication may also include the updated mappings and the updated latency values” [Poothia ¶ 45]. “The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46].
cause the security processor to determine, using the physical identifiers, the data indicative of communication relationships among the hardware components based on physical placement of the hardware components within the computing system; “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
and cause storage of the data indicative of the communication relationships. “The hypervisor 206 can maintain a physical latency table (also referred to as a physical system locality information table (pSLIT)) that specifies the latencies between any CPU core and a RAM bank” [Poothia ¶ 37].
Poothia fails to teach the security processor.
However, Liu teaches the security processor “In step S18, the security processor establishes a mapping relationship corresponding to the security memory in the security page table. establishing the corresponding mapping relationship in the security page table, so that the security virtual machine accesses the security memory based on the security page table; realizing the access of the security virtual machine to the security memory” [Liu P 27, Lines 8-12].
Response to Arguments
Applicant's arguments filed 03/31/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
I. As amended, claim 1 recites (i) accessing data describing communication relationships between pairs of endpoint-device hardware components of the host system, where the data is based on a physical hardware topology of the host system rather than a guest VM topology of the guest VM, and (ii) causing execution of an operation involving a selected pair of virtual components, where the selected pair is selected based on that data and is identified, by data associating identifiers of the virtual components with identifiers of corresponding hardware components of the host system, as corresponding to a pair of the endpoint-device hardware components. Poothia does not disclose these features.
In the Office Action, Poothia is cited for virtualization of NUMA locality information for processor and memory resources, including mappings between vCPUs and pCPUs, mappings between vRAMs and pRAMs, and physical and virtual latency values for CPU-core-to-memory- bank relationships. (See, e.g., Poothia paras. 17, 37, 43, and 46-47). The cited portions of Poothia concern generation and use of a virtual NUMA latency model for processor-memory placement in a VM. (See, e.g., Poothia paras. 37, 42, and 46-47). Poothia does not disclose data describing communication relationships between pairs of endpoint-device hardware components, and does not disclose the use of such endpoint-device-pair data based on a physical hardware topology of the host system rather than a guest VM topology of the guest VM. The Office Action instead relies on Poothia's disclosures of latency values associated with physical processing nodes and a pSLIT specifying latencies between CPU cores and RAM banks. (See, e.g., Poothia paras. 17 and 37).
As described in the specification of the present application, a guest VM topology may misrepresent the actual host-side physical topology, for example, by using an emulated root complex that obscures actual paths and latencies between endpoint devices. The application describes embodiments in which distance or latency information for pairs of endpoint devices is based on the physical hardware topology rather than the guest VM topology and is used to select a pair for scheduling.
a) Examiner respectfully disagrees. As detailed in the rejection above, Poothia teaches accessing, by the processor, data describing communication relationships between pairs of endpoint-device hardware components of the host system, [Poothia ¶ 35-37] the data being based on a physical hardware topology of the host system rather than a guest VM topology of the guest VM; [Poothia ¶ 15-16, 38] and causing, by the processor, execution of an operation involving a selected pair of the virtual components, [Poothia ¶ 47]. wherein the selected pair is: selected based at least in part on the data; [Poothia ¶ 36]. and identified as corresponding to a pair of the endpoint-device hardware components by data [Poothia ¶ 38, 46].
The CPUs and RAMs of Poothia are endpoint-device hardware components, as they are included in NUMA nodes that each correspond to a processor socket. “The processors and the memories in the hardware resources 208 are structured in a form that supports nonuniform memory access (NUMA) architecture. In particular, the hardware resources 208 can be structured as a physical NUMA (pNUMA). The pNUMA can include several NUMA nodes, such as first pNUMA node 234 and a second pNUMA node 236 interconnected by an interconnect 238. The hardware resources 208 can represent a multi-socket processing board where each socket corresponds to a pNUMA node, and each pNUMA node includes multiple processing cores” [Poothia ¶ 35]. Further, the latency information of Poothia is considered data describing communication relationships between pairs of these endpoint-device hardware components. “The process 600 further includes generating latency values associated with the virtual processors and the virtual memories based on the mapping information and the physical latency values (606) … For example, the latency value for the vCPU1 218 to access the vRAM1 222 is based on the mapping of the vCPU1 218 and the vRAM1 222 to the pCPU1 240 and the pRAM1 244, respectively, and the latency value of 10 associated with the pCPU1 240 and the pRAM1 244 (in the physical latency table 300)” [Poothia ¶ 51]. The teachings of Poothia consider data comprising physical latency values between hardware components, these latencies are based on the physical hardware topology [Poothia ¶ 38].
Further, Poothia clearly states the need to draw from the data of the physical components in order to properly account for the hardware distances when scheduling virtual components: “One technical problem encountered in such computing systems is the lack of latency information associated with virtual processing cores and virtual memory banks available at the virtual machine. The NUMA architecture at the physical level can have non-uniform latencies or access times between the physical processing cores and the physical memory banks. A hypervisor can map virtual processing cores and virtual memory banks to physical processing cores and physical memory banks. Thus, there can be non-uniform latencies between virtual processing cores and virtual memory banks. Some virtual machines may not have the ability to provide latency information or may provide uniform latencies to the operating system. As a result, process or thread scheduling by the operating system on the virtual processing cores and the virtual memory banks may become inefficient or unpredictable, and may affect the performance of the computing system. The discussion below provides at least one technical solution to the technical problems mentioned above. For example, the computing system discussed below, the virtual processing cores also can be configured to have non-uniform access times to the virtual memory banks. That is, the virtual machine is configured to include a virtual NUMA architecture. The virtual machine is configured to obtain latency information associated with the physical processing nodes, and generate latency information associated with the virtual processing nodes based on the latency information associated with the physical processing nodes and mapping information between the virtual processing nodes and the physical processing nodes” [Poothia ¶ 15-16].
Further, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “endpoint-device-pair data”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The independent claims include pairs of endpoint device hardware components, not pairs of endpoint devices. The arguments have been considered but are not persuasive.
II. Poothia also does not disclose the amended claim features that the selected pair of virtual components is identified as corresponding to a pair of endpoint-device hardware components by data associating identifiers of the virtual components with identifiers of corresponding hardware components of the host system. Even if Poothia discloses mappings between virtual and physical CPU and memory resources, those mappings are used in Poothia's NUMA processor-memory context. (See, e.g., Poothia paras. 43 and 46). Poothia also discloses that such mappings may be used to update virtual latency tables and that applications or threads may be assigned to a virtual CPU / virtual RAM pair having a lower or lowest latency value. (See, e.g., Poothia paras. 45-47). However, Poothia does not disclose using those mappings to identify a selected virtual pair as corresponding to a pair of endpoint-device hardware components selected based on endpoint-pair communication-relationship data derived from host physical topology rather than guest topology.
Accordingly, Poothia does not disclose all features of claim 1 and therefore does not anticipate claim 1. Claims 8 and 15 are likewise not anticipated by Poothia.
a) Examiner respectfully disagrees. As detailed in the rejection above, the virtual CPUs and virtual RAM banks of Poothia do correspond to respective hardware components of the host system by data associating identifiers of the virtual components with identifiers of corresponding hardware components of the host system. “As discussed above, the hypervisor 206 can maintain the mappings of the vCPUs and the vRAMs to the pCPUs and the pRAMs in a mapping data structure” [Poothia ¶ 46]. They are also indeed associated by identifiers which are related to identifiers of the hardware components. “The table (or another table) can additionally include a list of identfiiers of vCPU cores and vRAM banks and the identifers of the mapped pCPU cores and pRAM banks. For example, the table can include identities of the vCPU1 218, the vRAM1 222, the vCPU2, and the vRAM2 224 and the associated pCPUs and pRAMs in the first pNUMA node 234” [Poothia ¶ 46]. It is unclear in what manner the context of Poothia is argued by Applicant to differ from the claimed invention.
Further, Poothia does disclose using these mappings in the selection of a pair of virtual components. “The hypervisor 206 can advantageously use the non-uniform latencies between various pCPU cores and pRAM banks in the hardware resources 208 in processor and memory virtualization. In particular, the hypervisor may map vCPUs to pCPUs and vRAMs to pRAMs based on the known latencies between the pCPUs and the pRAMs. For example, the hypervisor 206 may run critical applications on pCPUs and pRAMs pairs having the lowest latencies” [Poothia ¶ 36]. The latency data of the physical components is used in combination with the virtual component to physical component mappings in order to schedule tasks on the virtual components. The arguments have been considered but are not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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 on (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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/ Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights