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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1, 11, 16; 2, 3, 4, 5, 6, 13, 14, 15, 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asaro et al. U.S. Pub. No. 2020/0201758 in view of Rao et al. U.S. Pub. No. 2016/0328823, Koob et al. U.S. Pub. No. 2016/0246731 and Chinya et al. U.S. Pub. No. 2011/0072234.
Re: claims 1, 11 and 16 (which are rejected under the same rationale), Asaro teaches
1. (Currently Amended) (Previously Presented) A graphics processor comprising: a system interface including a device interface configurable for assignment to a guest software domain; (“Fig. 2 is a block diagram illustrating an embodiment of a host system 200 that depicts the host system 102 of Fig. 2 in greater detail… In various virtualization environments of GPU 210, a single-root input/output virtualization (SR-IOV) specification allow for a single Peripheral Component Interconnect Express (PCIe) device to appear as multiple separate PCIe devices. A physical PCIe device of the host system 200 (such as graphics processing unit 210, shared memory 206, or a central processing unit 108 of Fig. 1) having SR-IOV capabilities is configured to appear as multiple functions (virtual functions 212).”; Asaro, [0016], [0022])
Fig. 2 depicts the host system of Fig. 1 in more detail. Fig. 2 illustrates a system 200 that includes a GPU 210, where the GPU 210 includes a single-root input/output virtualization (SR-IOV) which allows for a single PCIe device (system interface includes a device interface) to appear as multiple separate PCIe devices.
(“In the example embodiment of Fig. 2, the SR-IOV specification enables the sharing of graphics processing unit 210 among the virtual machines 208. The graphics processing unit 210 is a PCIe device having physical function 211. The virtual functions 212 are derived from the physical function of the graphics processing unit 210, thereby mapping a single physical device (e.g., the graphics processing unit 210) to a plurality of virtual functions 212 that is shared with guest virtual machines 208. In some embodiments, the hypervisor 204 maps (e.g., assigns) the virtual functions 212 to the guest virtual machines 208.”; Asaro, [0023])
The graphics processing unit (GPU) 210 is a PCIe device (device interface configurable) having a physical function 211, where the virtual functions are derived from the physical function and the physical device (GPU 210) is mapped (for assignment) to a plurality of virtual functions 212 that are shared with guest virtual machines 208 (to the guest software domain).
... and access a location in the local memory device via the second physical address. (“The UTC 150 returns the SPA to the graphics engine 109. At a later instance, graphics engine 109 makes a memory request to framebuffer 122 using the SPA.”; Asaro, [0014])
The universal translation cache (UTC) returns the system physical address (SPA) (second physical address) to the graphics engine. Then, the graphics engine makes a memory request to the framebuffer (local memory device) using the SPA (access a location in the local memory device via the second physical address).
a local memory device; and a processing circuitry including a plurality of graphics engines, the processing circuitry coupled with the local memory device, the processing circuitry including memory arbiter circuitry, wherein the memory arbiter circuitry is configured, in response to a request from a graphics engine of the plurality of graphics engines to access memory via a virtual address, to: perform a first address translation for the virtual address, the first address translation to generate a first physical address; (“When graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122, a guest virtual memory identification (VMID), and the virtual function identification (VFID). The UTC 150 uses a GPUVM located in the UTC 150 to convert the VA to a guest physical address (GPA).”; Asaro, [0014], Fig. 1)
Fig. 1 illustrates GPU 106 and frame buffer 122 (local memory device). The GPU (processing circuitry) includes graphic engine 109 that is coupled with the frame buffer (local memory device). When the graphics engine intends to access framebuffer (in response to a request from a graphics engine to access memory), the graphics engine sends a translation request to the UTC with a virtual address (to access memory via a virtual address) of the corresponding memory in the framebuffer. The UTC uses a GPUVM located in the UTC to convert the virtual address (VA) to a guest physical address (GPA). The UTC is considered to include the processing circuitry including memory arbiter circuitry. The UTC performs the function of the memory arbiter circuitry. Asaro is silent regarding a processing circuitry including a plurality of graphics engines, however, Rao teaches this limitation.
(“… the GPU 108 includes a number of graphics engines (not shown), wherein the graphics engine is configured to perform specific graphics tasks, or to execute specific types of workloads.”; Rao, [0024], Fig. 1)
Fig. 1 illustrates a GPU 108 that includes a number of graphics engines. Rao is combined with Asaro such that the plural graphics engines of Rao are included in the GPU of Asaro. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of a processing circuitry including a plurality of graphics engines, in order to enable each graphic engine to perform specific graphics tasks or to execute specific types of workloads, as taught by Rao ([0024]).
Asaro teaches determine, based on a local memory bit within an entry of the first translation table, whether the virtual address is mapped to the local memory device or to memory external to the graphics processor; (“When the graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122.”; Asaro, [0014], Fig. 1)
When the graphics engine intends to access the framebuffer, it sends a translation request (determines) to the UTC with the virtual address of the memory location in the framebuffer (virtual address is mapped to the local memory device).
(“GPUVM 224 represents the guest VM layer that uses the guest virtual address (GVA) and the virtual machine identification (VMID) for translation to a guest physical address (GPA). GPUVM 224 performs page table walks individually with GPUVM page tables 241 located in the guest VM portion of frame buffer 222 and distinct from the host page tables 240, also located in frame buffer 222.”; Asaro, [0025])
The GPUVM represents the guest VM layer that uses the guest virtual address (GVA) for translation to a guest physical address (GPA). The GPUVM performs page table walks with GPUVM page tables (determine, based on... an entry of the first translation table) located in the guest VM portion of the frame buffer (virtual address is mapped to the local memory device). Asaro and Rao are silent regarding a local memory bit within an entry, however, Koob teaches this limitation.
(“Referring to the Fig. 1. enlarged view of a representative example translation entry, labeled “150-r,” the translation entries 150 can include a virtual address page number (VPN) field 1502, a physical address page number field 1504... and, in an aspect, a local memory flag field 1506. In an aspect, the local memory flag field 1506 can hold a “local flag”... having a value that may be switchable between a first value that indicates the physical address in the page field 1504 is a location in the local memory 104, and a second value that indicates the physical address is a location not in the local memory 104.”; Koob, [0025], Fig. 1)
Translation entries include a local memory flag field that holds a local flag (local memory bit within an entry). The local flag that is switchable between a first value that indicates whether the physical address is in local memory or whether the second value that indicates that the physical address is not on local memory. The local flag of an entry is used to determine whether the virtual address is mapped to the local memory device. Koob is combined with Asaro and Rao such that the local flag of Koob is included in the entry of Asaro.
Asaro teaches in response to determining, based on the local memory bit, that the virtual address is mapped to the local memory device, perform a second address translation on the first physical address via a second translation table stored in the local memory device, the second address translation to generate a second physical address, “When the graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122, a guest virtual memory identification (VMID), and the virtual function identification (VFID). The UTC 150 uses a GPUVM located in UTC 150 to convert the VA to a guest physical address (GPA)... The GIOMMU located in IOHUB 140 converts the GPA to the true system physical address (SPA).”; Asaro, [0014])
When the graphics engine intends to access framebuffer 122 (local memory device), a translation request is sent and the virtual address (VA) is converted to a guest physical address (GPA). Then the GPA is converted to the system physical address (SPA) (second address translation to generate a second physical address).
(“The GIOMMU located in the IOHUB 130 converts the GPA to the true system physical address (SPA)… the GPA to SPA translation may be controlled by, for example, hypervisor 116 or a host VM of the hypervisor… The GIOMMU will translate the GPAs into SPAs using page table based address translation.”; Asaro, [0014], Figs. 1-2)
The GIOMMU converts the graphics physical address (GPA) (first physical address) to system physical address (SPA) (second physical address) using page table based translation (perform a second address translation on the first physical address via a second translation table stored in the local memory device, the second address translation to generate a second physical address). Fig. 1 illustrates that the second translation table is stored in the memory of the GPU.
(“Frame buffer 22 includes host page tables 240, guest page tables 241 (GPUVM page tables 241)… guest page tables 241 and host page tables 240 represent the page tables for GPUVM 224 and GIOMMU, respectively… GPUVM 224 performs page table walks individually with GPUVM page tables 241 located in the guest VM portion of frame buffer 222 and distinct from the host page tables 240, also located in frame buffer 222.”; Asaro, [0019], [0025], Fig. 1)
Guest page tables (used by the GPUVM to perform GPA to GVA translation) and host page tables (used by the GIOMMU to perform GPA to SPA translation (second translation table)) are both stored in the frame buffer (second translation table stored in the local memory device). Asaro is silent regarding the second address translation being performed in response to determining... that the virtual address is mapped to the local memory device, however Koob teaches this limitation.
(“Referring to the Fig. 1. enlarged view of a representative example translation entry, labeled “150-r,” the translation entries 150 can include a virtual address page number (VPN) field 1502, a physical address page number field 1504... and, in an aspect, a local memory flag field 1506. In an aspect, the local memory flag field 1506 can hold a “local flag”... having a value that may be switchable between a first value that indicates the physical address in the page field 1504 is a location in the local memory 104, and a second value that indicates the physical address is location not in the local memory 104. For purposes of description, logical “0” will be assigned as the first value of the local memory flag and logical ”1” will be assigned as the second value of the local memory flag.”; Koob, [0025], Fig. 1)
The local flag of an entry is indicates whether the virtual address is mapped to the local memory device or to non-local memory.
(“If the translation lookaside unit 110 finds a matching translation entry 150, it generates a TLB hit event... Example operations will be first described assuming a matching translation entry is found... in the low power mode, operation of the switchable power/memory access mode processor 100 in response to a TLB hit event depends on the local memory flag in the matching translation entry 150. If the local memory flag indicates the physical page number in the page field 1504 being in the local memory 104, the operations can proceed as described for the normal power mode, namely, a physical address can be generated and the local memory 104 accessed. If however, the local memory flag identifies the physical page number in the page field 1504 being outside the local memory 104, the LP access exception logic 116 will output an active... low power access exception signal.”; Koob, [0038])
If a matching translation entry is found, a TLB hit event is generated. Operation of the switchable power/memory access mode processor, in response to a TLB hit event, depends on the local memory flag in the matching translation entry. If the local memory flag indicates the physical page number in the page field is located in the local memory (in response to determining... that the virtual address is mapped to the local memory device), a physical address is generated and the local memory is accessed (perform a second address translation on the first physical address via a second translation table). If the local memory flag indicates the physical page number in the page field is outside the local memory, the LP access exception logic outputs an active low power exception signal. Koob is combined with Asaro and Rao such that the local flag of Koob is included in the entry of Asaro and when the graphics engine intends to access the framebuffer of Asaro, it is based on the local flag of the entry of Koob. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of determining... that the virtual address is mapped to the local memory device, in order to provide rapid, low processing overhead switching between a local memory/low power mode that can confine access to local memory, and a normal power mode enabling full access to remote memory, as taught by Koob ([0007]).
Asaro and Rao are silent regarding in response to determining, based on the local memory bit, that the virtual address is mapped to the memory external to the graphics processor, requesting translation of the first physical address via an input/output memory management unit (IOMMU), wherein the memory external to the graphics processor is accessible via the system interface, however, Koob and Chinya teach
in response to determining, based on the local memory bit, that the virtual address is mapped to the memory external to the graphics processor, requesting translation of the first physical address via an input/output memory management unit (IOMMU), (“Each translation entry 150 can map a virtual page... to a physical page number. The physical page number may correspond to the local memory 104, the remote memory 106, or another non-local resource.”; Koob, [0023])
Each translation entry maps a virtual page to a physical page number, which corresponds to local memory or remote memory.
(“... the local memory flag field 1506 can hold a “local flag”... having a value that may be switchable between a first value that indicates the physical address in the page field 1504 is a location in the local memory 104 and a second value that indicates the physical address is a location not in the local memory 104.”; Koob, [0025])
The local flag has a value switchable between a first value indicating that the physical address is in the local memory, and a second value indicating that the physical address is in a location not in the local memory.
(“Referring to Figs. 1 and 3, if the hardware page walk at 318 finds a virtual-to-physical mapping... then... the flow 300 can proceed to 324 and determine whether the physical address field of that virtual-to-physical mapping is to a local memory, e.g., the local memory 104, or is outside of the local memory, e.g., the remote memory 106. The flow 300 can the proceed to 326 and use that determination at 324 in updating the TLB 112 with a new translation mapping entry 150. The new translation mapping entry 150 can be formatted according to the example 150-r, having in its VPN field 1502 and page field 1504 the virtual-to-physical mapping found by the hardware page walk at 318, and in its local memory flag field 1506, a local memory flag set value.. indicating whether the physical address is in the local memory 104, or outside of the local memory, e.g., in the remote memory 106. The flow 300 can then proceed to 314, access the memory using the virtual-to-physical mapping found by the hardware page walk at 318, and then end at 316. ”; Koob, [0051])
A determination is made regarding whether the physical address field of the virtual-to-physical address mapping is to a local memory or to a remote memory (memory external to the graphics processor). Asaro, Rao and Koob are silent regarding in response to determining... that the virtual address is mapped to the memory external to the graphics processor, requesting translation of the first physical address via an input/output memory management unit (IOMMU), wherein the memory external to the graphics processor is accessible via the system interface, however, Chinya teaches
(“To support RPE a CPU may identify whether a given virtual address is mapped to system memory or to a remote memory across a peripheral fabric... When the accelerator receives the PCIeTM transaction notifying of an access request from the CPU, the sequencer in the accelerator handles the request as a special interrupt event. The sequencer extracts the access address and access type from the request. If the access address is a virtual address, the sequencer may perform the translation locally via a local MMU to obtain the physical address.”; Chinya, [0026])
The CPU identifies whether the virtual address is mapped to system memory (memory external to the graphics processor) or to remote memory local to the accelerator (in response to determining... that the virtual address is mapped to the memory external to the graphics processor). When the accelerator is notified of an access request from the CPU, the sequencer extracts the access address and access type form the request. If the access address is a virtual address, the sequencer performs translation locally (on system memory, which is a memory external to the graphics processor) via a local MMU to obtain the physical address (request translation of the first physical address via an input/output memory management unit (IOMMU)).
wherein the memory external to the graphics processor is accessible via the system interface. (“As shown in Fig. 1, a system 100 may be an exemplary computer system having a host personal computer (PC) platform 110 that is coupled to an accelerator card 150 via a non-coherent interconnect 140 which may be a PCIeTM link, for example.”; Chinya, [0016], Fig. 1)
Fig. 1 illustrates the PCIeTM link that connects the host platform that includes the system memory (memory external to the graphics processor) and the accelerator card that includes (remote memory local to an accelerator (graphics processor)).
(“To support RPE a CPU may identify whether a given virtual address is mapped to system memory or to a remote memory across a peripheral fabric. ”; Chinya, [0026])
The graphics memory (remote memory local to an accelerator) and the system memory are accessible across a peripheral fabric such as a PCIe (accessible via the system interface). Chinya is combined with Koob, Asaro and Rao such that the local flag of Koob is used in the determination of Chinya and both are included in the system of Asaro. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of in response to determining, based on the local memory bit, that the virtual address is mapped to the memory external to the graphics processor, requesting translation of the first physical address via an input/output memory management unit (IOMMU), wherein the memory external to the graphics processor is accessible via the system interface, in order to allow memory to be addressed without using memory protection and faulting on virtual address access, as taught by Chinya ([0011]).
Claim 11 is a method analogous to the graphics processor of claim 1, is similar in scope and is rejected under the same rationale.
Claim 16 is a system analogous to the graphics processor of claim 1, is similar in scope and is rejected under the same rationale. Claim 16 has additional limitations. Re: claim 16, Asaro teaches
16. (Currently Amended) A data processing system comprising: a local memory device; a system interface coupled with the memory device, the system interface including a device interface configurable for assignment to a guest software domain; and a graphics processor coupled with the system interface and the memory device, (“Fig. 2 is al block diagram illustrating an embodiment of a host system 200 that depicts the host system 102 of Fig. 2 in greater detail… In various virtualization environments of GPU 210, a single-root input/output virtualization (SR-IOV) specification allow for a single Peripheral Component Interconnect Express (PCIe) device to appear as multiple separate PCIe devices. A physical PCIe device of the host system 200 (such as graphics processing unit 210, shared memory 206, or a central processing unit 108 of Fig. 1) having SR-IOV capabilities is configured to appear as multiple functions (virtual functions 212).”; Asaro, [0016], [0022], Figs. 1-2)
Fig. 2 depicts the host system of Fig. 1 in more detail. Fig. 2 illustrates a system 200 that includes a GPU 210, where the GPU 210 includes a single-root input/output virtualization (SR-IOV) which allows for a single physical PCIe device (system interface including a device interface) to appear as multiple separate PCIe devices. Fig. 2 illustrates that the PCIe device is coupled to the GPU (graphics processor coupled with system interface). Fig. 1 illustrates that the GPI is coupled to the frame buffer 122 (local memory device) and the memory 110 (graphics processor coupled with… the memory device).
(“In the example embodiment of Fig. 2, the SR-IOV specification enables the sharing of graphics processing unit 210 among the virtual machines 208. The graphics processing unit 210 is a PCIe device having physical function 211. The virtual functions 212 are derived from the physical function of the graphics processing unit 210, thereby mapping a single physical device (e.g., the graphics processing unit 210) to a plurality of virtual functions 212 that is shared with guest virtual machines 208. In some embodiments, the hypervisor 204 maps (e.g., assigns) the virtual functions 212 to the guest virtual machines 208.”; Asaro, [0023], Fig. 2)
The graphics processing unit (GPU) 210 is a PCIe device (device interface configurable) having a physical function 211, where the virtual functions are derived from the physical function and the physical device (GPU 210) is mapped (for assignment) to a plurality of virtual functions 212 that are shared with guest virtual machines 208 (to the guest software domain).
Asaro is silent regarding the graphics processor comprising a processing circuitry including a plurality of graphics engines, however, Rao teaches the graphics processor comprising a processing circuitry including a plurality of graphics engines, (“… the GPU 108 includes a number of graphics engines (not shown), wherein the graphics engine is configured to perform specific graphics tasks, or to execute specific types of workloads.”; Rao, [0024], Fig. 1)
Fig. 1 illustrates a GPU 108 that includes a number of graphics engines (a processing circuitry including a plurality of graphics engine). Rao is combined with Asaro, such that the GPU of Asaro includes the plural graphics engines of Rao. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of the graphics processor comprising a processing circuitry including a plurality of graphics engines, in order to enable each graphic engine to perform specific graphics tasks or to execute specific types of workloads, as taught by Rao ([0024]).
Re: claims 2 and 13 (which are rejected under the same rationale), Asaro in view of Rao, Koob and Chinya teach
2. (Original) The graphics processor as in claim 1, wherein the first physical address is a guest physical address associated with the guest software domain and the second physical address is a host physical address associated with a host of the guest software domain. ( “The UTC 150 uses a GPUVM located in UCT 150 to convert the VA to a guest physical address (GPA)... the VA to GPA translation may be controlled by the VM or driver software located within the VM.”; Asaro, [0014])
The GPUVM converts the VA to a guest physical address (GPA) (first physical address is a guest physical address). The VA to GPA translation is controlled by the VM (associated with the guest software domain).
(“Frame buffer 222 includes host page tables 240, guest page tables 241 (GPUVM page tables 241)... guest page tables 241 and host page tables 240 represent the page tables for GPUVM 224 and GIOMMU, respectively.”; Asaro, [0019])
The guest page tables represent page tables for the GPUVM (guest software domain) and the host page tables represent page tables for the GIOMMU (host of the guest software domain).
(“The GIOMMU located in the IOHUB 130 converts the GPA to the true system physical address (SPA)... the GPA to SPA translation may be controlled by, for example, hypervisor 116 or a host VM of the hypervisor.”; Asaro, [0014])
The GIOMMU converts the guest physical address (GPA) to the system physical address (SPA) (second physical address is a host physical address). The GPA to SPA translation is controlled by the host VM or hypervisor (associated with a host of the guest software domain).
Re: claims 3 and 14 (which are rejected under the same rationale), Asaro in view of Rao, Koob and Chinya teach
3. (Previously Presented) The graphics processor as in claim 1, wherein the processing circuitry is configured to enable the guest software domain to access the first translation table. ( “GPUVM 224 represents the guest VM layer that uses the guest virtual address (GVA) and the virtual machine identification (VMID) for translation to a guest physical address (GPA). GPUVM 224 performs page table walks individually with GPUVM page tables 241 located in the guest VM portion of frame buffer 222 and distinct from the host page tables 240, also located in frame buffer 222.”; Asaro, [0025])
The GPUVM represents the guest VM layer that uses the guest virtual address (GVA) for translation to a guest physical address (GPA). The GPUVM performs page table walks with GPUVM page tables (enable the guest software domain to access the first translation table) located in the guest VM portion of the frame buffer.
Re: claims 4 and 15 (which are rejected under the same rationale), Asaro in view of Rao, Koob and Chinya teach
4. (Previously Presented) The graphics processor as in claim 3, wherein the processing circuitry is configured to prevent access to the second translation table by the guest software domain. ( “Frame buffer 222 includes host page tables 240, guest page tables 241 (GPUVM page tables 241)... guest page tables 241 and host page tables 240 represent the page tables for GPUVM 224 and GIOMMU, respectively... guest page tables 241 are GPUVM 224 page tables that are in the scattered pages, similar to other guest VM data... the host page tables 240 are located in the non-paged region of memory... GPUVM 224 and GIOMMU 232 are used to fetch guest page tables 241 and host page tables 240, respectively... ”; Asaro, [0019])
The guest page tables are GPUVM page tables located in the scattered pages of the framebuffer. The host page tables are located in the non-paged region of the framebuffer.
(“GPUVM 224 represents the guest VM layer that uses the guest virtual address (GVA) and the virtual machine identification (VMID) for translation to a guest physical address (GPA), GPUVM 224 performs page table walks individually with GPUVM page tables 241 located in the guest VM portion of the framebuffer 222 and distinct from the host page tables 240, also located in framebuffer 222.”; Asaro, [0025])
The GPUVM performs address translation from the GVA to the GPA performing page table walks (first translation tables) with GPUVM page tables located in the guest VM portion of the framebuffer. Thus, the GPUVM accesses the guest VM portion of the framebuffer (and not the host page tables located in the non-paged region of the framebuffer) (prevent access to the second translation table by the guest software domain).
Re: claims 5 and 17 (which are rejected under the same rationale), Asaro in view of Rao, Koob and Chinya teach
5. (Currently Amended) The graphics processor as in claim 1, wherein the memory arbiter circuitry is configurable to arbitrate access to memory for the plurality of graphics engines. (“The locations of the pages are annotated by graphics input/output memory management unit (GIOMMU) that is located in IOHUB of GPU 106. GPU 106 includes a memory controller (MC) 103 and a graphics engine 109 that is bound to a guest VM in VMs 114.”; Asaro, [0012])
The GPU includes an IOHUB that includes an GIOMMU (memory arbiter circuitry). The GPU is considered to include the arbiter (memory arbiter circuitry). The GPU also includes a graphics engine that is bound to a guest VM 114.
(“The GIOMMU located in IOHUB 130 converts the GPA to the true system physical address (SPA)... The UTC 150 returns the SPA to graphics engine 109. At a later instance, graphics engine 109 makes a memory request to framebuffer 122 using the SPA... The GIOMMU will translate the GPAs into SPAs using page table based address translation. The guest physical pages are then accessed using the virtual frame buffer.”; Asaro, [0014])
The GIOMMU performs the address translation of GPA to SPA and controls access to, for example, the framebuffer and the virtual framebuffer.
Asaro is silent regarding the plurality of graphics engines, however, Rao teaches this limitation.
(“… the GPU 108 includes a number of graphics engines (not shown), wherein the graphics engine is configured to perform specific graphics tasks, or to execute specific types of workloads.”; Rao, [0024], Fig. 1)
Fig. 1 illustrates a GPU 108 that includes a number of graphics engines (plurality of graphics engines).
(“A memory management unit (MMU) 126 may be used to manage access to data that is stored within the surface 122.”; Rao, [0031])
The MMU (memory arbiter) manages, for example, graphics engine access to data stored in the surface (arbitrate access to memory for the plurality of graphics engines). Rao is combined with Asaro, such that the GPU of Asaro includes the plural graphics engines of Rao and the MMU of Rao is included in the IOHUB of the GPU of Asaro. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of the plurality of graphics engines, in order to enable each graphic engine to perform specific graphics tasks or to execute specific types of workloads, as taught by Rao ([0024]).
Re: claims 6 and 18 (which are rejected under the same rationale), Asaro, Rao, Koob and Chinya teach
6. (Currently Amended) The graphics processor as in claim 5, wherein the memory arbiter circuitry is configured to perform the first address translation and the second address translation without requesting translation of the first physical address via the IOMMU in response to determining, based on the local memory bit, that the virtual address is mapped to the local memory device. (“Each translation entry 150 can map a virtual page... to a physical page number. The physical page number may correspond to the local memory 104, the remote memory 106, or another non-local resource.”; Koob, [0023])
Each translation entry maps a virtual page to a physical page number, which corresponds to local memory or remote memory (perform the first address translation and the second address translation).
(“... the local memory flag field 1506 can hold a “local flag”... having a value that may be switchable between a first value that indicates the physical address in the page field 1504 is a location in the local memory 104 and a second value that indicates the physical address is a location not in the local memory 104.”; Koob, [0025])
The local flag has a value switchable between a first value indicating that the physical address is in the local memory, and a second value indicating that the physical address is in a location not in the local memory.
(“Referring to Figs. 1 and 3, if the hardware page walk at 318 finds a virtual-to-physical mapping... then... the flow 300 can proceed to 324 and determine whether the physical address field of that virtual-to-physical mapping is to a local memory, e.g., the local memory 104, or is outside of the local memory, e.g., the remote memory 106. The flow 300 can the proceed to 326 and use that determination at 324 in updating the TLB 112 with a new translation mapping entry 150. The new translation mapping entry 150 can be formatted according to the example 150-r, having in its VPN field 1502 and page field 1504 the virtual-to-physical mapping found by the hardware page walk at 318, and in its local memory flag field 1506, a local memory flag set value.. indicating whether the physical address is in the local memory 104, or outside of the local memory, e.g., in the remote memory 106. The flow 300 can then proceed to 314, access the memory using the virtual-to-physical mapping found by the hardware page walk at 318, and then end at 316. ”; (Koob, [0051])
A determination is made regarding whether the physical address field of the virtual-to-physical address mapping is to a local memory or to a remote memory (memory external to the graphics processor). Using the determination, the virtual-to-physical mapping is determined (perform the first address translation and the second address translation) by the hardware page walk and the local memory flag set value (without requesting translation of the first physical address via the IOMMU in response to determining, based on the local memory bit, that the virtual address is mapped to the local memory device), where the local memory flag set value indicates whether the physical address is in the local memory or in the remote memory. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of the memory arbiter circuitry is configured to perform the first address translation and the second address translation without requesting translation of the first physical address via the IOMMU in response to determining, based on the local memory bit, that the virtual address is mapped to the local memory device, in order to provide rapid, low processing overhead switching between a local memory/low power mode that can confine access to local memory, and a normal power mode enabling full access to remote memory, as taught by Koob ([0007]).
Claim(s) 7, 8, 9, 12, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asaro in view of Rao, Koob and Chinya as applied to claim 6 above, and further in view of Karve et al. U.S. Pub. No. 2021/0165745.
Re: claims 7 and 19 (which are rejected under the same rationale), Asaro, Rao, Koob and Chinya are silent regarding the first translation table comprises a per-process graphics translation table, however Shah et al. U.S. Pub. No. 2020/0410628.
7. (Currently Amended) The graphics processor as in claim 6, wherein the first translation table comprises a per-process graphics translation table. “Current systems use the system memory for GPU engines to access a Global Graphics Translation Table (GGTT) and/or a Per-Process Graphics Translation Table (PPGTT) to translate from GPU graphics memory addresses to system memory addresses. A shadowing mechanism may be used for the guest GPU page table's GGTT/PPGTT.”; Shah, [0185])
The GPU engines access a Per-Process Graphics Translation Table to translate from GPU graphics memory addresses to system memory addresses. Shah is combined with Asaro, Rao, Koob and Chinya such that the PPGTT of Shah is the first translation table of Asaro. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of the first translation table comprises a per-process graphics translation table, in order to remap from a guest PPGTT-mapped GPN to HPB without relying on the low efficiency/complicated shadow PPGTT, as taught by Shah ([0187]).
Re: claims 8 and 20 (which are rejected under the same rationale), Asaro in view of Rao, Koob, Chinya and Shah teach
8. (Currently Amended) The graphics processor as in claim 7, wherein the memory arbiter circuitry is configured to: generate a third physical address via the first translation table, the third physical address generated in response to a request to access the memory via a second virtual address; (“When graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122, a guest virtual memory identification (VMID), and the virtual function identification (VFID). The UTC 150 uses a GPUVM located in the UTC 150 to convert the VA to a guest physical address (GPA).”; Asaro, [0014], Fig. 1)
Fig. 1 illustrates GPU 106 and frame buffer 122. The GPU includes graphic engine 109. When the graphics engine intends to access the framebuffer, the graphics engine sends a translation request to the UTC with a virtual address (second virtual address) of the corresponding memory in the framebuffer. The UTC uses a GPUVM located in the UTC to convert the virtual address (VA) to a guest physical address (GPA) (third physical address generated in response to a request to access the memory via a second virtual address).
(“GPUVM 224 represents the guest VM layer that uses the guest virtual address (GVA) and the virtual machine identification (VMID) for translation to a guest physical address (GPA). GPUVM 224 performs page table walks individually with GPUVM page tables 241 located in the guest VM portion of frame buffer 222 and distinct from the host page tables 240, also located in frame buffer 222.”; Asaro, [0025])
The GPUVM (of the GPU) represents the guest VM layer that uses the guest virtual address (GVA) (second virtual address) for translation to a guest physical address (GPA) (generate a third physical address). The GPUVM performs page table walks with GPUVM page tables located in the guest VM portion of the frame buffer (generate a third physical address via the first translation table).
determine that the second virtual address is mapped to the memory external to the graphics processor; (“When the graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122.”; (Asaro, [0014], Fig. 1)
When the graphics engine intends to access the framebuffer, it sends a translation request (determines) to the UTC with the virtual address of the memory location in the framebuffer 122 (second virtual address is mapped to the memory external to the graphics processor).
and request translation of the third physical address via the IOMMU. (“When the graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122.”; Asaro, [0014], Fig. 1)
When the graphics engine intends to access the framebuffer, it sends a translation request (request translation of the third physical address) to the UTC with the virtual address of the memory location in the framebuffer 122.
(“The GIOMMU located in the IOHUB 130 converts the GPA to the true system physical address (SPA)… the GPA to SPA translation may be controlled by, for example, hypervisor 116 or a host VM of the hypervisor… The GIOMMU will translate the GPAs into SPAs using page table based address translation.”; Asaro, [0014], Figs. 1-2)
The GIOMMU (input/output memory management unit (IOMMU)), of the GPU, converts the graphics physical address (GPA) (third physical address) to system physical address (SPA) using page table based translation. The translation from GPA to SPA has been requested and is performed by the GIOMU (request translation of the third physical address via the IOMMU).
Claim 12 is a method analogous to the graphics processor of claim 8 is similar in scope and is rejected under the same rationale. Claim 12 has an additional limitation. Re: claim 12, Asaro in view of Rao, Koob and Chinya teach
12. (Currently Amended) The method as in claim 11, further comprising:... wherein the memory external to the graphics processor is system memory accessed via the system interface of the graphics processor; (“In various virtualization environments of GPU 210, single-root input/output virtualization (SR-IOV) specifications allow for a single Peripheral Component Interconnect Express (PCIe) device to appear as multiple separate PCIe devices. A physical PCIe device of the host system 200 (such as graphics processing unit 210, shared memory 206, or a central processing unit 108 of FIG. 1) having SR-IOV capabilities is configured to appear as multiple functions (virtual functions 212). The term “function” as used herein refers to a device with access controlled by a PCIe bus.”; Asaro, [0022], Figs. 1-2)
Fig. 1 illustrates that the memory 110 (system memory) is external to the GPU 106 (graphics processor). Fig. 2 illustrates a GPU 210, single-root input/output virtualization (SR-IOV) that includes a PCIe bus (system interface of the graphics processor) that accesses, for example the memory (system memory accessed via a system interface of the graphics processor).
Re: claim 9, Asaro in view of Rao, Koob, Chinya and Shah teach
9. (Previously Presented) The graphics processor as in claim 7, wherein the memory arbiter circuitry includes a translation lookaside buffer (TLB) to cache a result of the first address translation and the second address translation. (“... the GPUVM 224 and GIOMMU 232 are used to fetch guest page tables 241 and host page tables 240 respectively... GPUVM 224 and GIOMMU 232 may also optionally cache portions of guest page tables 241 and host page tables 240. IOTLB 220 may cache address translations received from GIOMMU 232.”; Asaro, [0019], Fig. 2)
The input/output translation lookaside buffer (IOTLB) caches address translations received from the GIOMMU.
(“GPUVM 224 represents the guest VM layer that uses the guest virtual address (GVA) and the virtual machine identification (VMID) for translation to a guest physical address (GPA). GPUVM 224 performs page table walks individually with GPUVM page tables 241 located in the guest VM portion of frame buffer 222 and distinct from the host page tables 240, also located in frame buffer 222. IOTLB 220 relies on GIOMMU 232 to fetch translations during translation requests from virtual machines 208.”; Asaro, [0025], Fig. 2)
The IOTLB receives and caches translations, from the GIOMMU, that have been performed by the GPUVM (GVA to GPA address translations) (translation lookaside buffer (TLB) to cache a result of the first address translation).
(“The IOTLB 220 and GIOMMU 232, which in combination comprise the host VM layer, use the GPA and VFID for translation to the system physical address (SPA). Thus, the UTC 250 translates the virtual address to a physical address (i.e., the physical address is the final location of the data to be stored in, for example, frame buffer 222) and provides the translated physical address to graphics engine 209. ”; Asaro, [0031], Fig. 2)
The IOTLB and the GIOMMU, of the GPU, use the cached GPA for translation to the system physical address (SPA). The universal translation cache (UTC), which includes the IOTLB, performs the translation form GPA to SPA (second address translation) and provides the SPA to the graphics engine.
(“Graphics engine 209 receives the physical address provided by IOTLB 220 of UTC 250 and makes a memory access request to frame buffer 222 using the SPA.”; Asaro, [0032], Fig. 2)
The graphics engine receives the SPA, provided by the IOTLB of the UTC, and makes a memory access request to frame buffer 222 using the SPA. Thus, the SPA (result of the second address translation) has been cached to the IOTLB (translation lookaside buffer (TLB) to cache the result of the second address translation).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asaro in view of Rao, Koob and Chinya as applied to claim 9 above, and further in view of Banerjee et al. U.S. Pub. No. 2020/0379920.
Re: claim 10, Asaro in view of Rao, Koob and Chinya teach
10. (Previously Presented) The graphics processor as in claim 9, further comprising a graphics microcontroller coupled with the system interface, the local memory device, and the processing circuitry, (“Fig. 2 is a block diagram illustrating an embodiment of a host system 200 that depicts the host system 102 of Fig. 2 in greater detail… In various virtualization environments of GPU 210, a single-root input/output virtualization (SR-IOV) specification allow for a single Peripheral Component Interconnect Express (PCIe) device to appear as multiple separate PCIe devices. A physical PCIe device of the host system 200 (such as graphics processing unit 210, shared memory 206, or a central processing unit 108 of Fig. 1) having SR-IOV capabilities is configured to appear as multiple functions (virtual functions 212).”; Asaro, [0016], [0022])
Fig. 2 depicts the host system of Fig. 1 in more detail. Fig. 2 illustrates a system 200 that includes a GPU 21, where the GPU 210 (processing circuitry) includes a single-root input/output virtualization (SR-IOV) which allows for a single PCIe device (system interface) to appear as multiple separate PCIe devices. The GPU 210 is also a PCIe device.
(“When graphics engine 109 intends to access framebuffer 122, graphics engine 109 sends a translation request to the universal translation cache (UTC) 150 with the virtual address (VA) of the corresponding memory in framebuffer 122, a guest virtual memory identification (VMID), and the virtual function identification (VFID). The UTC 150 uses a GPUVM located in the UTC 150 to convert the VA to a guest physical address (GPA).”; Asaro, [0014], Fig. 1)
Fig. 1 illustrates GPU 106 (processing circuitry) coupled to the frame buffer 122 (local memory device) and the CPU 108.
Asaro, Rao, Koob and Chinya are silent regarding a graphics microcontroller... and the processing circuitry, wherein the graphics microcontroller is configurable to invalidate an entry in the TLB, however, Banerjee teaches
(“... the GPU complex 136 includes a GPU TLBI controller 148 which, like the TLBI controller 126, may be configured to flush or invalidate the GPU TLB 144.”; Banerjee, [0022], Fig. 1)
Fig. 1 illustrates a GPU complex 136 (graphics processor) that includes a GPU TLBI controller (graphics microcontroller). Banerjee is combined with Asaro such that the GPU of Asaro includes the GPU TLBI controller of Banerjee.
wherein the graphics microcontroller is configurable to invalidate an entry in the TLB. (“... the GPU complex 136 includes a GPU TLBI controller 148 which, like the TLBI controller 126, may be configured to flush or invalidate the GPU TLB 144.”; Banerjee, [0022], Fig. 1)
The GPU translation lookaside buffer invalidation (TLBI) controller is configured to invalidate the GPU TLB.
(“If a virtual memory address translation becomes invalid... the MMU signals to the TLB via the respective TLB invalidation controller, respectively, to invalidate a TLB entry corresponding to this virtual memory address translation.”; Banerjee, [0025], Fig. 1)
When the virtual memory address translation becomes invalid, the TLB invalidation controller (graphics microcontroller) is signaled to invalidate a TLB entry corresponding to this virtual address translation (invalidate an entry in the TLB). Banerjee is combined with Asaro such that the GPU of Asaro includes the GPU TLBI controller performing the invalidation function of Banerjee. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the system of Asaro by adding the feature of a graphics microcontroller coupled with the system interface, the local memory device, and the processing circuitry, wherein the graphics microcontroller is configurable to invalidate an entry in the TLB, in order to clear no longer needed TLB entries and to prevent potential security issues when a TLB is shared among multiple applications, as taught by Banerjee ([0014]).
Response to Arguments
Applicant’s arguments, see Amendment/Request for Reconsideration-After Non-Final Rejection, filed 6/10/2026, with respect to the rejection(s) of claim(s) 1, 11 and 16 under 35 U.S.C § 103 Rejection have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Asaro, Rao, Koob and Chinya. Applicant argues regarding claims 1, 11, and 16:
“As amended, claim 1 recites memory arbiter circuitry configured to perform a first address translation via a first translation table to generate a first physical address, and to determine, based on a local memory bit within an entry of the first translation table, whether the virtual address is mapped to the local memory device or to memory external to the graphics processor. Claim 1 further recites two different responses to that bit-driven determination:
" when the memory arbiter circuitry determines, based on the local memory bit, that the virtual address is mapped to the local memory device, the memory arbiter circuitry performs a second address translation on the first physical address via a second translation table stored in the local memory device and accesses the local memory device via the resulting second physical address; and
" when the memory arbiter circuitry determines, based on the local memory bit, that the virtual address is mapped to memory external to the graphics processor, the memory arbiter circuitry requests translation of the first physical address via an input/output memory management unit (IOMMU), with the external memory accessed via the system interface. Independent claims 11 and 16 recite corresponding subject matter in method and data- processing-system form. These amendments are supported by the specification, figures, and claims as originally filed. This is not merely a claim to a local/non-local flag in isolation, nor merely a claim to a conventional two-stage virtual-address translation. The claims require structural and conditional coupling between: (1) a bit in an entry of the first translation table; (2) a determination of whether the virtual address maps to local memory or external memory; (3) a local-memory path using a second translation table stored in local memory; and (4) an external-memory path using IOMMU translation. The cited art does not teach or suggest this claimed architecture.”
Examiner disagrees. The combination of Asaro, Rao, Koob and Chinya teaches these amended limitations of claim 1. Koob teaches a bit in an entry of the first translation table and a determination of whether the virtual address maps to local memory or external memory. Koob teaches that translation entries include a local memory flag field that holds a local flag (local memory bit within an entry). The local flag that is switchable between a first value that indicates whether the physical address is in local memory or whether the second value that indicates that the physical address is not on local memory. The local flag of an entry is used to determine whether the virtual address is mapped to the local memory device. Koob is combined with Asaro and Rao such that the local flag of Koob is included in the entry of Asaro. (Koob, [0025], Fig. 1). Asaro teaches a local-memory path using a second translation table stored in local memory. Asaro teaches that the GIOMMU converts the graphics physical address (GPA) (first physical address) to system physical address (SPA) (second physical address) using page table based translation (perform a second address translation on the first physical address via a second translation table stored in the local memory device, the second address translation to generate a second physical address). Fig. 1 illustrates that the second translation table is stored in the GPU. (Asaro, [0014], Figs. 1-2). Koob and Chinya teach an external-memory path using IOMMU translation. Koob teaches that each translation entry maps a virtual page to a physical page number, which corresponds to local memory or remote memory. (Koob, [0023]). The local flag has a value switchable between a first value indicating that the physical address is in the local memory, and a second value indicating that the physical address is in a location not in the local memory. (Koob, [0025]). A determination is made regarding whether the physical address field of the virtual-to-physical address mapping is to a local memory or to a remote memory (memory external to the graphics processor). (Koob, [0051]). And Chinya teaches that the CPU identifies whether the virtual address is mapped to system memory (memory external to the graphics processor) or to remote memory local to the accelerator (in response to determining... that the virtual address is mapped to the memory external to the graphics processor). When the accelerator is notified of an access request from the CPU, the sequencer extracts the access address and access type form the request. If the access address is a virtual address, the sequencer performs translation locally (on system memory, which is a memory external to the graphics processor) via a local MMU to obtain the physical address (request translation of the first physical address via an input/output memory management unit (IOMMU)). (Chinya, [0026]).
Applicant argues:
“The present Office Action states that Asaro and Rao are silent regarding a local memory bit within an entry and relies on Koob for the local memory bit. The Office Action further states that Koob teaches the limitation of performing the second translation 'in response to' a local- memory determination. Applicant respectfully disagrees. Koob's cited local memory flag is a flag in a TLB translation entry. Koob describes translation entries that include a local memory flag field, and describes operation after a TLB hit in which a local flag is evaluated with low-power access exception logic. Koob's local flag indicates whether a physical page is in local memory or not local memory for purposes of local- memory access / low-power exception behavior. This teaching is not equivalent to the amended claims. The amended independent claims require a local memory bit within an entry of the first translation table. The claims further require that this bit-driven determination selects between two different translation paths: a local-memory path in which a second address translation is performed on the first physical address via a second translation table stored in local memory, and an external-memory path in which translation is requested via an IOMMU. Koob does not disclose a bit in a first translation table entry used to select between those two translation paths. The Office Action appears to equate Koob's generation or use of a physical address following a TLB hit with the claimed second address translation. That reading is not consistent with the claim language. The claims require two translations and two tables: a first translation via a first translation table generates a first physical address, and a second translation is then performed on that first physical address via a second translation table stored in local memory. Koob's cited local flag does not cause such a second table walk, does not select a second translation table stored in local memory, and does not select between a local-memory translation table and IOMMU translation. Thus, Koob does not teach or suggest the amended limitations.”
Examiner disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The combination of references teach these limitations. Asaro teaches that when the graphics engine intends to access framebuffer 122 (local memory device), a translation request is sent and the virtual address (VA) is converted to a guest physical address (GPA). Then the GPA is converted to the system physical address (SPA) (second address translation to generate a second physical address). (Asaro, [0014]). The GPUVM represents the guest VM layer that uses the guest virtual address (GVA) for translation to a guest physical address (GPA). The GPUVM performs page table walks with GPUVM page tables (determine, based on... an entry of the first translation table) located in the guest VM portion of the frame buffer (virtual address is mapped to the local memory device). (Asaro, [0025]). The GIOMMU converts the graphics physical address (GPA) (first physical address) to system physical address (SPA) (second physical address) using page table based translation (perform a second address translation on the first physical address via a second translation table stored in the local memory device, the second address translation to generate a second physical address). (Asaro, [0014], Figs. 1-2). Guest page tables (used by the GPUVM to perform GPA to GVA translation) and host page tables (used by the GIOMMU to perform GPA to SPA translation (second translation table)) are both stored in the frame buffer (second translation table stored in the local memory device). (Asaro, [0019], [0025], Fig. 1). Koob teaches that the translation entries include a local memory flag field that holds a local flag (local memory bit within an entry). The local flag that is switchable between a first value that indicates whether the physical address is in local memory or whether the second value that indicates that the physical address is not on local memory. The local flag of an entry is used to determine whether the virtual address is mapped to the local memory device. The local flag of an entry is indicates whether the virtual address is mapped to the local memory device or to non-local memory. (Koob, [0025], Fig. 1). If a matching translation entry is found, a TLB hit event is generated. Operation of the switchable power/memory access mode processor, in response to a TLB hit event, depends on the local memory flag in the matching translation entry. If the local memory flag indicates the physical page number in the page field is located in the local memory (in response to determining... that the virtual address is mapped to the local memory device), a physical address is generated and the local memory is accessed (perform a second address translation on the first physical address via a second translation table). If the local memory flag indicates the physical page number in the page field is outside the local memory, the LP access exception logic outputs an active low power exception signal. (Koob, [0038]). Each translation entry maps a virtual page to a physical page number, which corresponds to local memory or remote memory. (Koob, [0023]). The local flag has a value switchable between a first value indicating that the physical address is in the local memory, and a second value indicating that the physical address is in a location not in the local memory. (Koob, [0025]). A determination is made regarding whether the physical address field of the virtual-to-physical address mapping is to a local memory or to a remote memory (memory external to the graphics processor). (Koob, [0051]). And Chinya teaches that the CPU identifies whether the virtual address is mapped to system memory (memory external to the graphics processor) or to remote memory local to the accelerator (in response to determining... that the virtual address is mapped to the memory external to the graphics processor). When the accelerator is notified of an access request from the CPU, the sequencer extracts the access address and access type form the request. If the access address is a virtual address, the sequencer performs translation locally (on system memory, which is a memory external to the graphics processor) via a local MMU to obtain the physical address (request translation of the first physical address via an input/output memory management unit (IOMMU)). (Chinya, [0026])
Applicant argues:
“The Office Action combines Koob with Asaro and states that Asaro and Koob are
combined such that Asaro's second translation is performed in response to Koob's local-memory determination. Applicant respectfully submits that the asserted combination is unsupported by the references and relies on Applicant's disclosure as a roadmap. Asaro teaches an unconditional GPUVM/GIOMMU translation sequence. In Asaro, a graphics engine sends a -translation request with a virtual address. A GPUVM/UTC converts the virtual address to a guest physical address. The GIOMMU then converts the guest physical address to a system physical address. Asaro does not disclose a local memory bit in an entry of the GPUVM page table. Asaro also does not disclose making GIOMMU translation conditional on a first-table bit indicating local memory. Koob does not fill that gap. Koob's local flag is in a TLB entry and is used for local/non- local access or exception behavior in the context of a switchable power/memory access mode. Koob does not teach modifying Asaro's GPUVM page table entries to include a local memory bit, and Koob does not teach repurposing its TLB local flag to select between Asaro's GIOMMU path and a second translation table stored in local memory. The amended claims now make the missing coupling explicit. The local memory bit is in the first translation table entry, and the bit selects between the local-memory second-translation- table path and the IOMMU path. Neither Asaro nor Koob teaches this feature, and their combination does not render it obvious.”
Examiner disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). As discussed above, the combination of references teach these amended limitations.
Applicant argues:
“The Office Action states, in substance, that Asaro and Koob are combined so that the second translation is performed in response to Koob's local-memory determination. But the Office Action does not provide an adequate reason why a person of ordinary skill would have modified Asaro in the specific manner required by the amended claims.
In particular, the Office Action does not explain why a person of ordinary skill would have:
1. modified Asaro's first translation table / GPUVM page-table entries to include Koob's TLB-local flag;
2. moved or duplicated Koob's local flag from a TLB entry into an entry of Asaro's first translation table;
3. repurposed Koob's low-power exception/local-access flag into a selector between a local-memory second translation table and IOMMU translation;
4. made Asaro's otherwise unconditional GIOMMU translation conditional on the first- table local memory bit; or
5. provided a second translation table stored in local memory that is selected in response to that first-table local memory bit.”
Examiner disagrees. In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Koob is combined with Asaro in order to provide rapid, low processing overhead switching between a local memory/low power mode that can confine access to local memory, and a normal power mode enabling full access to remote memory, as taught by Koob ([0007]). .
Applicant argues:
“The Office Action also relies on Rao for a plurality of graphics engines and MMU management of access to data. Applicant does not understand Rao to cure the deficiencies discussed above. Even if Rao teaches a GPU with multiple graphics engines and an MMU that manages access to memory, Rao does not teach the claimed bit-selected local-memory/IOMMU path selection. Rao does not teach a local memory bit within an entry of a first translation table. Rao does not teach performing a second translation via a second translation table stored in local memory in response to that bit indicating local memory. Rao also does not teach requesting IOMMU translation in response to the same bit indicating external memory. As amended, the independent claims do not merely require a generic MMU or generic arbitration of memory access. The claims require memory arbiter circuitry configured to perform the claimed first translation, make the bit-driven local/external determination, perform the local- memory second translation via the local second translation table when the bit indicates local memory, and request IOMMU translation when the bit indicates external memory. The combined teachings of Asaro, Rao, and Koob do not disclose or suggest that architecture.”
Examiner disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). As discussed above, the combination of references teach these amended limitations.
Applicant's arguments filed 6/10/2026 have been fully considered but they are not persuasive. Applicant argues:
“Claim(s) 7, 8, 9, 12, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asaro in view of Rao and Koob as applied to claim 6 above, and further in view of Karve et al. U.S. Pub. No. 2021/0165745. The Office Action relies on Karve for additional address/TLB features in claims 7-9, 12, and 19-20. As Karve does not cure the deficiencies in the independent claims, applicant respectfully submits that this rejection is overcome, at the least, by way of dependence upon respective amended independent claims.”
Examiner disagrees. Claims 6 and claims 7, 8, 9, 12, 19 and 20 have been rejected. Please see the corresponding rejections.
Applicant's arguments filed 6/10/2026 have been fully considered but they are not persuasive. Applicant argues:
“Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asaro in view of Rao, Koob and Karve as applied to claim 9 above, and further in view of Banerjee et al. U.S. Pub. No. 2020/0379920. Banerjee is relied upon for TLB invalidation in claim 10. Applicant respectfully submits that Banerjee fails to cure the deficiencies of Asaro, Rao, Koob, and Karve discussed above. Even if Banerjee teaches invalidating a TLB entry, Banerjee does not teach the claimed first-table local memory bit, the claimed bit-selected local-memory/IOMMU path selection, or the claimed second translation table stored in local memory. Thus, the rejection of claim 10 should be withdrawn at least by virtue of its dependence from allowable 9 and independent claim 1.”
Examiner disagrees. Claims 9 and 10 have been rejected. Please see the corresponding rejections.
Conclusion
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 DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
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, Devona Faulk can be reached on 571-272-7776. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2618
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights