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 .
DETAILED ACTION
Claims 1-29 are pending.
Examiner Notes
Examiner cites particular paragraphs and/or columns and lines in the references as applied to Applicant’s claims for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. The prompt development of a clear issue requires that the replies of the Applicant meet the objections to and rejections of the claims. Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06.
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 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.
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/04/2026 has been entered.
Claim Objections
As per claim 9, ll. 1-2 should be amended to read: “A system comprising one or more processors and memory to store instructions that, as a result of execution by the one or more processors, cause the system to:”. Appropriate correction is required.
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, 9, 16, 22, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty et al. (US 2013/0076768) (hereinafter Chakraborty as previously cited) in view of Ooguni (US 2013/0257882) (as previously cited) in view of Stackhouse et al. (US 2004/0255295) (hereinafter Stackhouse).
As per claim 1, Chakraborty primarily teaches the invention as claimed including one or more processors (fig. 1, block 21) comprising: circuitry ([0031] specialized integrated circuits) to: receive, from a graphics processing unit (GPU) (fig. 5, blocks 112 and 510 and [0038] parent partition interacts with GPUs i.e., receive communication from a GPU and can include a virtual video memory controller that can request that hypervisor reserve an amount of memory for graphics processing for each child partition), a request to reserve an amount of GPU memory to be used by a thread group to be executed by the GPU ([0029] each child partition can manage and schedule threads thereon and [0038] request to reserve an amount of memory for graphics processing for each child partition each having threads).
Chakraborty does not explicitly teach in response to the requested amount of memory not exceeding one or more user-configured memory size limits, provide, to the GPU, an indication that the requested amount of GPU memory is reserved for the thread group to cause one or more threads of the thread group to be executed by the GPU to access GPU memory according to the one or more user-configured memory size limits on the amount of GPU memory to be used by the one or more threads of the thread group, wherein the one or more user-configured GPU memory size limits are enforced on one or more requests to reserve GPU memory made by the one or more threads of the thread group during execution by the GPU.
However, Ooguni teaches in response to the requested amount of memory not exceeding one or more memory size limits, provide, to the GPU, an indication that the requested amount of GPU memory is reserved for the thread group to cause one or more threads of the thread group to be executed by the GPU to access GPU memory according to the one or more memory size limits on the amount of GPU memory to be used by the one or more threads of the thread group (fig. 2B; [0062]; [0068] determine whether requested memory size to be reserved is less than or equal to a threshold value i.e., size limit and if yes then reserve the amount of memory requested, change the reserved memory region to used and hand-over the reserved memory to the requester i.e., indicating that the memory is reserved and [0048] and [0050] GPU uses the reserved memory and [0093] notifying the module, that is the source of the memory reserving request, of the start address of the reserved memory regions and [0117] resource managing section is notified of the start address of the memory region that was reserved).
Ooguni and Chakraborty are both concerned with memory management in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni because it would provide an advantage of identifying and using individual video settings for each child partition so that the video memory controller can request a different amount of memory to be reserved for each child partition. Another advantage is that the calculated amount of memory can be based on settings identified for that particular child partition. If appropriate video settings are set for each child partition, the video memory controller will be able to reserve sufficient memory for graphics processing for the one or more displays associated with each child partition while not reserving more significantly more memory than each child partition can use for graphics processing.
Chakraborty in view of Ooguni do not explicitly teach wherein the one or more user-configured GPU memory size limits are enforced on one or more requests to reserve GPU memory made by the one or more threads of the thread group during execution by the GPU.
However, Stackhouse teaches wherein the one or more user-configured GPU memory size limits (abstract the resources whose use is managed include memory resources and [0057] the setting of limits on resources other than CPU resources i.e., the memory resources may be accomplished via the same user interface used for setting CPU allocations, and such other limitations and allocations are preferably stored in the relevant nodes of the policy as with CPU limitations) are enforced on one or more requests to reserve GPU memory made by the one or more threads of the thread group ([0044] number of threads) during execution by the GPU ([0057] manage memory resources via APIs to constrain the working size set of a process i.e., to reserve a minimum amount of memory for a process and also to prohibit physical memory use by the process beyond a certain predetermined limit. Management of memory use may be beneficial, for example when CPU usage limitations are ineffective due to application memory consumption patterns. Memory management may be effected via establishment of an upper limit on the working set size for an application or process, with the limitation being enforced by appropriate kernel functions. Similarly, limitations on committed memory can be used to handle "leaky" applications that for whatever reason have trouble de-allocating memory or having memory de-allocated. Intervention may be provided for processes or applications that exceed memory limits, including displaying a warning and/or shutting down the offending application or process).
Stackhouse and Chakraborty are both concerned with memory management in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse because it would provide an appropriate API or otherwise to reserve a minimum amount of memory for a process and also to prohibit physical memory use by the process beyond a certain predetermined limit. Management of memory use may be beneficial, for example when CPU usage limitations are ineffective due to application memory consumption patterns. Memory management may be effected via establishment of an upper limit on the working set size for an application or process, with the limitation being enforced by appropriate kernel functions resulting in an improved memory resource management system.
As per claim 9, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 16, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 22, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 29, Stackhouse teaches wherein the one or more user-configured GPU memory size limits are enforced during execution by the GPU by providing an error indication and refraining from allocating or reserving additional GPU memory for the thread group when an additional request to allocate or reserve GPU memory would cause a total amount of GPU memory allocated or reserved for the thread group to exceed a maximum amount specified by the one or more user-configured GPU memory size limits ([0057] limitations on committed memory can be used to handle "leaky" applications that for whatever reason have trouble de-allocating memory or having memory de-allocated. Intervention may be provided for processes or applications that exceed memory limits, including displaying a warning and/or shutting down the offending application or process).
Claims 2, 12, 18, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Emaru et al. (US 2005/0034117) (hereinafter Emaru as previously cited)
As per claim 2, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach wherein the one or more user-configured GPU memory size limits are indicated, at least in part, using one or more environment variables set by a user.
However, Emaru teaches wherein the one or more user-configured GPU memory size limits are indicated, at least in part, using one or more environment variables set by a user ([0041] user sets parameter values associated with the environment).
Emaru and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Emaru because it would provide a way of accepting inputs of information of a developed software program and parameter values used by the software program at a time of setup and generating identification information and optimal parameter configuration information used for defining the parameter values, thereby generating a parameter configuration table having the software identification information and the parameter values as information accompanied with the software. This would reduce a burden of setup for the user and when setting up the system without requiring the user to understand characteristics specific to the software program.
As per claim 12, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
As per claim 18, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
As per claim 23, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Masters et al. (US 11,853,179) (hereinafter Masters as previously cited), in view of Park (US 2015/0074216) (as previously cited).
As per claim 3, the combination of references above teaches wherein a parallel processing library (Park fig. 3, block 120) comprises instructions that, if executed, cause one or more requests to allocate or reserve GPU memory to fail as a result of the one or more requests exceeding the one or more user-configured GPU memory size limits (Masters col. 3, ll. 40-44 when a device accesses memory space outside the area specified by the device driver, functional errors are likely to occur because this type of DMA access can create an error that ranges from simple data corruption to total system failure).
Masters and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Masters because it would provide a way for detecting a DMA memory address violation when testing PCIe devices by providing the ability to set memory address range access detection areas (memory fences/barriers) for the purpose of error detection or security in either a production or a test environment.
Park and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Masters in view of Park because it would provide a way for redistributing un-processed data from a lower performance computer to a higher performance computer based on determined respective data processing capabilities of the computers.
Claims 4, 8, 10, 14, 17, 26, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Leonard et al. (US 2004/0226017) (hereinafter Leonard as provided in the Notice of References Cited dated 03/29/2024).
As per claim 4, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach wherein one or more software kernels are to be executed by the GPU and one or more requests by the one or more software kernels to access the GPU memory are to succeed if the one or more requests cause the GPU to access the memory according to the one or more user-configured GPU memory size limits.
However, Leonard teaches wherein one or more software kernels are to be executed by the GPU and one or more requests by the one or more software kernels to access the GPU memory are to succeed if the one or more requests cause the GPU to access the memory according to the one or more user-configured GPU memory size limits ([0031] kernel determines whether granting the current memory allocation request would cause the maximum memory usage to be exceeded and if not, the kernel grants the memory allocation request, and allocates the requested memory).
Leonard and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Leonard because it would provide a way to specify that for a certain group of applications, a certain set of processors and a certain maximum amount of memory should be used. Similarly, for another set of applications, another set of processors and another maximum amount of memory may be specified. This ability to associate resources with entities enables a system administrator to better control how the resources of a system are used. This control may be used in many contexts to achieve a number of desirable results, for example, to prevent certain processes from consuming an inordinate amount of system resources, to enforce fairness in resource usage among various entities, to prioritize resource usage among different entities.
As per claim 8, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach wherein the one or more user-configured GPU memory size limits are at least one data value indicating a maximum amount of GPU memory to be usable by one or more kernels to be executed by the GPU.
However, Leonard teaches wherein the one or more user-configured GPU memory size limits are at least one data value indicating a maximum amount of GPU memory to be usable by one or more kernels to be performed by the GPU ([0031] kernel determines how much maximum memory usage has been specified in the resource pool. The kernel then determines whether granting the current memory allocation request would cause the maximum memory usage to be exceeded).
Leonard and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Leonard because it would provide a way of modifying the memory allocation to include increasing an amount of memory allocated to the kernel in response to the kernel requesting additional resources and decreasing the amount of memory allocated to the kernel in response to the kernel freeing resources that are no longer being used.
As per claim 10, it has similar limitations as claim 8 and is therefore rejected using the same rationale.
As per claim 14, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach wherein the instructions, as a result of execution by the one or more processors, further cause the system to restrict an amount of the GPU memory to be allocated to one or more software kernels performed executed by the GPU according to the one or more user-configured GPU memory size limits.
However, Leonard teaches wherein the instructions, as a result of execution by the one or more processors, further cause the system to restrict an amount of the GPU memory to be allocated to one or more software kernels performed executed by the GPU according to the one or more user-configured GPU memory size limits ([0031] if granting the request would cause the maximum memory usage to be exceeded, then the kernel will either: (1) deny the request; or (2) deallocate enough memory from one or more other processes to enable the memory request to be granted without exceeding the maximum memory usage, and then grant the request).
Leonard and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Leonard because it would provide a way to specify that for a certain group of applications, a certain set of processors and a certain maximum amount of memory should be used. Similarly, for another set of applications, another set of processors and another maximum amount of memory may be specified. This ability to associate resources with entities enables a system administrator to better control how the resources of a system are used. This control may be used in many contexts to achieve a number of desirable results, for example, to prevent certain processes from consuming an inordinate amount of system resources, to enforce fairness in resource usage among various entities, to prioritize resource usage among different entities.
As per claim 17, it has similar limitations as claim 8 and is therefore rejected using the same rationale.
As per claim 26, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
As per claim 28, it has similar limitations as claim 14 and is therefore rejected using the same rationale.
Claims 5, 15, 24, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Uemura et al. (US 6,182,194) (hereinafter Uemura as previously cited) in view of Park.
As per claim 5, the combination of references above teaches wherein the user-configured GPU memory size limits (Uemura col. 4, ll. 45-49 user selected memory area) are indicated to a parallel processing library (Park fig. 3, block 120) using one or more data values stored in another memory accessible by a central processing unit (CPU) (Uemura col. 1, ll. 61 to col. 2, ll. 5 cache memory is situated adjacent to the CPU and is different than the main memory).
Uemura and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Uemura because it would provide for a cache management table containing access information to the respective user memory areas for selectively performing access control to determine whether or not the individual user memory area is replaceable so that cache mistakes can be minimized. Since whether or not data is replaceable and invalidation of data can be set as required for every user memory area, it is possible to minimize cache mistakes, thus making the computer system quicker.
Park and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Uemura in view of Park because it would provide a way for redistributing un-processed data from a lower performance computer to a higher performance computer based on determined respective data processing capabilities of the computers.
As per claim 15, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
As per claim 24, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
As per claim 27, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
Claims 6, 11, 20, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Cheng (US 2018/0181519) (hereinafter Cheng).
As per claim 6, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach wherein the circuitry is to perform an application programming interface (API), the API managing access to the GPU memory in response to one or more data values indicating the one or more user-configured GPU memory size limits.
However, Cheng teaches wherein the circuitry is to perform an application programming interface (API), the API managing access to the GPU memory in response to one or more data values indicating the one or more user-configured GPU memory size limits ([0016] block access API is used by an application for accessing memory in various block sizes).
Cheng and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Cheng because it would provide a way to access data from block addressable I/O devices without having to go through system memory and a host processor. This provides increased GPU performance in terms of bandwidth savings due to bypassing host processor involvement and not having to perform a system memory copy. Moreover, the front end processor uses a cache to store the accessed blocks, therefore increasing speed and decreasing latency. This also increases available bandwidth and capacity by not having to transfer entire blocks upon subsequent accesses to the block.
As per claim 11, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
As per claim 20, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
As per claim 25, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
Claim 7 is are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Imbrogno et al. (US 2021/0097643) (hereinafter Imbrogno) in view of Silwa et al. (US 2017/0206175) (hereinafter Silwa as previously cited).
As per claim 7, the combination of references above teaches wherein the GPU is to access the GPU memory in response to an application programming interface (API) function (Imbrogno [0036] API commands are transmitted to the GPU to store rendered images in frame buffer), the API function preventing access to the GPU memory in excess of the one or more user-configured GPU memory size limits (Silwa [0170] API controls access to memory at selected specific ranges of memory).
Imbrogno and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Imbrogno because it would provide a way for transmitting API commands to a GPU to render graphic data and store rendered images in frame buffer. An image may be rendered by dividing the image into multiple sections of a grid where each section is known as a tile. Each tile may be rendered separately to video memory by the GPU. Rendering a single tile, rather than an entire frame at once, helps reduce the amount of memory and bandwidth needed for rendering. Shaders may be programmable as a part of a programmable GPU pipeline using shader functions to allow for increased flexibility and functionality of the shaders. Then, considering the amount of work required by each component, a power management unit may optimize power distribution to conserve most energy. In one example, when no workload is assigned to a GPU for execution or when the GPU is waiting idle for the next workload, the GPU may be placed in a sleep mode and may cause to be minimal, if any, power to be consumed by the GPU.
Silwa and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Imbrogno in view of Silwa because it would provide a way for a write operation to result in a monitor creating a page fault handler for writes to an allocated memory region so that if a rogue program attempts to write to the secure memory, then a page fault would occur, transitioning execution to the monitor. The monitor would then prevent access to the memory and take additional security measures. Using this type of API implementation can guarantee that the specified memory region is protected by encryption, and also provides security checks preventing rogue programs from storing data at secured memory locations. One or more applications can be specified as allowed to access the specific memory ranges, and can be tracked by the monitor.
Claim 13 is are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Kim et al. (US 2021/0382691) (hereinafter Kim as previously cited) in view of Silwa.
As per claim 13, the combination of references above teaches wherein the instructions, as a result of execution by the one or more processors, further cause the system to execute one or more software kernels using the GPU (Kim [0055] GPU applications consist of one or more kernels, which are executed by each of the GPU threads) where the one or more software kernels are to request access to the GPU memory using an application programming interface (API) (Kim [0107] the host transfers the data to the GPU memory during kernel initialization using customized memory management APIs), the API preventing the request if the request is in excess of the one or more user-configured GPU memory size limits (Silwa [0170] API controls access to memory at selected specific ranges of memory).
Kim and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Kim because it would provide for augmented logic in the on-chip memory controller to send invalidate signals to the on-chip caches and nullify dirty data to be modified. The invalidate signals are sufficient to prevent GPU cores from using stale data. As most GPU caches use a write-through policy, it is guaranteed that in-DRAM accelerators have access to the most up-to-date data.
Silwa and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Kim in view of Silwa because it would provide a way for a write operation to result in a monitor creating a page fault handler for writes to an allocated memory region so that if a rogue program attempts to write to the secure memory, then a page fault would occur, transitioning execution to the monitor. The monitor would then prevent access to the memory and take additional security measures. Using this type of API implementation can guarantee that the specified memory region is protected by encryption, and also provides security checks preventing rogue programs from storing data at secured memory locations. One or more applications can be specified as allowed to access the specific memory ranges, and can be tracked by the monitor.
Claim 19 is are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Sevenich et al. (US 2017/0168779) (hereinafter Sevenich as previously cited).
As per claim 19, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach instructions that, if performed by the one or more processors, cause the one or more processors to limit a total amount of GPU memory used by one or more threads of a software program to be executed, at least in part, by the GPU.
However, Sevenich teaches instructions that, if performed by the one or more processors, cause the one or more processors to limit a total amount of GPU memory used by one or more threads of a software program to be executed, at least in part, by the GPU ([0007] limiting the amount of memory that each thread uses).
Sevenich and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Sevenich because it would provide a way for improving performance of graph analytics by generating logic that tunes concurrency for available memory. Graph analysis logic is enhanced to decrease horizontal scaling to avoid memory exhaustion.
Claim 21 is are rejected under 35 U.S.C. 103 as being unpatentable over Chakraborty in view of Ooguni in view of Stackhouse in view of Kim.
As per claim 21, Chakraborty in view of Ooguni in view of Stackhouse do not explicitly teach an application programming interface (API), wherein the API allocates GPU memory to be used by one or more software kernels executed by the GPU according to the one or more user-configured GPU memory size limits.
However, Kim teaches an application programming interface (API), wherein the API allocates GPU memory to be used by one or more software kernels ([0109] API is used to copy the allocated data to consecutive physical pages before the kernel execution) executed by the GPU according to the one or more user-configured GPU memory size limits ([0055] GPU applications consist of one or more kernels, which are executed by each of the GPU threads.)
Kim and Chakraborty are both concerned with memory access in a computing environment and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty in view of Ooguni in view of Stackhouse in view of Kim because it would provide for augmented logic in the on-chip memory controller to send invalidate signals to the on-chip caches and nullify dirty data to be modified. The invalidate signals are sufficient to prevent GPU cores from using stale data. As most GPU caches use a write-through policy, it is guaranteed that in-DRAM accelerators have access to the most up-to-date data.
Response to Arguments
Applicant's arguments have been considered but are moot in view of the new grounds of rejection necessitated by Applicant’s amendments because the new grounds of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Tseng et al. (US 2019/0272611) in at least [0019] disclose a GPU issuing an access request to a memory controller and the memory controller either permitting or rejecting the request based on whether or not the request exceeds a maximum amount of memory granted to the GPU.
Kelly (US 2019/0325554) in at least [0025] discloses reserving memory capacity for graphics workloads.
Asai et al. (US 5,903,730) disclose visualizing results of performance monitoring and analysis in a parallel computing system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Adam Lee whose telephone number is (571) 270-3369. The examiner can normally be reached on M-TH 8AM-5PM.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, Pierre Vital, can be reached at the following telephone number: (571) 272-4215. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/Adam Lee/Primary Examiner, Art Unit 2198 March 13, 2026