DETAILED ACTION
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
This Office Action is sent in response to Applicant’s Communication received on 07/20/2026 for application number 18/667,614.
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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 6, 8-10, 15-17 and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gaster et al. (US 2011/0022817 A1).
Regarding claim 1, Gaster teaches one or more processors (Figure 1, GPU 102), comprising: circuitry to:
determine that one or more software programs are to share information between two or more threads using one or more portions of memory (“GPU local memory, such as, GPU local memory 114 and 115, is shared between the processing elements of a compute unit. Therefore, one GPU local memory is shared between all workitems of a workgroup.” Par 0072 and “The execution of GPU-kernels can be described with respect to GPU 102. A GPU-kernel generally executes as multiple threads in parallel. Each of these parallel threads is a “workitem.”” Par 0039) [GPU-kernels (software programs) use workitems (threads) to share data through local memory (portions)], wherein the two or more threads lack access to the one or more portions of memory until the two or more threads have been scheduled for execution (“In scheduling a processing logic and/or code segment to be executed on a selected GPU, a command including an executable code including the code segment (e.g., executable kernel object) can be scheduled to a command queue created in the context of the selected GPU. A “context,” … defines the execution environment for the GPU-kernel. The context can include handles and other information for devices, memory, and other program objects associated with the kernel … [and] can provide the executing kernel with the GPU device and memory locations it is permitted to use.” Par 0058 and “Step 311 can also include creating a context and a command queue for that GPU, creating memory objects associated with the context, compiling and creating GPU-kernel objects, issuing corresponding commands to the command queue to execute the GPU-kernel objects” par 0056 and paragraph 66, 73, Figure 3) [the threads lack access because memory permissions are given within a context established once the workgroup is scheduled and mapped to a core]; and
cause the one or more software programs to be modified to cause a first-to-begin thread of the two or more threads to initialize the one or more portions of memory to be used by the two or more threads to share the information (“the local memory area allocated in the memory and/or cache may require being flushed before being reused for each successive workgroup.” Par 0073 and “additional code is inserted in the entry, exit, and/or barrier routines of the GPU-kernels” par 0079 and “Scheduling another workgroup may include re-initializing the memory allocations for the currently executing OS thread on the current CPU core.” Par 0089) [the modification maps to the inserting instructions into the entry routine to ensure the shared memory is flushed/re-initialized when execution begins].
Claims 8 and 15 correspond to claim 1 and are rejected accordingly.
Regarding claim 2, Gaster teaches the one or more processors of claim 1, wherein the circuitry is to modify the one or more software programs at runtime of the one or more software programs (“In scheduling the GPU-kernel for execution on multi-core CPU 101, instructions to enforce the mappings and configurations determined in steps 313-325 can be inserted in the code to be executed” par 0078 and paragraph 79) [the kernel’s code is modified by inserting instructions at the time of execution].
Claims 9 and 16 correspond to claim 2 and are rejected accordingly.
Regarding claim 3, Gaster teaches the one or more processors of claim 1, wherein the modification comprises selecting one or more instructions with which to perform the initialization (“instructions to enforce the mappings and configurations determined in steps 313-325 can be inserted in the code to be executed” par 0078 and paragraph 79) [specific instructions are chosen to enforce memory configurations and inserting them into the code].
Claims 10 and 17 correspond to claim 3 and are rejected accordingly.
Regarding claim 6, Gaster teaches the one or more processors of claim 1, wherein the information is to be initialized on a reserved shared memory included in one or more GPUs (“GPU local memory, such as GPU local memories 114 and 115, are shared by workitems in a workgroup.” Par 0073 and “Scheduling another workgroup may include re-initializing the memory allocations for the currently executing OS thread” par 0089).
Claim 19 corresponds to claim 6 and is rejected accordingly.
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.
Claims 4, 5, 7, 11-14, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gaster in view of Levit-Gurevich (US 2023/0109752 A1).
Regarding claim 4, Gaster teaches the one or more processors of claim 1. However, Gaster does not explicitly teach wherein the one or more software programs comprise one or more GPU kernels, and the modification comprises inserting one or more instructions to be performed by the one or more GPU kernels to perform the initialization prior to each of one or more invocations of one or more APIs within the one or more software programs.
In the analogous art, Levit-Gurevich teaches wherein the one or more software programs comprise one or more GPU kernels (“As used herein, a GPU kernel refers to a kernel in binary format.” Par 0042), and the modification comprises inserting one or more instructions to be performed by the one or more GPU kernels to perform the initialization prior to each of one or more invocations of one or more APIs within the one or more software programs (“the profiling instructions 104A-104C are inserted at a first address (e.g., a first position) of a kernel (e.g., the beginning of the first kernel 106) to initialize variables used for profiling.” Par 0069 and “the trace emulator 430 can execute the first instrumentation routine 1302 prior to executing the emulation routine (EmulRoutines) and the second instrumentation routine 1304 after executing the emulation routine.” Par 0170 and paragraphs 99-102 and Figure 12) [this shows inserting instructions (which perform initialization) at beginning of kernel (prior to execution calls)].
It would have been obvious to a person having ordinary skill in the art, having the teachings of Gaster and Levit-Gurevich before him before the effective filing date of the claimed invention, to have modified Gaster to incorporate the teachings of Levit-Gurevich to insert instructions for the GPU kernels to perform before the API invocations to execute emulation routines to generate and provide data to a GPU profiling tool which can identify improvements to GPU/CPU operations. (Levit-Gurevich, paragraph 99)
Claims 11 and 18 correspond to claim 4 and are rejected accordingly.
Regarding claim 5, Gaster teaches the one or more processors of claim 1, However, Gaster does not explicitly teach wherein the one or more software programs comprise one or more GPU kernels, and the modification comprises inserting one or more instructions to be performed by the one or more GPU kernels after each of one or more invocations of one or more APIs within the one or more software programs.
In the analogous art, Levit-Gurevich teaches wherein the one or more software programs comprise one or more GPU kernels (“As used herein, a GPU kernel refers to a kernel in binary format.” Par 0042), and the modification comprises inserting one or more instructions to be performed by the one or more GPU kernels after each of one or more invocations of one or more APIs within the one or more software programs (“insert a second callback routine in the instrumented routine after the emulation routine, the second call-back routine to invoke the first API or a second API to provide the first GPU state to the application.” Par 0305 and “In some examples, in response to executing the second instrumentation routine 1304, the trace emulator 430 can invoke a callback routine (e.g., “CallbackAfter( )”) to invoke an API to provide GPU states of the hardware thread that executed the software thread to an upper level construct, such as the application 120 of FIG. 1 , the hardware profiling analysis tool 718 of FIG. 7 , etc.” par 0172).
It would have been obvious to a person having ordinary skill in the art, having the teachings of Gaster and Levit-Gurevich before him before the effective filing date of the claimed invention, to have modified Gaster to incorporate the teachings of Levit-Gurevich to insert instructions for the GPU kernels to perform after each of the API invocations to provide GPU states of the head thread prior to and after executing the emulation routine to determine changes in the GPU states and generate profiling data and determine appropriate improvements to be made. (Levit-Gurevich, paragraph 172)
Claim 12 corresponds to claim 5 and is rejected accordingly.
Regarding claim 7, Gaster teaches the one or more processors of claim 1. However, Gaster does not explicitly teach wherein the one or more software programs comprise one or more GPU kernels, and the modification comprises inserting one or more instructions to be performed by the first-to-begin thread of the one or more GPU kernels.
In the analogous art, Levit-Gurevich teaches wherein the one or more software programs comprise one or more GPU kernels (“As used herein, a GPU kernel refers to a kernel in binary format.” Par 0042), and the modification comprises inserting one or more instructions to be performed by the first-to-begin thread of the one or more GPU kernels (“the thread dispatcher 506 may load initial GPU state(s) into an idle one of the thread(s) 208 and start its execution based on the determination(s).” par 0120 and “Identified Events may include, but are not limited to: (a) Code dispatch” par 0224 and “the profiling instructions 104A-104C are inserted at a first address (e.g., a first position) of a kernel (e.g., the beginning of the first kernel 106)” par 0069 and “Specifically, a process is to save data before the first instruction (ADD) of the code (code dispatch point),” par 0239 and Figure 2) [the code dispatch point marks the start of kernel execution; instructions are inserted before kernel’s main execution by hardware thread (first-to-begin thread)].
It would have been obvious to a person having ordinary skill in the art, having the teachings of Gaster and Levit-Gurevich before him before the effective filing date of the claimed invention, to have modified Gaster to incorporate the teachings of Levit-Gurevich to insert instructions by the first-to-begin thread to allow for the execution environments to be initialized with initial data values and be ready for program execution.
Claims 14 and 20 correspond to claim 7 and are rejected accordingly.
Regarding claim 13, Gaster teaches the one or more processors of claim 8. However, Gaster does not explicitly teach wherein the information is to be initialized on a memory that is not accessible until performance of a GPU kernel thread of one or more software programs associated with the memory has started.
In the analogous art, Levit-Gurevich teaches wherein the information is to be initialized on a memory that is not accessible until performance of a GPU kernel thread of one or more software programs associated with the memory has started (“As used herein, a GPU state refers to one or more first values stored in a general-purpose register file (GRF) and/or one or more second values stored in an architecture register file (ARF) associated with a hardware thread of the GPU.” Par 0045 and “the thread dispatcher 506 may load initial GPU state(s) into an idle one of the thread(s) 208 and start its execution based on the determination(s).” par 0120 and Figure 5) [this shows initial GPU states, stored in thread specific registers, are only loaded into the thread and execution is started synchronously by the dispatcher, meaning those register contents only become relevant/accessible to the executing thread right at the beginning of its performance].
It would have been obvious to a person having ordinary skill in the art, having the teachings of Gaster and Levit-Gurevich before him before the effective filing date of the claimed invention, to have modified Gaster to incorporate the teachings of Levit-Gurevich to forestall access to the information to be initialized on a memory before the GPU kernel thread performance has started to prevent a program to access or alter memory areas, ensuring system stability and security.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 8 and 15 have been considered but are moot because the new ground 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.
No additional arguments were presented as to the remaining claims. As such, the rejection is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Hari et al. (US 2019/0102180 A1) teaches methods for software optimization to reduce overhead of intra-thread instruction duplication on a GPU. The method identifies duplication eligible original instructions, inserts duplicate instructions after original ones, creates a shadow register and verifies the integrity of source operands for the instructions using the shadow registers.
Hu et al. (US 2022/0004438 A1) teaches a processing unit generating different versions of a GPU based on allocated hardware resources from a global memory and fast shared resource.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYMAN FATIMA whose telephone number is (571)270-0830. The examiner can normally be reached M to Fri between 8am and 4pm EST.
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, Jaweed Abbaszadeh can be reached on (571)270-1640. 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.
/AYMAN FATIMA/Examiner, Art Unit 2176
/JAWEED A ABBASZADEH/Supervisory Patent Examiner, Art Unit 2176
