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 Objections
Claim 15 is objected to because of the following informalities: The claim now states, “…wherein the physical memory is located in storage of a first graphics processing unit (GPU) storage or host storage…”. This doesn’t appear grammatically correct. Appropriate correction is required.
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.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rao et al. US Patent Application Publication No. 2015/0206277 (herein after referred to as Rao) in view of Haywood et al. US Patent Application Publication No. 2021/0390066 (herein after referred to as Haywood).
Regarding claim 1, Rao describes one or more processors (…unified memory support is provided across multiple heterogeneous processors. With unified memory support in a system, data can be accessed using the same pointer from the CPU and the GPU in that system. However, for systems that contain multiple GPUs, the same pointer has to be accessible across all GPUs that are capable of supporting unified memory (page 9, paragraph [0107])), comprising: circuitry to (With reference to Fig. 9, a block diagram of an exemplary computer system 900… (page 3, paragraph [0054]). Computing Systems are known to be comprised of circuits), in response to an application programming interface (API) call (…through an application program interface (API) (e.g., like cudaMalloc, etc.) (page 2, paragraph [0032])), allocate virtual memory and cause storage of a first graphics processing unit (GPU) or host storage to be mapped to the allocated virtual memory (In block 1310, a memory allocation process is performed. In one embodiment, a memory allocation process similar to an address allocation process in block 120 is performed. In one exemplary implementation, a CudaMalloc call is made, memory is allocated on a GPU and a CPU, and a CPU PA space is mapped to a GPU VA space (page 5, paragraph [0068])). Rao does not specifically disclose wherein the circuitry is further to: select, from among a plurality of hardware interconnects between the first GPU and one or more of a host or a second GPU, a route based, at least in part, on bandwidth of the route; and direct memory allocation signals along the selected route.
Haywood describes a multi-path fabric interconnected system with many nodes and many communication paths from a given source node to a given destination node. Specifically, the memory allocation device on an originating node (local node) requests an allocation of memory from a remote node (i.e., requests a remote allocation). The memory allocation device on the local node selects the remote node based on one or more performance indicators. For example, the local memory allocation device may select the remote node to provide a remote allocation of memory based on one or more of: latency, availability, multi-path bandwidth, data access patterns (both local and remote), fabric congestion, allowed bandwidth limits, maximum latency limits, and, available memory on remote node (page 1, paragraph [0009]). Further communication between the originating node and remote node would occur along the selected path, which considered multi-path bandwidth as part of the selection.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Haywood teachings in the Rao system. Skilled artisan would have been motivated to incorporate the method of considering multi-path bandwidth limits in node/path selection as taught by Haywood in the Rao system for effectively improving communication by considering bandwidth in selection. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as memory allocation. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 2, Rao in view of Haywood describe the one or more processors of claim 1 (see above), wherein the circuitry is to allocate the virtual memory based, at least in part, on a flag in memory of one or more second processors (When a user passes in a special flag called managed memory it indicates it is one unified memory (Rao, page 6, paragraph [0080]). …a “host” flag may be used instead for the argument which means that the data will only be touched from the CPU side, so anything the GPU may be doing to the data will not affect it… (Rao, page 13, paragraph [0157]). While the call “CudaMallocManaged” will allocate on the GPU, the flag (global, host, etc.) indicates who will be accessing the data (Rao, page 13, paragraph [0159])).
Regarding claim 3, Rao in view of Haywood describe the one or more processors of claim 1 (see above), wherein the circuitry is to allocate the virtual memory based, at least in part, on a descriptor to create the virtual memory (…a “host” flag may be used instead for the argument which means that the data will only be touched from the CPU side, so anything the GPU may be doing to the data will not affect it… (Rao, page 13, paragraph [0157])).
Regarding claim 4, Rao in view of Haywood describe the one or more processors of claim 1 (see above), wherein the allocated virtual memory comprises a range of memory (In one embodiment, the allocator maintains an internal heap of the VA address ranges it has reserved on the CPU (e.g., using mmap in block 210, etc.). This heap represents the GPU allocations. Now given a VA pointer, the allocator or the runtime can determine if this is a GPU allocation or a CPU allocation by looking up the heap (Rao, page 3, paragraph [0043]). These are essentially windows or ranges into the GPU memory (Rao, page 6, paragraph [0077]). The device driver can create the mapping by using a window or range and shifting and creating a CPU to VA mapping, then the device driver can read and write the memory itself and then send the content back to the user debugger (Rao, page 6, paragraph [0078])).
Regarding claim 5, Rao in view of Haywood describe the one or more processors of claim 1 (see above), wherein the host storage is storage of a central processing unit (CPU) (Many computing systems often have a central processing unit (CPU)… (Rao, page 1, paragraph [0007]). …unified memory architectures or schemes (e.g., compatible with CUDA 6.0, etc.) can result in cases where the same memory can be accessed on a host (e.g., CPU, etc.)… (Rao, page 5, paragraph [0063]). In one embodiment, a host is a CPU and a device is a GPU (Rao, page 6, paragraph [0075])).
Regarding claim 6, Rao in view of Haywood describe the one or more processors of claim 1 (see above), wherein the first GPU is to reserve the virtual memory based, at least in part, on the API call (The GPU driver reserves one or more regions from the CPU’s virtual address space. The same or similar set of regions are also reserved in the GPUs virtual address space (Rao, page 7, paragraph [0084]). If CUDAmalloc managed is used a chunk of CPU VA or reserved region is picked and the physical pages or actual physical memory on the GPU is allocated and then in the GPU VA space set up mapping from GPU page table (e.g., from that region set up mapping to that physical memory, etc.) (Rao, page 8, paragraph [0100])).
Regarding claim 7, Rao in view of Haywood describe the one or more processors of claim 1 (see above), wherein the circuitry is to cause access to the storage of the first GPU or the host storage using the selected route (In a multi-path fabric interconnected system with many nodes, there are many communication paths …memory allocation device on the local node selects the remote node based on one or more performance indicators… multi-path bandwidth… (Haywood, page 1, paragraph [0009]). Further communication between the originating node and remote node would occur through the selected path).
Regarding claim 8, Rao describes a system, comprising: one or more processors (…unified memory support is provided across multiple heterogeneous processors. With unified memory support in a system, data can be accessed using the same pointer from the CPU and the GPU in that system. However, for systems that contain multiple GPUs, the same pointer has to be accessible across all GPUs that are capable of supporting unified memory (page 9, paragraph [0107])) to, in response to an application programming interface (API) call (…through an application program interface (API) (e.g., like cudaMalloc, etc.) (page 2, paragraph [0032])), allocate virtual memory and cause storage of a first graphics processing unit (GPU) or host storage to be mapped to the allocated virtual memory (In block 1310, a memory allocation process is performed. In one embodiment, a memory allocation process similar to an address allocation process in block 120 is performed. In one exemplary implementation, a CudaMalloc call is made, memory is allocated on a GPU and a CPU, and a CPU PA space is mapped to a GPU VA space (page 5, paragraph [0068])). Rao does not specifically disclose wherein the circuitry is further to: select, from among a plurality of hardware interconnects between the first GPU and one or more of a host or a second GPU, a route based, at least in part, on bandwidth of the route; and direct memory allocation signals along the selected route.
Haywood describes a multi-path fabric interconnected system with many nodes and many communication paths from a given source node to a given destination node. Specifically, the memory allocation device on an originating node (local node) requests an allocation of memory from a remote node (i.e., requests a remote allocation). The memory allocation device on the local node selects the remote node based on one or more performance indicators. For example, the local memory allocation device may select the remote node to provide a remote allocation of memory based on one or more of: latency, availability, multi-path bandwidth, data access patterns (both local and remote), fabric congestion, allowed bandwidth limits, maximum latency limits, and, available memory on remote node (page 1, paragraph [0009]). Further communication between the originating node and remote node would occur along the selected path, which considered multi-path bandwidth as part of the selection.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Haywood teachings in the Rao system. Skilled artisan would have been motivated to incorporate the method of considering multi-path bandwidth limits in node/path selection as taught by Haywood in the Rao system for effectively improving communication by considering bandwidth in selection. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as memory allocation. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 9, Rao in view of Haywood describe the system of claim 8 (see above), wherein the one or more processors are to allocate the virtual memory based, at least in part, on information including a location in memory of one or more second processors (The presented new approach or solution uses OS allocation on the CPU combined with GPU driver mappings to provide a unified VA across both GPU and CPU (Rao, page 2, paragraph [0030]). Virtual addresses associated with the GPU can be mapped to the GPU PA. In one embodiment, GPU VA 410 allocated space 411 (including an address associated with pointer 412) is mapped to GPU PA 430 address 431 via GPU PTE 420 mapping entry or indication 421… Virtual addresses associated with the CPU can be mapped to the CPU PA. The CPU VA 440 address associated with pointer 433 is mapped to CPU PA 450 address 451 via CPU PTE 470 mapping entry or indication 471… (Rao, page 3, paragraph [0048])).
Regarding claim 10, Rao in view of Haywood describe the system of claim 8 (see above), wherein the one or more processors are to allocate the virtual memory based, at least in part, on a descriptor to reserve the virtual memory (The GPU driver reserves one or more regions from the CPU’s virtual address space. The same or similar set of regions are also reserved in the GPUs virtual address space (Rao, page 7, paragraph [0084]). If CUDAmalloc managed is used a chunk of CPU VA or reserved region is picked and the physical pages or actual physical memory on the GPU is allocated and then in the GPU VA space set up mapping from GPU page table (e.g., from that region set up mapping to that physical memory, etc.) (Rao, page 8, paragraph [0100]). …a “host” flag may be used instead for the argument which means that the data will only be touched from the CPU side, so anything the GPU may be doing to the data will not affect it… (Rao, page 13, paragraph [0157])).
Regarding claim 11, Rao in view of Haywood describe the system of claim 8 (see above), wherein the one or more processors access a range of memory of the storage of the first GPU or the host storage (In one embodiment, the allocator maintains an internal heap of the VA address ranges it has reserved on the CPU (e.g., using mmap in block 210, etc.). This heap represents the GPU allocations. Now given a VA pointer, the allocator or the runtime can determine if this is a GPU allocation or a CPU allocation by looking up the heap (Rao, page 3, paragraph [0043]). These are essentially windows or ranges into the GPU memory (Rao, page 6, paragraph [0077]). The device driver can create the mapping by using a window or range and shifting and creating a CPU to VA mapping, then the device driver can read and write the memory itself and then send the content back to the user debugger (Rao, page 6, paragraph [0078])).
Regarding claim 12, Rao in view of Haywood describe the system of claim 8 (see above), wherein the host storage is storage of a central processing unit (CPU) (Many computing systems often have a central processing unit (CPU)… (Rao, page 1, paragraph [0007]). …unified memory architectures or schemes (e.g., compatible with CUDA 6.0, etc.) can result in cases where the same memory can be accessed on a host (e.g., CPU, etc.)… (Rao, page 5, paragraph [0063]). In one embodiment, a host is a CPU and a device is a GPU (Rao, page 6, paragraph [0075])).
Regarding claim 13, Rao in view of Haywood describe the system of claim 8 (see above), wherein the first GPU is to reserve the virtual memory based, at least in part, on the API call (The GPU driver reserves one or more regions from the CPU’s virtual address space. The same or similar set of regions are also reserved in the GPUs virtual address space (Rao, page 7, paragraph [0084]). If CUDAmalloc managed is used a chunk of CPU VA or reserved region is picked and the physical pages or actual physical memory on the GPU is allocated and then in the GPU VA space set up mapping from GPU page table (e.g., from that region set up mapping to that physical memory, etc.) (Rao, page 8, paragraph [0100])).
Regarding claim 14, Rao in view of Haywood describe the system of claim 8 (see above), wherein the one or more processors are to cause access of the storage of the first GPU or the host storage using the selected route (In a multi-path fabric interconnected system with many nodes, there are many communication paths …memory allocation device on the local node selects the remote node based on one or more performance indicators… multi-path bandwidth… (Haywood, page 1, paragraph [0009]). Further communication between the originating node and remote node would occur through the selected path).
Regarding claim 15, Rao describes a method, comprising: receiving an application programming interface (API) call (…through an application program interface (API) (e.g., like cudaMalloc, etc.) (page 2, paragraph [0032])) comprising a parameter indicating a location of physical memory to be used for virtual memory to be allocated ; in response to the API call, allocating the virtual memory and causing the virtual memory to be mapped to the location of the physical memory, wherein the physical memory is located in storage of a first graphics processing unit (GPU) storage or host storage (In block 1310, a memory allocation process is performed. In one embodiment, a memory allocation process similar to an address allocation process in block 120 is performed. In one exemplary implementation, a CudaMalloc call is made, memory is allocated on a GPU and a CPU, and a CPU PA space is mapped to a GPU VA space (page 5, paragraph [0068])). Rao does not specifically disclose wherein the circuitry is further to: select, from among a plurality of hardware interconnects between the first GPU and one or more of a host or a second GPU, a route based, at least in part, on bandwidth of the route; and direct memory allocation signals along the selected route.
Haywood describes a multi-path fabric interconnected system with many nodes and many communication paths from a given source node to a given destination node. Specifically, the memory allocation device on an originating node (local node) requests an allocation of memory from a remote node (i.e., requests a remote allocation). The memory allocation device on the local node selects the remote node based on one or more performance indicators. For example, the local memory allocation device may select the remote node to provide a remote allocation of memory based on one or more of: latency, availability, multi-path bandwidth, data access patterns (both local and remote), fabric congestion, allowed bandwidth limits, maximum latency limits, and, available memory on remote node (page 1, paragraph [0009]). Further communication between the originating node and remote node would occur along the selected path, which considered multi-path bandwidth as part of the selection.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Haywood teachings in the Rao system. Skilled artisan would have been motivated to incorporate the method of considering multi-path bandwidth limits in node/path selection as taught by Haywood in the Rao system for effectively improving communication by considering bandwidth in selection. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as memory allocation. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 16, Rao in view of Haywood describe the method of claim 15 (see above), wherein the parameter is a flag in memory to indicate the host storage when a default is device storage (When a user passes in a special flag called managed memory it indicates it is one unified memory (Rao, page 6, paragraph [0080]). …a “host” flag may be used instead for the argument which means that the data will only be touched from the CPU side, so anything the GPU may be doing to the data will not affect it… (Rao, page 13, paragraph [0157]). While the call “CudaMallocManaged” will allocate on the GPU, the flag (global, host, etc.) indicates who will be accessing the data (Rao, page 13, paragraph [0159])).
Regarding claim 17, Rao in view of Haywood describe the method of claim 15 (see above), further comprising generating a flag to indicate a host memory allocation when creating one or more blocks of memory (When a user passes in a special flag called managed memory it indicates it is one unified memory (Rao, page 6, paragraph [0080]). …a “host” flag may be used instead for the argument which means that the data will only be touched from the CPU side, so anything the GPU may be doing to the data will not affect it… (Rao, page 13, paragraph [0157]). While the call “CudaMallocManaged” will allocate on the GPU, the flag (global, host, etc.) indicates who will be accessing the data (Rao, page 13, paragraph [0159])).
Regarding claim 18, Rao in view of Haywood describe the method of claim 15 (see above), further comprising indicating a range of memory of the storage of the first GPU or the host storage (In one embodiment, the allocator maintains an internal heap of the VA address ranges it has reserved on the CPU (e.g., using mmap in block 210, etc.). This heap represents the GPU allocations. Now given a VA pointer, the allocator or the runtime can determine if this is a GPU allocation or a CPU allocation by looking up the heap (Rao, page 3, paragraph [0043]). These are essentially windows or ranges into the GPU memory (Rao, page 6, paragraph [0077]). The device driver can create the mapping by using a window or range and shifting and creating a CPU to VA mapping, then the device driver can read and write the memory itself and then send the content back to the user debugger (Rao, page 6, paragraph [0078])).
Regarding claim 19, Rao in view of Haywood describe the method of claim 15 (see above), wherein the host storage is storage of a central processing unit (CPU) (Many computing systems often have a central processing unit (CPU)… (Rao, page 1, paragraph [0007]). …unified memory architectures or schemes (e.g., compatible with CUDA 6.0, etc.) can result in cases where the same memory can be accessed on a host (e.g., CPU, etc.)… (Rao, page 5, paragraph [0063]). In one embodiment, a host is a CPU and a device is a GPU (Rao, page 6, paragraph [0075])).
Regarding claim 20, Rao in view of Haywood describe the method of claim 15 (see above), further comprising causing access to the storage of the first GPU or the host storage using the selected route (In a multi-path fabric interconnected system with many nodes, there are many communication paths …memory allocation device on the local node selects the remote node based on one or more performance indicators… multi-path bandwidth… (Haywood, page 1, paragraph [0009]). Further communication between the originating node and remote node would occur through the selected path).
Response to Arguments
Applicant’s arguments with respect to claims 1 – 20 have been considered but are moot because the arguments are directed toward the newly amended limitations, which are addressed by the new grounds of rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Butcher et al. US Patent No. 10990562 describes that more hops may be more expensive but could be more efficient if the available bandwidth is higher than a closer memory.
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 RALPH A VERDERAMO III whose telephone number is (571)270-1174. The examiner can normally be reached Monday through Friday 8:30 AM - 5:00 PM.
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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/RALPH A VERDERAMO III/Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
rv
October 7, 2026
