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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 10-11, 13-14, 17-20, and 22 are objected to because of the following informalities:
Claim 10, line 7: Remove “same” before “execution data” as the identifier is not necessary when every other instance is “the execution data”.
Claim 13, line 1: Insert “the” before “identifying” to clearly connect the step to “identifying” in claim 10, line 6.
Claim 17, last line: Insert “requesting ones of the plurality of” before “shader engines” as there is a lack of basis since there are multiple “shader engines”
Claim 20: Delete the underline in line 2.
Claim 22, line 2: The element “the requesting execution” seems to be missing certain words and should be changed to read “the requesting ones of the plurality of execution units”.
Claims 11, 13-14, and 18-20 are objected to for inheriting the objection of the claims in which they depend on.
Examiner makes the following recommendations:
Claim 1, line 8: Examiner recommends to insert “receiving” between “the” and “memory” to add context to the “memory requests” element.
Claim 2, line 3: Examiner recommends to insert “receiving” between “the” and “memory” to add context to the “memory requests” element.
Claim 5, lines 2-3: Examiner recommends to insert “first” before both instances of “memory request” to add context to the “memory request” element.
Claim 15, line 9: Examiner recommends to insert “receiving” between “the” and “memory” to add context to the “memory requests” element.
Claim 17: Although not incorrect, the phrase “corresponding to same execution data” does not flow naturally. Examiner recommends that Applicant changes “same” to “identical” or some other term to improve the flow of the claim.
Note: If Applicant chooses to accept any of Examiner’s recommendations, potential antecedent basis issues should be kept in mind.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-11, 13-14 and 21-22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the execution data" in lines 11-12. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to the “respective execution data” in claim 1, line 4, or the “same execution data” in claim 1, line 10. For the sake of examination, Examiner will change the limitation in line 10 to be “the same first execution data” and the limitation in claim 1, line 11-12 to be “the first execution data”. For consistency, the limitation “the execution data” in claim 1, line 12 will be changed to “the first execution data”.
Claim 1 recites the limitation "the respective execution data" in line 13. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to the same “respective execution data” in claim 1, line 4, or the “execution data” as seen in claim 1, lines 10-12. For the sake of examination, Examiner will change the limitation in claim 1, line 13 to be “the first execution data”.
Claim 4 recites the limitation "the memory request" in line 1. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to the “representative memory request” in claim 1, line 4, or the “single representative memory request” in claim 1, line 11. For the sake of examination, Examiner will interpret this limitation to be “the single representative memory request” in claim 1, line 11.
Claim 10 recites the limitation “the identifiers” in line 7. There is insufficient antecedent basis for this limitation in the claim. Although “one or more parallel execution group identifiers” was established in line 6, there may be only one “parallel execution group identifier”. For the sake of examination, Examiner will interpret this limitation to be “the one or more parallel execution group identifiers”.
Claim 13 recites the limitation “the parallel execution group identifiers” in line 3. There is insufficient antecedent basis for this limitation in the claim. Although “one or more parallel execution group identifiers” was established in claim 10, line 6 , there may be only one “parallel execution group identifier”. For the sake of examination, Examiner will interpret this limitation to be “the one or more parallel execution group identifiers”.
Claim 14 recites the limitation “the same parallel execution group identifier of the first request” in lines 7-8. There is insufficient antecedent basis for this limitation in the claim. Although “one or more parallel execution group identifiers” was established in claim 10, line 6 , there may be more than one “parallel execution group identifier”. For the sake of examination, Examiner will interpret this limitation to be “the same one or more parallel execution group identifiers of the first request”.
Claim 14 recites the limitation “the parallel execution group identifier” in the last two lines. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to the “parallel execution group identifier” in claim 14, lines 6-7, or the “same parallel execution group identifier” in claim 14, lines 7-8. For the sake of examination, Examiner will interpret this limitation to be referring to the “parallel execution group identifier” in claim 14, lines 6-7.
Claim 22 recites the limitation "the execution data" in line 2. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to the “respective execution data” in claim 1, line 4, or the “same first execution data” in claim 1, line 10 (see 112(b) interpretation above). For the sake of examination, Examiner will interpret this limitation to be referring to the “same first execution data” in claim 1, line 10.
Claim 22 recites the limitation "the parallel execution group" in line 3. There is insufficient antecedent basis for this limitation in the claim. There was no prior recitation of “parallel execution group” within the claim or the claim it depends on. For the sake of examination, Examiner will interpret this limitation to be referring to the “parallel execution” in claim 1, line 3.
Claims 2-9, 11, 13-14, and 21-22 are rejected for inheriting the rejection of the claims in which they depend on.
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.
Claim(s) 1-5, 9-11, 13, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (“Future Scaling of Memory Hierarchy for Tensor Cores and Eliminating Redundant Shared Memory Traffic Using Inter-Warp Multicasting”, See IDS filed 10/8/24) in view of Gouldey et al. (US 20240020012 A1).
Regarding claim 1, Lee teaches a system comprising:
a processor comprising a plurality of execution units configured to perform respective portions of a parallel execution (Figs. 2 and 8a, Section 2.1 “NVIDIA GPU Architecture”: Figures show a streaming multi-processor with four sub-cores. Where each sub-core is capable of processing a warp, which allows for parallel execution. Sub-cores as execution units), wherein the execution units are each configured to request respective execution data via a respective memory request (Section 3.1 “Microarchitectural Details”: A sub-core may request a matrix by executing a load instruction (LDS). A matrix is defined as a rectangular array of numbers (see pertinent art section below). Matrix data as the execution data); and
a request aggregation circuit configured to combine received memory requests from the execution units (Fig. 8a and Section 3.1 “Microarchitectural Details”: The inter-warp multicasting unit (IWMU) unit receives memory requests from different sub-cores. The IWMU as the request circuit), by:
identifying, based on one or more parallel execution group identifiers included in the memory requests, a plurality of memory requests from different respective requesting ones of the plurality of execution units as corresponding to the same execution data (Fig. 8a and Section 3.1 “Microarchitectural Details”: The IWMU stores the warp ID, shared memory (SMEM) address, source register ID, and destination register ID. The IWMU also checks and identifies if the incoming request corresponds to a stored request with the same execution data by comparing the SMEM address, source register ID, and destination register ID, while verifying that the requests are not from the same warp ID. Since the warps are executing in parallel and warp IDs refer to one of the sub-cores executing one of the warps in parallel, the warp IDs are parallel execution group identifiers); and
providing the respective execution data to each of the requesting execution units (Fig. 8a and Section 3.1 “Microarchitectural Details”: IWMU multicasts execution data to the requesting sub-cores).
Lee does not teach that the request aggregation circuit is to send a single representative memory request for the execution data and to receive a single instance of the execution data.
Note that the MLDS instructions are implemented at compilation rather than dynamically inserted at runtime (see section 3.4 “Compilation”), therefore the compiler would insert these instructions under a set of “rules” to make sure that these instructions don’t hinder the performance of the processor. Additionally, Lee is silent on how the MLDS instruction loads data, whether it’s to fetch the data and wait for the second MLDS instruction to come through to multicast, or wait until the second MLDS instruction comes through and then fetches the data and multicasts.
Here, Gouldey teaches that a request aggregation circuit is to combine the received memory request from the execution units (Figs. 5-6, [0040]: When a memory request is received by the transaction bundler 508, the bundler follows the steps seen in Fig. 6 to potentially combine two memory requests. The transaction bundler as the request aggregation circuit) and that the request aggregation circuit is to send a single representative memory request for the execution data (Fig. 7 and [0050]:) and to receive a single instance of the execution data (Fig. 5 and [0041]: When a response to a memory request is received at 520, the data is processed through the FIFO buffer 522 or bypasses it if it’s a singular request, and returns it back to the processor at 528
It would have been obvious to one of ordinary skill in the art before the effective filing date to have modified the teachings of Lee with the teachings of Gouldey to have the request aggregation circuit combine memory requests into a single memory request and have the single memory request be sent to memory, then receive the data from memory to then be sent to the processor and its respective execution unit. Memory request aggregation is a popular method used by one of ordinary skill to prevent issues related to consistent memory requests to the same memory location, such as memory failures or to prevent redundant memory accesses, which causes bandwidth issues (See Lee Section 2.5 “Challenges and Opportunities for the Next Tensor Core Generations”). Therefore, aggregating memory requests from processors, such as the one seen in Lee, would be beneficial for the computing system as a whole.
Regarding claim 2, Lee, in view of Gouldey, teaches the system of claim 1, wherein identifying the plurality of memory requests comprises comparing parallel execution group identifiers of the memory requests to a stored set of parallel execution group identifiers maintained by the request aggregation circuit (Lee, Fig. 8a and Section 3.1 “Microarchitectural details”: An incoming memory request is compared to a memory request stored in the load request table, which also includes storing the warp IDs of each memory request. Therefore, when an incoming memory request comes in, the warp IDs stored in the load request table is compared to the warp ID of the incoming request for the plurality of incoming memory requests that may occur. The warp IDs stored in the load request table as the stored set of parallel execution group identifiers).
Regarding claim 3, Lee, in view of Gouldey, teaches the system of claim 2, wherein the stored set of parallel execution group identifiers comprises a plurality of logical identifiers that correspond to respective portions of the parallel execution (Lee, Figs. 7B and 8a, Section 3.1 “Microarchitectural Details”: The warp IDs stored in the inter-warp multicasting unit are logical identifiers due to the fact they refer to an executing warp (i.e., the logical component) rather than the sub-core (i.e., the physical component) executing the warp. Therefore, when a warp ID is referred to, it indirectly refers to a sub-core (Lee, see Fig. 7B)).
Regarding claim 4, Lee, in view of Gouldey, teaches the system of claim 1, wherein the memory request is a load multicast instruction (Lee, Section 3.1 “Microarchitectural Details”: The multicasting SMEM load instruction is used to make a memory request, whenever necessary to replace the SMEM load instruction).
Regarding claim 5, Lee, in view of Gouldey, teaches the system of claim 1, wherein identifying the plurality of memory requests comprises detecting, in a memory request, an indication that the memory request is part of a parallel execution group and dynamically adding a corresponding execution unit to the parallel execution group (Lee, Fig. 8a and Section 3.1 “Microarchitectural Details”; Gouldey, Figs. 5-6, [0040]: In the current combination, when an incoming memory request of a first warp indicates that it’s requesting the same execution data as another stored memory request of a second warp (indicating the first memory request is part of a group of sub-cores executing using the same data), the incoming memory request is merged with the other memory request and becomes associated with the second warp requesting the execution data (i.e., the requesting sub-core gets dynamically added with the stored request of one or more sub-cores to create/join a parallel execution group)).
Regarding claim 9, Lee, in view of Gouldey, teaches the system of claim 1, wherein the plurality of execution units are shader engines, compute units, single instruction multiple data (SIMD) units, or any combination thereof (Lee, Fig. 2 and Section 2.1 “NVIDIA GPU Architecture”: The sub-cores performs various types of operations; therefore the sub-cores are compute units).
Regarding claim 10, Lee, in view of Gouldey, teaches to receive a first request for execution data from a first execution unit of a plurality of execution units performing respective portions of a parallel execution (Lee, Fig. 8a: In an empty load request table, a first memory request gets sent to the IWMU and is stored in the load request table as there are no entries stored in the table) and to receive a second request for the execution data from a second execution unit of the plurality of execution units (Lee, Fig. 8a: A second memory request gets sent to the IWMU and is stored temporarily in the request queue).
The rest of the claim teaches a method similar to the system of claim 1, therefore the claim is rejected on the same premises.
Regarding claim 11, Lee, in view of Gouldey, teaches the method of claim 10.
Lee, in view of Gouldey, does not currently teach that the second request for the execution data is received subsequent to sending the representative request for the execution data.
Gouldey further teaches a timeout function, which prompts the scenario that the second request for the execution data is received subsequent to sending the representative request for the execution data (Fig. 7 and [0050]: See blocks 740-770. If a second request is received after the specified time period, the first memory request is sent as the representative request for the execution data whereas the second memory request stays back in the memory request queue).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have further combined the teachings of Lee with the teachings of Gouldey to have made the IWMU to process the load request without combining after a certain duration has passed, creating the scenario of a second request that is received subsequent to sending the representative request for the execution data. A benefit of having the timeout function would be to avoid a stall in the situation where a sub-core that is expected to send a memory request may have suffered a fault or is otherwise stalling, which one of ordinary skill would appreciate.
Regarding claim 13, Lee, in view of Gouldey, teaches the method of claim 12, wherein identifying comprises comparing the parallel execution group identifiers of the first request and the second request to a stored set of parallel execution group identifiers corresponding to portions of the parallel execution (Lee, Fig. 8a and Section 3.1 “Microarchitectural details”: The incoming memory requests are compared to one or more memory requests stored in the load request table, which also includes storing the warp IDs of each memory request. Therefore, when the incoming memory requests comes in, the warp IDs, SMEM addresses, source register IDs, and destination register IDs stored in the load request table are compared to the warp IDs, SMEM addresses, source register IDs, and destination register IDs of the incoming requests. The warp IDs stored in the load request table as the stored set of parallel execution group identifiers), wherein sending the representative request is performed in response to determining that the first request corresponds to a respective parallel execution group identifier of the stored set (Lee, Fig. 8a and Section 3.1 “Microarchitectural details”; Gouldey, Figs 5-7 and [0026]: In the current combination, when all conditions (i.e., same SMEM address, source register ID, and destination register ID, different warp ID) are met which indicates the memory requests refer to the same data in memory, the transaction bundler 508 combines the memory requests into one memory request (i.e., the representative request). The memory address associated to the sub-cores requesting the data from memory as the respective parallel execution group identifier).
Regarding claim 22, Lee, in view of Gouldey, teaches the system of claim 1, wherein the request aggregation circuit is further configured to wait to provide the execution data to the requesting execution until all expected memory requests of the parallel execution group have been received or until expiration of a timeout duration (Gouldey, Fig. 7 and [0050]: Before the timeout duration expires, the system identifies that the second memory request has not been received as it continues to wait until the second memory request is received or until the timeout duration expires).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (“Future Scaling of Memory Hierarchy for Tensor Cores and Eliminating Redundant Shared Memory Traffic Using Inter-Warp Multicasting”, See IDS filed 10/8/24) in view of Gouldey et al. (US 20240020012 A1) and Alsop et al. (US 20220414013 A1).
Regarding claim 6, Lee, in view of Gouldey, teaches the system of claim 1.
Lee, in view of Gouldey, does not teach a second request aggregation circuit configured to combine received memory requests from a second plurality of execution units, wherein the request aggregation circuit and the second request aggregation circuit are hierarchically arranged.
However, Alsop teaches multiple processors (Fig. 1 and [0028]: “the host device 130 may include multiple host execution engines including multiple different types of host execution engines. In various examples, a host execution engine 102 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific processor, a configurable processor, or other such compute engine capable of supporting multiple concurrent sequences of computation”) that are hierarchically arranged (Fig. 1: Each execution engine 102 are located on the “same level” of a computer hierarchy, therefore hierarchically arranged)
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Lee, in view of Gouldey, with the teachings of Alsop to have multiple processors, with multiple execution units and a second aggregation circuit as a result. Having multiple processors within a system would provide many benefits such as increased throughput and increased parallelism, which one of ordinary skill would appreciate. Additionally, duplication of parts, i.e., duplication of processors and circuits, and rearrangement of parts, i.e., arranging the processors in a hierarchy, are deemed routine expedients and not patentable distinctions (MPEP 2144.04(VI)(B) and MPEP 2144.04(VI)(C)).
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (“Future Scaling of Memory Hierarchy for Tensor Cores and Eliminating Redundant Shared Memory Traffic Using Inter-Warp Multicasting”, See IDS filed 10/8/24) in view of Gouldey et al. (US 20240020012 A1), Alsop et al. (US 20220414013 A1) and Benedict (US 20160077751 A1).
Regarding claim 7, Lee, in view of Gouldey and Alsop, teaches the system of claim 6.
Lee, in view of Gouldey and Alsop, does not teach a third request aggregation circuit configured to combine received memory requests from the request aggregation circuit and from the second request aggregation circuit and to generate a further aggregated memory request to a memory external to the processor.
However, Benedict teaches a memory controller that contains circuitry to combine memory requests to generate an aggregated memory request to a memory (Fig. 2 and [0026-0027]: Work flow 206 and work flow manager 208 as the request aggregation circuitry. Memory requests are aggregated into one request and processes a request to access memory 204) and Alsop teaches a memory controller connected to the host execution engines and to a memory external to the processor (Fig. 1: Memory controller 112, connected to cache 140, where each host execution engine 102 is connected to cache 140. The memory controller is also connected to system memory 120, located externally from the host execution engines).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Lee, in view of Gouldey, with the teachings of Benedict and further combine the teachings of Alsop to have the memory controller of the system to combine memory requests from the processor prior to sending the combined request to memory. Given the possibility that multiple execution units between multiple processors may request the same execution data, especially in parallel execution between processors, it would be just as beneficial to combine these requests into a singular request to reduce memory bandwidth (See Lee Section 2.5 “Challenges and Opportunities for the Next Tensor Core Generations”) or memory failures (see Benedict [0008]).
Regarding claim 8, Lee, in view of Gouldey, Alsop, and Benedict, teaches the system of claim 7, wherein the third request aggregation circuit is separate from the processor (Alsop, Fig. 1: Memory controller is separate from host execution engines 102).
Claims 15 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (“Future Scaling of Memory Hierarchy for Tensor Cores and Eliminating Redundant Shared Memory Traffic Using Inter-Warp Multicasting”, See IDS filed 10/8/24) in view of Gouldey et al. (US 20240020012 A1) and Kilgard (US 20210174550 A1).
Regarding claim 15, the claim recites a shader processing unit similar to the system of claim 1, therefore the claim is mostly rejected on the same premises.
Lee, in view of Gouldey, does not teach that the processing unit is a shader processing unit, or the execution units are shader engines.
Note that the architecture used in Lee is NVIDIA’s Volta GPU architecture (see Fig. 2).
Here, Kilgard teaches a GPU with a shader pipeline (Fig. 3 and [0048]: The GPU processes data through programmable shader GPU stages. GPUs, such as the Volta architecture, provide the programmable graphic pipeline).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Lee, in view of Gouldey, with the teachings of Kilgard to have made the GPU a shader processing unit, where each sub-core is a type of shader unit as a result, GPUs are known for image and video processing on a computer due to their high computational output with being able to process SIMD instructions. Therefore, one of ordinary skill would appreciate using GPUs as shader processing units to process complex operations to render images or objects.
Regarding claim 17, Lee, in view of Gouldey and Kilgard, teaches the shader processing unit of claim 16.
Lee, in view of Gouldey and Kilgard, does not teach that the request aggregation circuit is configured to wait until all requesting shader engines corresponding to the one or more parallel execution group identifiers request the same execution data or until a timeout duration expires before providing the separate instances of the execution data to the shader engines corresponding to the identified memory requests.
Gouldey teaches that teach that the request aggregation circuit is configured to wait until a timeout duration expires before providing the separate instances of the execution data to the shader engines corresponding to the identified memory requests (Figs. 5 and 7, [0050]: See blocks 740-770. When a memory request is received and a time period has passed for the request, the transaction bundler 508 is set to send the memory request to memory and receives a response to the memory request, bypasses the FIFO queue 522, and sends the data to the respective unit that made the request. The process is done for every memory request that comes through).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Lee, in view of Gouldey and Kilgard, with the teachings of Gouldey further to have made the IWMU to process the load request without combining after a certain duration has passed. A benefit of having the timeout function would be to avoid a stall in the situation where a sub-core that is expected to send a memory request may have suffered a fault or is otherwise stalling, which one of ordinary skill would appreciate.
Regarding claim 18, Lee, in view of Gouldey and Kilgard, teaches the shader processing unit of claim 17, wherein the request aggregation circuit is configured to identify shader engines corresponding to the one or more parallel execution group identifiers that do not request the execution data before the timeout duration expires (Gouldey, Fig. 7 and [0050]: Before the timeout duration expires, the system identifies that the second memory request has not been received as it continues to wait until the second memory request is received or until the timeout duration expires).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (“Future Scaling of Memory Hierarchy for Tensor Cores and Eliminating Redundant Shared Memory Traffic Using Inter-Warp Multicasting”, See IDS filed 10/8/24) in view of Gouldey et al. (US 20240020012 A1) and Yoo et al. (US 20170277571 A1).
Regarding claim 21, Lee, in view of Gouldey, teaches the system of claim 3.
Lee, in view of Gouldey does not teach that the logical identifiers are translated into physical identifiers associated with the execution units during execution of the parallel execution.
Yoo teaches to translate logical identifiers into physical identifiers (Fig. 3 and [0067]: A translation table 332 translates a logical ID into a physical ID, in which the physical ID corresponds to a permanent identification of a core).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Lee, in view of Gouldey, with the teachings of Yoo to have converted the logical identifiers of Lee into physical identifiers during the parallel execution. By translating the identifiers from logical to physical, one of ordinary skill would be able to identify the sub-core that’s performing the warp, which may help in instances such as identifying what sub-core is executing what warp for debugging/processor analysis purposes, which may be appreciated.
Allowable Subject Matter
Claims 14 and 19-20 are objected to as being dependent upon a rejected base claim, but would be allowable, over the prior art, if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The statement of reasons for the indication of allowable subject matter can be seen in the Non-Final Office Action mailed August 27, 2025.
Response to Arguments/Amendments
Applicants amendments, filed January 14, 2026, with respect to the claim objections have been addressed. Therefore, the objection of the claims have been withdrawn. However, new claim objection(s) have been raised.
Applicant amendments, filed January 14, 2026, with respect to the 112(b) rejections have been mostly addressed. Therefore, most of the rejections have been withdrawn. However, some 112(b) rejections on claim 1 and its dependent claims are maintained, which includes raising 112(b) rejections on claims 21-22. Additionally, new 112(b) rejections have been raised. See 112(b) rejections above.
Applicant's arguments on page 8 to page 12, filed January 14, 2026, with respect to the 103 rejections have been fully considered but they are not persuasive
.
Regarding arguments on page 8, last paragraph to page 9, first paragraph, Applicant argues that Lee does not teach the limitation “identifying, based on one or more parallel execution group identifiers included in the memory requests, …”.
Examiner respectfully disagrees with this argument. In Fig. 8(a) of Lee, the inter-warp multicasting unit can be seen storing warp IDs. A warp ID comes with the memory requests and corresponds to a requesting execution unit executing a warp. Furthermore, the identification of one or more execution units requesting the same execution data includes checking that the warp IDs of the memory requests are not the same, which would indicate that multiple execution units are requesting the same data, hence Lee satisfies this limitation. Therefore, Applicants arguments regarding that Lee does not teach the limitation is considered not persuasive.
Regarding arguments on page 10, second paragraph, Applicant argues that Lee, in view of Gouldey, does not teach the limitation “comparing parallel execution group identifiers of the memory requests to a stored set of parallel execution group identifiers…”.
Examiner respectfully disagrees with this argument. Examiner points to the load request table of the inter-warp multicasting unit of Lee as being able to store warp IDs. Therefore, when an incoming request arrives at the inter-warp multicasting unit, the incoming request warp ID is compared to the stored memory request warp IDs. See 103 mapping above for further details. Therefore, Applicants arguments regarding that Lee, in view of Gouldey, does not teach the limitation is considered not persuasive.
Regarding arguments on page 10, third paragraph to page 11, first paragraph, Applicant argues that Lee, in view of Gouldey, does not teach the limitation “wherein the stored set of parallel execution group identifiers comprises a plurality of logical identifiers that correspond to respective portions of the parallel execution”.
Examiner respectfully disagrees with this argument. Examiner notes that the warp IDs are logical identifiers since they refer to a warp/plurality of threads identifier rather than specify a physical unit, such as a sub-core (see Lee, Fig. 7B). Furthermore, the warp IDs indirectly refer to a sub-core performing the warp, therefore the warp IDs correspond to a respective sub-core. See 103 mapping above for further details. Therefore, Applicants arguments regarding that Lee, in view of Gouldey, does not teach the limitation is considered not persuasive.
Regarding arguments on page 9, paragraph 3, Applicant argues that Gouldey does not teach a request aggregation circuit because there is no mechanism for aggregating memory requests from different execution units.
Examiner respectfully disagrees with this argument. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Applicant cannot attack the secondary reference because it does not recite the elements that the primary reference covers. Lee was used to recite all elements and steps prior to the request aggregation part of the claim and Gouldey was used to perform the certain particulars of the memory aggregation part. Together, Lee and Gouldey create a system that receives memory requests from different execution units and merges those requests together to create a single memory request to be sent to memory. Therefore, Applicants arguments regarding that Gouldey does not teach the limitations is considered not persuasive.
Regarding arguments on page 11, fourth paragraph, Applicant argues that Kilgard does not teach a request aggregation circuit configured to receive memory requests from shader engines for the same execution data.
Examiner respectfully disagrees with this argument. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Applicant cannot attack the secondary reference because it does not recite the elements that the primary reference or other secondary reference(s) cover. Lee was used to recite all elements and steps prior to the request aggregation part of the claim and Gouldey was used to perform the certain particulars of the memory aggregation part. Together, Lee and Gouldey create a system that receives memory requests from different execution units and merges those requests together to create a single memory request to be sent to memory. Kilgard is then brought in to implement the system created on a GPU comprising of shader pipelines (in which, under BRI, are interpreted as the shader processing unit and shader engines, respectively). As a result, the combination of the prior art creates the shader processing unit of claim 15. Therefore, the arguments regarding that Kilgard does not teach the limitations is considered not persuasive.
The rejection of claims 1-11, 13, 15, and 17-18 under 103 will be maintained or rejected under 103 in view of newly found prior art. Claims 21-22 are rejected under 35 U.S.C. 103 in view of the current prior art used.
Conclusion
THIS ACTION IS MADE FINAL. 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 EMILIO ALCANTARA-RAMOS whose telephone number is (571)272-4211. The examiner can normally be reached Mon-Fri 8:30-5:00 PST.
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, Jyoti Mehta can be reached at (571)270-3995. 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.
/E.A./Examiner, Art Unit 2183
/JYOTI MEHTA/Supervisory Patent Examiner, Art Unit 2183
Prosecution Insights