DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Action is final and is in response to the claims filed 02/24/2026. Claims 1-32 are currently pending, of which claims 1-32 are currently rejected.
Response to Arguments
Applicant’s arguments filed on 02/24/2026 have been fully considered.
35 U.S.C. 101: Rejection under 35 U.S.C. 101 has been withdrawn necessitated by amendments.
35 U.S.C. 112(b): Rejection under 35 U.S.C. 112(b) has been withdrawn necessitated by amendments.
35 U.S.C. 102: Applicant’s arguments regarding the 102 rejection have been fully considered.
Applicant specifically argues in page 11 of 15 that “Kjolstad is silent regarding compiling instructions for accelerators, let alone compiling such instructions at runtime. Consequently, Kjolstad does not disclose each and every element of amended claim 1.”
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. See new grounds of rejection below necessitated by amendments.
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-6, 5-14, 16-22, 24-30, and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Fredrik Kjolstad in NPL: “The Tensor Algebra Compiler” (https://dl.acm.org/doi/pdf/10.1145/3133901), hereinafter “Kjolstad”, in view of Prasad A. Kulkarni in NPL: “JIT Compilation Policy for Modern Machines” (https://www.ittc.ku.edu/~kulkarni/CARS/papers/oopsla11.pdf), hereinafter “Kulkarni”, in view of Fredrik Berg Kjølstad in NPL: “Sparse Tensor Algebra Compilation” (https://tensor-compiler.org/files/kjolstad-phd-thesis-taco-compiler.pdf), hereinafter “Berg”.
Regarding Claim 1, Kjolstad teaches:
One or more processors, comprising: circuitry to use an instruction to indicate one or more non-zero values within one or more matrices of data, … (Page 77:17 Second paragraph, e.g., Compiler runs in Processor and memory (circuitry); Page 77:15, Sparse storing technique, e.g., Taco (Tensor Algebra Compiler) performs the operations of storing indices of non-zero values from a dimension (one or more matrices of data) in array idx;).
Kjolstad does not teach:
… wherein the instruction is to be compiled at runtime to be used by one or more accelerators.
However, in the same field of endeavor, Kulkarni teaches using JIT compilation for applications written in managed languages, such as Java and C#. Kulkarni explains “interpreted execution is inherently slow, which makes dynamic or Just-in-Time (JIT) compilation essential to achieve efficient runtime performance for such applications” (Kulkarni: First page, 1. Introduction, First paragraph). Additionally, Kjolstad discloses in Page 77:26, “Runtime Support”, how future work involves taking advantage of JIT compilation to support properties available only at runtime.
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine the JIT compilation for compiling applications as taught by Kulkarni with the tensor algebra compiler as taught by Kjolstad. One would have been motivated to combine these references because both references disclose JIT compilation, and Kulkarni enhances the model of Kjolstad because “Just-in-Time (JIT) compilation essential to achieve efficient runtime performance for such applications.” (Kulkarni: First page, 1. Introduction, First paragraph).
Kjolstad in view of Kulkarni do not teach:
… to be used by one or more accelerators.
However, in the same field of endeavor, Berg teaches performing sparse matrix multiplication using a the Tensor Algebra Compiler in a GPU accelerator. Berg explains “And Section 7.5 shows how they let us generate efficient sparse code for GPU accelerators and mixed sparse-dense operations that require tiling.”. See Berg: Pages 92-93, Section 6.7 Conclusion. In addition, Kjolstad discloses that their future work includes removing restrictions and adapting code generation to targe accelerators (e.g., GPUs and TPUs). See Kjolstad: Page 77:26 first paragraph.
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to modify the Tensor Algebra Compiler as taught by Kjolstad in view of Kulkarni to perform sparse matrix multiplication in a GPU accelerator as taught by Berg. One would have been motivated to combine these references because both references disclose the Tensor Algebra Compiler used for sparse matrix multiplication, and Berg enhances the model of Kjolstad in view of Kulkarni by allowing for the Tensor Algebra Compiler to "compile any sparse tensor algebra expression to CPU and GPU code that matches the performance of hand-optimized implementations" (Berg: Abstract).
Regarding Claim 2, Kjolstad in view of Kulkarni in view of Berg teach:
The one or more processors of claim 1, wherein the circuitry is to indicate the one or more non-zero values by at least causing the one or more processors to store index values corresponding to the one or more non-zero values in a memory (Kjolstad: Page 77:17 Second paragraph, e.g., Compiler runs in Processor and memory (one or more circuits); Page 77:15, Sparse storing technique, e.g., Taco (Tensor Algebra Compiler) performs the operations of storing indices of non-zero values in array idx)
Berg further teaches:
accessible to one or more graphics processing cores (Berg: Page 104, “Sparse Matrix-Vector Multiplication (SpMV)”, e.g., sparse matrix-vector multiplication (SPMV) is performed in a GPU (including gpu cores)).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to modify the Tensor Algebra Compiler as taught by Kjolstad in view of Kulkarni in view of Berg to perform sparse matrix multiplication in a GPU as taught by Berg. One would have been motivated to combine these references because both references disclose the Tensor Algebra Compiler used for sparse matrix multiplication, and Berg enhances the model of Kjolstad in view of Kulkarni in view of Berg by allowing for the Tensor Algebra Compiler to "compile any sparse tensor algebra expression to CPU and GPU code that matches the performance of hand-optimized implementations" (Berg: Abstract). This modification would cause for the GPU as taught by Berg to compute sparse matrix multiplication in its cores. Hence, Kjolstad in view of Kulkarni in view of Berg teach Claim 2 in its entirety.
Regarding Claim 3, Kjolstad in view of Kulkarni in view of Berg teach:
The one or more processors of claim 1, wherein the instruction is to cause the one or more processors to store indices of the one or more non-zero values in memory (Kjolstad: Page 77:17 Second paragraph, e.g., Compiler runs in Processor and memory (one or more processors); Page 77:15, Sparse storing technique, e.g., Taco (Tensor Algebra Compiler) executes storing instructions to store indices of non-zero values in array idx) that is accessible to one or more threads when executing one or more sparse matrix multiplication operations in parallel (Kjolstad: Page 77:17, Section 8.2 Sparse Matrix-Vector Multiplication, e.g., Sparse matrix multiplication is performed in threads; Page 77:18, Top paragraph, e.g., Sparse matrix multiplication operations can be performed in parallel).
Regarding Claim 4, Kjolstad in view of Kulkarni in view of Berg teach:
The one or more processors of claim 1, wherein the instruction indicates the one or more non-zero values corresponding to a sparse matrix multiplication (Kjolstad: Page 77:3, Fig. 3, e.g., shows an example of a sparse matrix multiplication instruction set using Tensor Algebra Compiler); and wherein the circuitry is to execute a compiler at a runtime to generate executable instructions for execution by the one or more accelerators (Kjolstad: Page 77:15, Sparse storing technique, e.g., Taco (Tensor Algebra Compiler) performs the operations of storing indices of non-zero values (by generating executable instructions); Kulkarni: First page, 1. Introduction, e.g., JIT compilation performs compilation at runtime; Berg: Pages 92-93, Section 6.7 Conclusion, e.g., sparse code is generated for GPU accelerators).
The motivation to combine provided with respect to claim 1 applies equally to claim 4.
Regarding Claim 5, Kjolstad in view of Kulkarni in view of Berg teach:
The one or more processors of claim 1, wherein the instruction is to cause a compiler to receive one or more first instructions with sparsity information of the one or more matrices of data (Page 77:15, Sparse storing technique, e.g., Taco (Tensor Algebra Compiler) executes storing instructions to store indices of non-zero values in array idx; Page 77:3, Fig. 2, e.g., shows array idx storing indices of non-zero elements (first instruction) for tensor B (one or more matrices)) and compile the one or more first instructions to generate one or more second instructions that are executable by a graphics processing unit (GPU) to perform a matrix multiplication operation with the sparsity information (Berg: Page 104 Sparse Matrix-Vector Multiplication (SpMV), e.g., Tensor Algebra Compiler generates kernel (second instruction) for Sparse matrix-vector multiplication in a GPU).
The motivation to combine provided with respect to claim 2 applies equally to claim 5.
Regarding Claim 6, Kjolstad in view of Kulkarni in view of Berg teach:
The one or more processors of claim 1, wherein the instruction includes a half-precision matrix multiply and accumulate (HMMA) operation, integer matrix multiplication and accumulate (IMMA) operation, single-precision matrix multiplication operation, or a floating point multiplication and accumulate operation (Kjolstad: Page 77:15, Fig. 12, e.g., shows matrices being a “double” data type (float). Line 20 performs matrix multiplication).
Regarding Claim 8, Kjolstad in view of Kulkarni in view of Berg teach:
The one or more processors of claim 1, wherein to indicate the one or more non-zero values within the one or more matrices of data includes to cause the circuitry to perform a compiler to generate an operand (Kjolstad: Page 77:3, fourth paragraph, e.g., Only values that are in matching non-zero locations (operands) of matrices B and C are computed) that is to be used by one or more graphics processing cores to perform one or more matrix multiplication operations (Kjolstad: Page 77:3, Fig. 3, e.g., shows Tensor Algebra Compiler performing matrix multiplication; Berg: Page 104, “Sparse Matrix-Vector Multiplication (SpMV)”, e.g., sparse matrix-vector multiplication (SPMV) is performed in a GPU (including gpu cores)), and wherein the operand includes index information of the one or more non-zero values (Kjolstad: Page 77:15, Sparse storing technique, e.g., Taco (Tensor Algebra Compiler) performs the operations of storing indices of non-zero values in array idx).
With regards to Claims 9-14 and 16, they are directed to instructions stored in a memory to be executed by the claimed processor above (claims 1-6 and 8 respectively), wherein all claim limitations also have been addressed and/or covered in cited areas. Thus, accordingly, these claims are rejected for at least the same reasons therein.
Regarding Claims 17-22 and 24, they are media claims practiced by the apparatus of claims 1-6 and 8 respectively. They are rejected for the same reasons as claims 1-6 and 8.
Regarding Claims 25-30 and 32, they are method claims practiced by the apparatus of claims 1-6 and 8 respectively. They are rejected for the same reasons as claims 1-6 and 8.
Claims 7, 15, 23, and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Kjolstad in view of Kulkarni in view of Berg, further in view of Liao (U.S. Patent Application Publication No.: US 20160299874 A1), hereinafter “Liao”.
Regarding Claim 7, Kjolstad in view of Kulkarni in view of Berg teach the one or more processors of Claim 1. Kjolstad in view of Kulkarni in view of Berg do not teach:
wherein to perform the operation is to cause a compiler to modify a Directed Acyclic Graph (DAG) interface to receive one or more instructions with sparsity information of the one or more matrices of data.
However, in the same field of endeavor, Liao teaches how a Directed Acyclic Graph (DAG) can be used for matrix multiplication in software. Liao explains “A PLASMA implementation itself relies on runtime scheduling of parallel subtasks (i.e., functions such as matrix multiplications). However, some subtasks depend on others, and the relationships between the subtasks can be complex. The relationships may be expressed through a task graph, typically shown as a directed acyclic graph (DAG), which can be explored at runtime”. See Liao: ¶0100.
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine the Directed Acyclic Graph in software for matrix multiplications as taught by Liao with the Tensor Algebra Compiler for computing sparse matrix multiplication as taught by Kjolstad in view of Kulkarni in view of Berg. One would have been motivated to combine these references because both references disclose matrix multiplication in software, and Liao enhances the model of Kjolstad in view of Kulkarni in view of Berg by improving load balancing. See Liao: ¶0013.
With regards to Claim 15, it is directed to instructions stored in a memory to be executed by the claimed processor above (claim 7), wherein all claim limitations also have been addressed and/or covered in cited areas. Thus, accordingly, this claim is rejected for at least the same reasons therein.
Regarding Claim 23, it is a media claim practiced by the apparatus of claim 7. It is rejected for the same reasons as claim 7.
Regarding Claim 31, it is a method claim practiced by the apparatus of claims 7. It is rejected for the same reasons as claim 7.
Prior Art Made of Record
US 12499175 B2 – mentions NVIDIA Corp offering the latest graphics processing unit (GPU) having a built-in tensor core that processes matrix multiplication. See Column 1 Lines 26-33.
US 12613697 B2 – teaches performing sparse matrix multiplication based on a directed acyclic graph. See Column 6 Lines 36-64.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS H DE LA GARZA whose telephone number is (571)272-0474. The examiner can normally be reached Monday-Friday 9:30AM-6PM.
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, Andrew Caldwell can be reached at (571) 272-3702. 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.
/C.H.D./
Carlos H. De La GarzaExaminer, Art Unit 2182 (571)272-0474
/EMILY E LAROCQUE/Primary Examiner, Art Unit 2182
Prosecution Insights