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 .
Claims 1-20 are currently pending for examination.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1, 2, 7, 8, 9, 14, 15, and 20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 , 6, 21 and 29 of co-pending Application No. 17/546,643 in view of Feehrer (US 20210133123 A1).
Although the claims at issue are not identical, they are not patentably distinct from each other because:
18742964
Claim 1:
the APU is to perform a runtime application program interface (API) to cause one or more memory locations to be asynchronously allocated
the API is to indicate: a location to return an asynchronously allocated memory; a size of memory requested; a stream to indicate a stream order
Claim 2:
the API is further to indicate one or more locations to return one or more asynchronously allocated memories.
Claim 7:
The system of claim 8, wherein the stream order is a stream order of operations that use the one or more memory locations.
Claim 8:
A system comprising… (same limitations as claim 1)
Claim 9:
The system of claim 8, wherein the API is further to indicate one or more locations to return one or more asynchronously allocated memories.
Claim 14:
The system of claim 8, wherein the stream order is a stream order of operations that use the one or more memory locations
Claim 15:
A method comprising… (same limitations as claim 1)
Claim 20:
The method of claim 15, wherein the stream order is a stream order of operations that use the one or more memory locations.
17546643
Claim 1:
One or more processors, comprising: circuitry to, in response to a call of an application programming interface ("API") to asynchronously allocate memory
Claim 6:
the API at least indicates a location used to return an asynchronously allocated memory address, a size of memory requested, and the order to be used by the one or more execution streams.
Claim 6:
the API at least indicates a location used to return an asynchronously allocated memory address
Claim 29:
an execution stream that indicates the order that uses the one or more memory locations
Claim 21:
A computer system… (see claim 1 rejection mapping)
Claim 6
The one or more processors of claim 1, wherein the API at least indicates a location used to return an asynchronously allocated memory address
Claim 17:
A computer system comprising one or more processors and memory storing executable instructions that, as a result of being executed by the one or more processors, cause the computer system to, in response to a call of an application programming interface ("API") to asynchronously allocate memory in an order to one or more execution streams
Claim 9:
A computer-implemented method comprising… (see claim 1 rejection mapping)
Claim 9:
computer-implemented method, comprising: in response to a call of an application programming interface ("API") to asynchronously allocate memory in an order to one or more execution streams
As per claims 1, 8, and 15, Application No. 17/546,6431 discloses:
the APU is to perform a runtime application program interface (API) to cause one or more memory locations to be asynchronously allocated (“One or more processors, comprising: circuitry to, in response to a call of an application programming interface ("API") to asynchronously allocate memory”, claim 1)
the API is to indicate: a location to return an asynchronously allocated memory; a size of memory requested; a stream to indicate a stream order (“the API at least indicates a location used to return an asynchronously allocated memory address, a size of memory requested, and the order to be used by the one or more execution streams.”, claim 6)
a memory pool from which to asynchronously allocate memory. (“the API indicates a memory pool usable to asynchronously allocate the one or more memory locations”, claim 21)
Application No. 17/546,6431 discloses the above limitations but does not explicitly disclose the APU and corresponding elements.
However, Feehrer discloses:
An acceleration processor unit (APU) comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); (“FIG. 2 shows an example implementation of the FIG. 1 system including 8 GPUs 102(0)-107(7). NVLINK™ switches 104 may be disposed on a GPU Baseboard and mid-plane in a multi-GPU system.“, 0065 ; see fig. 2- CPU (150) and GPUs 102(0)-102(7) ; “Explicitly, commands such as cudaMalloc( ) and a new CUDA driver API may thus be used to allocate/deallocate FAM as pinned memory.”, 0130)
an L2 cache; (“The first subset of SMs 440 processes vertex data to produce processed vertex data and writes the processed vertex data to the L2 cache 460 and/or the memory 304.”, 0172 )
one or more fabric interconnects; (“An example non-limiting system thus connects one or a set of “source GPUs” to one or a set of fabric attached memory modules (FAMMs) through an NVLINK™ interconnect fabric built with NVLINK™ switches.”, 0021)
a memory controller (“In some non-limiting embodiments, use of floor swept GPUs as FAM memory controllers (“FAM donors”) rather than industry-standard DIMMs with 3rd-party memory controllers.”, 0023)
one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface (“ The FAM SP CPU 154 may for example manage all of the FAMMs 106 on the baseboard through a link(s) such as PCIe.”, 0065)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Application No. 17/546,6431 with those of Feehrer in order to provide a FAM (fabric attached memory) which results in higher compatibility, reduction of dependency on 3rd-party form factors and standards, lower overall system cost, and allows for tighter integration of compute and memory system elements (Feehrer, [0023]).
As per claims 2 and 9, Application No. 17/546,6431 discloses:
the API is further to indicate one or more locations to return one or more asynchronously allocated memories. (“the API at least indicates a location used to return an asynchronously allocated memory address, a size of memory requested, and the order to be used by the one or more execution streams.”, claim 6)
As per claims 7, 14, and 20, Application No. 17/546,6431 discloses:
the stream order is a stream order of operations that use the one or more memory locations. (“an execution stream that indicates the order that uses the one or more memory locations”, claim 29)
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Feehrer (US 20210133123 A1) in view of Bernhard (US 20120179882 A1) in further view of Gurfinkel (US 20230005096 A1).
As per claim 1, Feehrer discloses:
An acceleration processor unit (APU) comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); (“FIG. 2 shows an example implementation of the FIG. 1 system including 8 GPUs 102(0)-107(7). NVLINK™ switches 104 may be disposed on a GPU Baseboard and mid-plane in a multi-GPU system.“, 0065 ; see fig. 2- CPU (150) and GPUs 102(0)-102(7) ; “Explicitly, commands such as cudaMalloc( ) and a new CUDA driver API may thus be used to allocate/deallocate FAM as pinned memory.”, 0130)
an L2 cache; (“The first subset of SMs 440 processes vertex data to produce processed vertex data and writes the processed vertex data to the L2 cache 460 and/or the memory 304.”, 0172 )
one or more fabric interconnects; (“An example non-limiting system thus connects one or a set of “source GPUs” to one or a set of fabric attached memory modules (FAMMs) through an NVLINK™ interconnect fabric built with NVLINK™ switches.”, 0021)
a memory controller (“In some non-limiting embodiments, use of floor swept GPUs as FAM memory controllers (“FAM donors”) rather than industry-standard DIMMs with 3rd-party memory controllers.”, 0023)
one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface (“ The FAM SP CPU 154 may for example manage all of the FAMMs 106 on the baseboard through a link(s) such as PCIe.”, 0065)
Feehrer discloses the above limitations of claim 1, but does not explicitly disclose that the memory allocation is performed asynchronously.
However, Bernhard discloses:
the APU is to perform a runtime application program interface (API) to cause one or more memory locations to be asynchronously allocated (“In one embodiment, a malloc manager can manage memory allocated via memory management libraries 303. Thus, API calls, e.g. for allocating/freeing memory pages, via common memory management libraries from each application (such as application 301 via memory management libraries 303) may be forwarded to the malloc manager which implements specific memory management capabilities for multiple applications. The malloc manager may communicate asynchronously with kernel 113 to request memory pages or release memory pages.”, 0049)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Feehrer and Bernhard, in order to provide the accelerator system of Feehrer with a mechanism for dynamically increasing the amount of available memory, thereby by improving the efficiency of the system (Bernhard, [0011]).
Feehrer in view of Bernhard discloses the above limitations of claim 1, but does not explicitly disclose the CUDA API indicating each of a location to return an asynchronously allocated memory, a size of memory requested, a stream to indicate a stream order, and a memory pool from which to asynchronously allocate memory.
However, Gurfinkel discloses:
in which the API is to indicate: a location to return an asynchronously allocated memory (Examiner Note: interpreted as indicating a location of memory to be deallocated- not further defined, see disclosure [0099]) (“In at least one embodiment, to release memory back to OS, an application needs to use one or more API functions such as a cudaDeviceGraphMemTrim API function. In at least one embodiment, cudaDeviceGraphMemTrim un-maps and releases any graph memory node's reserved physical memory that is safe to un-map.”, 0185 ; “In at least one embodiment, MemFree node, also referred to as a graph code node corresponding to a memory deallocation operation or a graph code node to deallocate or free memory, encodes information regarding memory deallocation such as properties of memory to be deallocated, size of memory to be deallocated, constraints on memory to be deallocated, address of memory to be deallocated, and/or any suitable information.“, 0159 ; see table-US-00016: “dptr” indicates an address of memory to free, and said API is denoted using any suitable notation)
a size of memory requested; (“In at least one embodiment, as an illustrative example, code utilizes API to generate one or more graph code nodes to allocate memory and includes a parameter value of a size of memory to be allocated, in which said system performs said API to generate one or more graph code nodes to allocate memory of said size of memory.”, 0151)
a stream to indicate a stream order; . (“In at least one embodiment, one or more systems capture stream ordered dependencies into said graph, in which ordering requirements of stream ordered allocation APIs guarantee that various graph memory nodes will be properly ordered with respect to captured stream operations.”, 0172)
a memory pool from which to asynchronously allocate memory (“In at least one embodiment, altering a peer accessibility of a stream ordered allocation pool after an API call such as a cudaMallocFromPoolAsync call is captured does not affect mappings that said graph will make for an allocation”, 0189 ; see Table-US-0003 : This dependency information is used when determining memory availability at node creation time. numDependencies A number of nodes in dependencies. params->poolProps Properties of a pool from which memory must be allocated.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Feehrer and Bernhard with those of Gurfinkel in order to provide the system with an improvement to memory allocation using a data structure representing operations and dependencies among the operations through the use of CUDA (Gurfinkel, [0003]).
As per claim 2, Feehrer in view of Bernhard in further view of Gurfinkel fully discloses the limitations of claim 1.
Furthermore, Gurfinkel discloses:
the API is further to indicate one or more locations to return one or more asynchronously allocated memories (Examiner Note: interpreted as indicating a location of memory to be deallocated- not further defined, see disclosure [0099]) (“In at least one embodiment, to release memory back to OS, an application needs to use one or more API functions such as a cudaDeviceGraphMemTrim API function. In at least one embodiment, cudaDeviceGraphMemTrim un-maps and releases any graph memory node's reserved physical memory that is safe to un-map.”, 0185 ; “In at least one embodiment, MemFree node, also referred to as a graph code node corresponding to a memory deallocation operation or a graph code node to deallocate or free memory, encodes information regarding memory deallocation such as properties of memory to be deallocated, size of memory to be deallocated, constraints on memory to be deallocated, address of memory to be deallocated, and/or any suitable information.“, 0159 ; see table-US-00016: “dptr” indicates an address of memory to free, and said API is denoted using any suitable notation)
As per claim 3, Feehrer in view of Bernhard in further view of Gurfinkel fully discloses the limitations of claim 1.
Furthermore, Gurfinkel discloses:
the API is to cause one or more virtual memory addresses to be associated with the one or more asynchronously allocated memory locations (“In at least one embodiment, one or more systems perform various operations and/or techniques described herein, and include systems such as drivers, programming model libraries, and/or variations thereof, which may be associated with one or more programming models such as CUDA, HIP, oneAPI, and/or variations thereof.”, 0054 ; “In at least one embodiment, said driver reuses memory by at least reusing memory within said graph based on virtual address assignment, reusing between graphs with virtual aliasing, in which different graphs can map same physical memory mapped to their virtual addresses, and/or variations thereof. In at least one embodiment, said driver assigns virtual addresses during allocation node creation, allowing them to be used in said graph.”, 0138)
As per claim 4, Feehrer in view of Bernhard in further view of Gurfinkel fully discloses the limitations of claim 1.
Furthermore, Gurfinkel discloses:
the API is a driver API (“In at least one embodiment, an API, such as those described herein, is a driver API or a runtime API. In at least one embodiment, a driver API is a low-level API, which can be referred to in reference to a programming model (e.g., CUDA driver API). In at least one embodiment, a driver API interacts directly with one or more devices. In at least one embodiment, a runtime API is a high-level API, which can be referred to in reference to a programming model (e.g., CUDA runtime API). In at least one embodiment, a runtime API operates utilizing a driver API. Further information regarding a driver API and a runtime API can be found in description of FIG. 31.”, 0167)
As per claim 5, Feehrer in view of Bernhard in further view of Gurfinkel fully discloses the limitations of claim 1.
Furthermore, Gurfinkel discloses:
the one or more CUs are to share the L2 cache (“In at least one embodiment, each core 1720(i), where i is an integer representing a particular instance of core 1720, may access L2 cache 1728(i) included in core 1720(i).“, 0251)
As per claim 6, Feehrer in view of Bernhard in further view of Gurfinkel fully discloses the limitations of claim 1.
Furthermore, Gurfinkel discloses:
the API is to cause the one or more memory locations to be asynchronously allocated from the memory pool (“In at least one embodiment, altering a peer accessibility of a stream ordered allocation pool after an API call such as a cudaMallocFromPoolAsync call is captured does not affect mappings that said graph will make for an allocation”, 0189 ; see Table-US-0003 : This dependency information is used when determining memory availability at node creation time. numDependencies A number of nodes in dependencies. params->poolProps Properties of a pool from which memory must be allocated.)
As per claim 7, Feehrer in view of Bernhard in further view of Gurfinkel fully discloses the limitations of claim 1.
Furthermore, Gurfinkel discloses:
the stream order is a stream order of operations that use the one or more memory locations (“In at least one embodiment, one or more systems, before executing said graph, back said graph's memory footprint with physical memory. In at least one embodiment, physical memory utilized for backings is owned by a launching stream. In at least one embodiment, one or more systems provide functionality for several graphs which are launched in a same stream (e.g., that have only internally-accessible memory allocations) to use a same physical memory, as execution of items in said stream are serialized.”, 0068)
As per claim 8, it is a system (A system comprising: memory; and an acceleration processor unit (APU) (Feehrer: “FIG. 6 shows one example FAM chassis to give customers running big-data multi-GPU-accelerated applications the option of a larger memory footprint. In this embodiment, a dedicated FAM baseboard (“tray”) is added on top of the GPU and CPU subsystems to create a memory-expanded system.”, 0112) claim with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
As per claim 9, it is a system claim with substantially the same limitations as claim 2, and as such, it is rejected for substantially the same reasons.
As per claim 10, it is a system claim with substantially the same limitations as claim 3, and as such, it is rejected for substantially the same reasons.
As per claim 11, it is a system claim with substantially the same limitations as claim 4, and as such, it is rejected for substantially the same reasons.
As per claim 12, it is a system claim with substantially the same limitations as claim 5, and as such, it is rejected for substantially the same reasons.
As per claim 13, it is a system claim with substantially the same limitations as claim 6, and as such, it is rejected for substantially the same reasons.
As per claim 14, it is a system claim with substantially the same limitations as claim 7, and as such, it is rejected for substantially the same reasons.
As per claim 15, it is a method claim with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
As per claim 16, it is a method claim with substantially the same limitations as claim 2, and as such, it is rejected for substantially the same reasons.
As per claim 17, it is a method claim with substantially the same limitations as claim 3, and as such, it is rejected for substantially the same reasons.
As per claim 18, it is a method claim with substantially the same limitations as claim 4, and as such, it is rejected for substantially the same reasons.
As per claim 19, it is a method claim with substantially the same limitations as claim 6, and as such, it is rejected for substantially the same reasons.
As per claim 20, it is a method claim with substantially the same limitations as claim 7, and as such, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Weber (US 20210240526 A1) – discloses a fully asynchronous execution queue for accelerator hardware wherein a malloc operation is replaced with an asynchronous malloc operation in an execution queue to be sent to an accelerator that returns a unique reference pointer. Execution of the asynchronous malloc operation in the execution queue by the accelerator allocates a requested memory size and adds an entry to a look-up table accessible by the accelerator that maps the reference pointer to a corresponding memory address
Stabrawa (US 20210240616 A1) – discloses a method for memory allocation which comprises selecting a type of memory to allocate in a client device from a group of memory types in response to a memory allocation request and/or in response to a request to access a portion of an address space, wherein the selection of the type of memory to allocate is based on an available memory determination
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights