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 .
Continued Examination Under 37 CFR 1.114
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 November 20, 2025 has been entered.
Claims 1-20 are pending in this case. Claims 1-15 and 17-19 have been newly amended. No claims have been newly added or cancelled. This action is made Non-Final.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on July 14, 2025 and November 21, 2025 were filed after the mailing date of the Non-Final Office Action mailed on October 23, 2024 and Final Office Action on July 15, 2025, respectively. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Objections
Claim 13 is objected to because of the following informalities:
Claim 13 recites, “…wherein in response to the API calls, cause a particular hardware unit is to be used…” but should recite, “…wherein in response to the API calls, cause a particular hardware unit to be used…”
Appropriate correction is required.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Benfield et al. (US 12,175,222) in view of Liu et al. (US 2021/0117806).
As to claim 1, Benfield et al. disclose one or more processors (Figure 3, host system 300, with processor 302 and/or acceleration engine 312), comprising: circuitry (e.g. Figure 3, column 9, lines 3-18 notes processor 302 is an integrated circuit that executes program code, in the form of instructions, from processor memory 304, e.g. including executing driver 322 and compiler 330; Figure 4 further illustrates circuitry of acceleration engine 312 as accelerator 402) to: in response to receiving an application programming interface (API) (e.g. column 11, lines 38-62 notes driver can provide an application program interface (API) that defines functions for feeding input data to the acceleration engine 312 and defines the operation(s) to perform on the input data, driver can further load or cause the acceleration engine 312 to load input data on which the neural network is to operate, and/or can cause the acceleration engine 312 to being executing on the input data) that indicates a first tensor (e.g. Figures 6A, 6B, 7, 8A, 8B, 9A, 9B, 9C, 10A, and 10B, input tensor(s) 810/840/910/1010/1030 (corresponding to respective Figures)) and tensor map (e.g. tensor operations as tensor indexing, e.g. tensor mapping, where Figure 11 notes process of performing tensor indexing using matrix multiplications and/or matrices transposes, further described below), cause the first tensor (e.g. the input tensor) to be translated into a second tensor (e.g. to be transformed, e.g. “translated,” into an output tensor (corresponding to Figures noted above)) according to the tensor map (e.g. according to the tensor indexing/mapping, e.g. matrix multiplications and/or matrices transposes), wherein, the tensor map indicates a transformation of the first tensor to the second tensor (e.g. the tensor indexing indicates a transformation of the input tensor to the output tensor), wherein the first tensor and the second tensor have different tensor layouts (e.g. the input tensor and output tensor have different tensor “layouts” as illustrated in Figures noted above)(Figure 6A, column 16, lines 22-28 notes tensor indexing, including mapping elements of the input tensor to the output tensor; Figure 6B, column 16, lines 29-52 notes tensor indexing of Figure 6A; Figure 7, column 16, lines 53 thru column 17, lines 61 notes using a pair of matrix multiplications to index a two-dimensional tensor; Figure 8A, column 17, lines 62 thru column 18, lines 51 notes tensor indexing using matrix multiplications, e.g. transforming input tensor 810 to output tensor 820 by mapping elements of input tensor 810 to elements of output tensor 820, e.g. performing a matrix transpose operation; Figure 8B, column 18, lines 52 thru column 19, lines 27 notes executing a gather operator using matrix multiplications, e.g. transforming input tensor 840 to output tensor 850 via a gather operation that maps rows of input tensor 840 to rows of output tensor 850; Figure 9A, 9B, 9C, column 19, lines 28 thru column 20, lines 16 further notes mapping of an input tensor 910 to an output tensor 920; Figure 10A, column 20, lines 17-36 notes mapping an input tensor 1010 to an output tensor 1020 using matrix multiplications, e.g. mapping elements in columns of input tensor 1010 to elements in columns of output tensor 1020; Figure 10B, column 20, lines 37-53 notes mapping an input tensor 1030 to an output tensor 1040 using a matrix transpose, e.g. mapping elements in columns of input tensor 1030 to elements in rows of output tensor 1040).
As noted above, Benfield et al. describes its driver provides an application program interface (API) that defines functions for feeding input data (e.g. input tensors) to the acceleration engine 312 and defines the operation to perform on the input data (e.g. tensor operations as tensor indexing using matrix multiplications and/or matrices transposes on tensors). Therefore, it is considered the API function indicates the tensor and operations, e.g. tensor indexing/mapping, to perform on the tensor as claimed. However, Benfield et al. do not explicitly described the API functions as an API “call.”
Liu et al. further disclose in response to receiving an application programming interface (API) call (e.g. receiving an API call, where [0026] notes operations performed (described below) in response to an invocation such as an API call, and [0093] notes the operations are API functions that can be called by software, thus API calls) that indicates a first tensor and a tensor map (e.g. indicates a first generic tensor raw data and generic tensor descriptors), cause the first tensor to be translated into a second tensor according to the tensor map (e.g. causing operations to be performed as noted below according to the operations (e.g. transformations) and layout (memory layout) indicated by the generic tensor descriptors as noted below, where upon performing the operations as described below on generic tensor raw data, considered a “first tensor,” may generate new or modified generic tensor raw data, considered a “second tensor”), wherein the tensor map indicates a transformation of the first tensor to the second tensor (e.g. the generic tensor descriptors indicate operations (e.g. transformations) and layouts of tensors in memory), wherein the first tensor and the second tensor have different tensor layouts (e.g. tensors have different layouts in memory)([0028] and [0029] notes data stored in memory in a particular format, e.g. memory layout, where [0030] notes generic tensor descriptor indicates the manner in which a multi-index maps to generic tensor raw data as stored in memory, the generic tensor descriptor facilitates proper mapping of elements of a multi-index to elements of generic tensor raw data, where [0088] and [0089] further notes performing operations on the generic tensor raw data, e.g. slice copy, general matrix multiply (“GEMM”) or batched GEMM on 2D or 3D generic tensors, reduction of an n-dimensional generic tensors, and algorithm transformations of an n-dimensional generic tensor, where [0089] notes the sliced copy create new generic tensor raw data or modify existing generic tensor raw data, [0090] notes the GEMM operation and batched GEMM operations generate new generic tensor raw data, [0091] notes the generic tensor reduction operation reduces multiple input generic tensors to a single output generic tensor, thus these operations may be considered to transform first tensor to second, different tensor, where [0092] further notes storing resulting tensors into any memory).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Benfield et al.’s system and method of transforming tensors in response to API calls as described by Liu et al. as the API is known for defining functions that allows operations to be performed within the system as described Benfield et al., where the API calls acts as the communication between software systems, thus yielding predictable results, without changing the scope of the invention.
As to claim 2, Benfield et al. in view of Liu et al. disclose the circuitry is to in response to the API call (Benfield, modified with Liu, e.g. in response to API call as noted in claim 1), asynchronously store the second tensor (Benfield, e.g. “asynchronously” store the output tensor, where Figure 4, column 12, lines 9-15 notes memory subsystem 404 may include multiple memory banks 414, where each bank 414 can be independently accessible, meaning the read of one memory bank is not dependent on the read of another memory bank, similarly, writing to one memory bank does not affect or limit writing to a different memory bank, where column 12, lines 42-43 notes the memory subsystem 404 may be configured such that a single memory may be able to service only one read or write at a time, where column 12, lines 60-63 further notes output from the processing element array 410 can be written into the memory banks 414 that can then subsequently provide input data for the processing element array 410, and column 22, lines 46-58 notes operations, e.g. a matrix multiplication or matrix transpose, may be performed by storing rows of an input matrix into rows of a first memory array in a local memory, sequentially reading columns of the first memory array and writing data read from the columns of the first memory array into rows of a second memory array for storing the output matrix (transposed matrix), where terms “subsequently” and “sequentially” denote “asynchronously”).
As to claim 3, Benfield et al. in view of Liu et al. disclose the circuitry is to in response to the API call (Benfield, modified with Liu, e.g. in response to API call as noted in claim 1), asynchronously store the second tensor in a memory of a graphics processing unit (GPU) (Benfield, e.g. “asynchronously” store the output tensor in memory subsystem 404 of accelerator 402, as noted in claim 2, where accelerator 402 may be similar to acceleration engine 312, where column 9, lines 51-54 notes acceleration engine 312 may be a graphics processing unit (GPU), and may be optimized to perform the computations needed for graphics rendering).
As to claim 4, Benfield et al. in view of Liu et al. disclose the first tensor is to be stored in a first memory of a graphics processing unit (GPU) (Benfield, e.g. the input tensor, e.g. as input data, stored in a first memory bank 414 of memory subsystem 404 of accelerator 402, where column 15, lines 10-12 notes input data 450 can be stored in a memory bank 414 when the accelerator 402 receives the input data), and the circuitry is to in response to the API call (e.g. Benfield, modified with Liu, e.g. in response to API call noted in claim 1), asynchronously translate the first tensor into the second tensor and store the second tensor in a second memory of the GPU (Benfield, e.g. “asynchronously” translate the input tensor into the output tensor, as noted in claim 1, and store in a second memory bank 414 of memory subsystem 404 of accelerator 402, as noted in claim 2)(Benfield, e.g. as noted in claim 2, column 12, lines 60-63 notes output from the processing element array 410 can be written into the memory banks 414 that can then subsequently provide input data for the processing element array 410).
As to claim 5, Benfield et al. in view of Liu et al. disclose in response to the API call (Benfield, modified with Liu, e.g. in response to API call as noted in claim 1), use automatic transaction accounting (Benfield, e.g. via one or more DMA engines using DMA descriptors)(Benfield, e.g. column 10, lines 51-55 notes direct memory access (DMA) descriptors for moving data into or out of the acceleration engine 312, where column 24, lines 50-59 notes DMA engine may enqueue DMA descriptors, which may identify an address for a block of data and an operation (e.g. a read or write) to perform, a descriptor can direct a DMA engine to instruct a DMA controller to read or write data to and/or from the acceleration engine, where it is considered the DMA engine “accounts” for each read and write operation performed by the acceleration engine using the DMA descriptors, thus considered to use “automatic transaction accounting”).
As to claim 6, Benfield et al. in view of Liu et al. disclose the API call is to receive as input (Benfield, e.g. as compiled code 344 from compiler 330 by driver 322) an indication of a location in which the tensor map is stored (Benfield, e.g. an indication of a location in which the tensor indexing/mapping operations, as compiled code 344, are stored, where column 10, lines 28 thru column 11, lines 37 notes compiler 330 includes a first stage 332, a second stage 336, and a third stage 340, which each perform different operations to produce compiled code 344, column 11, lines 38-62 further notes driver 322 provides the API defines functions for feeding input data to the acceleration engine 312 and defines the operation(s) to perform on the input data, the driver may identify a neural network that the acceleration engine 312 is to execute, as well as the location in the processor memory 304 or on the storage device 306 where the compiled code 344 for the neural network is located, and column 11, lines 63-67 notes an integrated circuit device, e.g. accelerator 402, then used to execute the compiled code of the neural network).
As to claim 7, Benfield et al. in view of Liu et al. disclose in response to the API call (Benfield, modified with Liu, e.g. in response to API call as noted in claim 1), is to receive as input (Benfield, e.g. as compiled code 344 from compiler 330 by driver 322) an indication of a portion of the first tensor to be translated into the second tensor (Benfield, e.g. see claims 1 and 6, where the driver provides the API that defines functions for feeding input data (e.g. input tensors) to the acceleration engine 312 and defines the operation(s) to perform on the input data (e.g. tensor operations as tensor indexing using matrix multiplications and/or matrices transposes on tensors (and/or elements thereof)), e.g. to be transformed, e.g. “translated,” into the output tensors as described).
As to claim 8, Benfield et al. in view of Liu et al. disclose a system (Benfield, Figure 3, host system 300), comprising the one or more processors (Benfield, e.g. processor 302 and/or acceleration engine 312) as described in claim 1. Please see the rejection and rationale for claim 1 above.
As to claim 9, Benfield et al. in view of Liu et al. disclose in response to the API call, cause the first tensor to be translated into the second tensor asynchronously (see claims 1 and 2).
As to claim 10, Benfield et al. in view of Liu et al. disclose in response to the API call, asynchronously store the second tensor in a memory of a graphics processing unit (GPU) (see claim 3).
As to claim 11, Benfield et al. in view of Liu et al. disclose in response to the API call, use automatic transaction accounting (see claim 5).
As to claim 12, Benfield et al. in view of Liu et al. disclose in response to the API call, asynchronously copy data from the first tensor according to the tensor map (see claims 1-4, where Benfield, column 9, lines 65 thru column 10, lines 6 further notes copying data, e.g. from processor memory 304 into the acceleration engine 312, copying input data for the neural network from processor memory 304 into the acceleration engine 312, and/or copying results from the acceleration engine 312 into the processor memory 304).
As to claim 13, Benfield et al. in view of Liu et al. disclose in response to the API call (e.g. Benfield, modified with Liu, e.g. in response to API call as noted in claim 1), cause a particular hardware unit [[is]] to be used (Benfield, e.g. cause the acceleration engine 312 (similar to accelerator 402) to perform the operations as described, see claim 1).
As to claim 14, Benfield et al. in view of Liu et al. disclose a method, comprising the method as performed by the one or more processors of claim 1. Please see the rejection and rationale for claim 1 above.
As to claim 15, Benfield et al. in view of Liu et al. disclose in response to the receipt of the API call, initiating one or more memory copy operations to be performed asynchronously (see claims 1-4, where Benfield, column 9, lines 65 thru column 10, lines 6 further notes copying data, e.g. from processor memory 304 into the acceleration engine 312, copying input data for the neural network from processor memory 304 into the acceleration engine 312, and/or copying results from the acceleration engine 312 into the processor memory 304).
As to claim 16, Benfield et al. in view of Liu et al. disclose the API is to use transaction accounting different from manual transaction accounting (Benfield, e.g. where system may be programmed to use “automatic transaction accounting” as described in claim 5, different “manual transaction accounting”).
As to claim 17, Benfield et al. in view of Liu et al. disclose the tensor map is stored in a data structure that indicates information about the first tensor and the second tensor (Benfield, e.g. see claim 6, where the tensor indexing/mapping operations may be stored as compiled code 344 for performing the operations as defined by the API).
As to claim 18, Benfield et al. in view of Liu et al. disclose in response to the receipt of the API call (Benfield, modified with Liu, e.g. in response to API call as noted in claim 1), using an input of the API to obtain the tensor map from memory (Benfield, e.g. see claim 6, where the tensor indexing/mapping operations may be stored as compiled code 344 for performing the operations as defined by the API).
As to claim 19, Benfield et al. in view of Liu et al. disclose in response to the API call, using an input of the API to obtain a portion of the first tensor to be translated into the second tensor (see claim 7).
As to claim 20, Benfield et al. in view of Liu et al. disclose a non-transitory computer-readable medium (Benfield, Figure 3, processor memory 304 and/or storage device 306) having stored thereon a set of instructions (Benfield, e.g. program code, in the form of instructions), which if performed by one or more processors (Benfield, e.g. processor 302 and/or acceleration engine 312)(Benfield, column 9, lines 3-25 and lines 59-60), cause the one or more processors (Benfield, e.g. processor 302 and/or acceleration engine 312) to at least perform the method of claim 14, similar to the one or more processors of claim 1. Please see the rejection and rationale for claim 1 above.
Response to Arguments
Applicant’s arguments, see pages 5 and 6, filed November 20, 2025, with respect to claims 1 and 8 have been fully considered and are persuasive. Independent claims 1 and 8 have been amended to recite similar limitations as independent claim 14. Therefore, the Double Patenting rejection of claims 1 and 8 has been withdrawn.
Applicant's arguments filed November 20, 2025 have been fully considered but they are not persuasive. Applicant amends independent claims 1 and 8 to similarly recite limitations of previously amended independent claim 14. Applicant argues on pages 6-9 of the Amendment filed that the prior art previously cited, e.g. Yu et al., fails to teach or suggest the limitations of the claims as now amended for independent claims 1 and 8 and recited by independent claim 14.
In reply, Yu et al. is no longer used for teaching the limitations the claims. All claims are now taught by newly found reference Benfield et al. (US 12,175,222) in view of Liu et al. (US 2021/0117806). Please see the rejection and notes regarding the claims above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wu et al. (US 2019/0042092) disclose a system and method of storing tensor data representing a tensor, the system may include memory controller circuitry to access the memory circuitry and processor circuitry to: receive a request for a tensor operation; generate a plurality of sub-commands for the tensor operation; and provide the sub-commands to memory controller circuitry to perform the tensor operation based on instructions contained in one or more of the sub-commands, where the instructions contained in one or more of the sub-commands may include identify addresses in memory to access; activate one or more rows in the memory circuitry that correspond to the addresses; and transfer tensor data to and/or from the memory circuitry.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACINTA M CRAWFORD whose telephone number is (571)270-1539. The examiner can normally be reached 8:30a.m. to 4:30p.m.
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, King Y. Poon can be reached at (571)272-7440. 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.
/JACINTA M CRAWFORD/Primary Examiner, Art Unit 2617