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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The Amendment filed 2/4/2026 has been entered. Claims 1-20 remain pending in the present Office Action.
The Amendments to the claims have been fully considered and are sufficient to overcome the non-statutory double patenting rejections with co-pending applications 18/086,464 and 18/086,469 presented in the previous Office Action.
The Amendments to the claims have been fully considered and are sufficient to overcome all rejections under 35 U.S.C. 112(b) presented in the previous Office Action.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 4, 8-9, 11, 14, and 19-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 7-9, 14, and 20 of copending Application No. 18/086,433 in view of Liu et al. (U.S. Pub. No. 2021/0117806), hereinafter Liu.
Please see Table 1 provided below for a comparison of the claims. Unless otherwise indicated, each claim of the instant application is compared to the claim of the same number in the reference application. Any limitations in the instant claims not taught by limitations in the reference claims are bolded.
The reference claims teach all the limitations of the instant claims except according to a tensor map. However, Liu teaches the translation according to a tensor map (Claim 1 – “receiving a second request to perform a second operation on generic tensor raw data associated with the generic tensor; and responsive to the second request, performing the second operation on the generic tensor raw data, the performing the second operation including mapping a tensor coordinate specified by the second request to a memory address”; [0098] – “performs the operations to manipulate the generic tensor raw data 306 and accesses the manipulated generic tensor descriptors 308 and manipulated generic tensor raw data 306 as specified by the program source 414.”; [0120] – “The generic tensor descriptor is a construct that indicates how to obtain data elements of generic tensor raw data given an input multi-index.”; [0030] – “A generic tensor is described both by a generic tensor descriptor and generic tensor raw data. […] a 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.”; [0033] – “The “generic tensor descriptor” of T is the implementation of the address function g: X[Symbol font/0xAE]Y. The address function maps the set of all tensor coordinates of a generic tensor T to the set of all memory addresses associated with the generic tensor T.” To perform the operation (e.g., a translation to generate a new tensor) on the generic tensor raw data associated with a generic tensor descriptor (a “tensor map”), a coordinate is mapped to a memory address to obtain the generic tensor raw data of the operand tensor. This mapping is indicated by the generic tensor descriptor.).
It would have been obvious to one of ordinary skill in the art to have modified the reference claims such that the first tensor is translated into the second tensor according to a tensor map as taught by Liu. The tensor map (generic tensor descriptor) enables retrieval of data elements of a tensor using tensor coordinates for use in operations on the actual data and allows efficient storage of tensor data by providing a means to treat tensor raw data as multiple different tensors through manipulation of the mapping function implemented by the generic tensor descriptor (Liu: [0030] and [0120]-[0121]).
Additionally, claim 19 of the instant application differs from claim 7 of the reference application in statutory category. However, it would have been obvious to one of ordinary skill in the art that the limitations of the processor of reference claim 7 could be applied to the method of instant claim 19.
This is a provisional nonstatutory double patenting rejection.
Claims 2-3, 5, 7, 10, 12-13, 16, and 18 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, and 14 of copending Application No. 18/086,433 in view of Liu and further in view of DESAPPAN et al. (U.S. Pub. No. 2020/0272892), hereinafter DESAPPAN. Please see Table 1 provided below for a comparison of the claims. Unless otherwise indicated, each claim of the instant application is compared to the claim of the same number in the reference application. Any limitations in the instant claims not taught by limitations in the reference claims are bolded.
The reference claims in view of Liu teach all the limitations of the instant application except limitations which amount to cause the second tensor to be stored by overwriting at least a portion of memory storing the first tensor. Equivalents include “cause memory storing the first tensor to be used to store the second tensor” and performing an “in-place” transform with the first and second tensor. However, DESAPPAN teaches cause the second tensor to be stored by overwriting at least a portion of memory storing the first tensor ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”).
It would have been obvious one of ordinary skill in the art to have modified the reference claims in view of Liu to store the second tensor by overwriting memory storing the first tensor as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
This is a provisional nonstatutory double patenting rejection.
Claim 6 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/086,433 in view of Liu and further in view of Li et al. (U.S. Pub. No. 2022/0253488), hereinafter Li. Please see Table 1 provided below for a comparison of the claims. Unless otherwise indicated, each claim of the instant application is compared to the claim of the same number in the reference application. Any limitations in the instant claims not taught by limitations in the reference claims are bolded.
The reference claim in view of Liu teaches all the limitations of instant claim 6 except wherein the circuitry, in response to the API call, indicates complete performance of the one or more functions provided by the API before the second tensor is stored. However, Li teaches circuitry, in response to an API call, indicates complete performance of the one or more functions provided by the API before the second tensor is stored ([0025] – “Operations such as Conv2D 212 are purposefully asynchronous and return a tensor whose data might not be computed yet. The operation is dispatched by the Ops API 120 to the WebNN thread 210 to be asynchronously executed by the WebNN Controller 140. […] Later, when the user code (e.g., the JavaScript instructions 110) needs to retrieve the data that is backing a tensor (e.g., to retrieve Tensor.data 250), the JavaScript-based thread 205 requests the data from the WebNN thread 210 (e.g., from the WebNN controller 140).”; [0030] – “tensor manager 510 implements an application programming interface (API) to enable access to a tensor, creation of tensors, and freeing of tensors by a user (and/or an application executed at the request of the user) to access tensor data. The example tensor manager 510 maintains the life cycle of tensors (e.g., manages storage of tensor data) and associates the tensor to delayed machine learning operations.”; [0032] – “The example tensor memory 515 of the illustrated example of FIG. 5 stores tensor data and/or objects at the direction of the tensor manager 510. As used herein, a tensor is a data object that includes data and a description of the data. The tensor description includes information such as a shape and/or other metadata describing the tensor data. The tensor is backed by a memory (e.g., the tensor memory 515). In examples disclosed herein, the tensor data is only accessible via the tensor manager 510.”; [0063] – “for a ML operation whose evaluation is delayed, referred to herein as delayed operation, the tensor manager 510 holds the reference to the input tensor much longer (e.g., until its output tensor is materialized)”. An asynchronous tensor operation dispatched by calling an API returns a tensor (“indicates complete performance of the API”) before the data backing the output tensor has been computed. Since it is returned before the tensor data is computed, the tensor data also has not be stored.).
It would have been obvious to one of ordinary skill in the art to have modified the API taught by the reference claim in view of Liu such that in response to the API call, circuitry indicates complete performance of the API before the second tensor is stored as taught by Li in order to allow a thread calling the API to be free to handle other tasks (Li: [0024]-[0025]).
This is a provisional nonstatutory double patenting rejection.
Claim 15 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 14 of copending Application No. 18/086,433 in view of Liu and further in view of Peng et al. (U.S. Pub. No. 2021/0191758), hereinafter Peng. Please see Table 1 provided below for a comparison of the claims. Unless otherwise indicated, each claim of the instant application is compared to the claim of the same number in the reference application. Any limitations in the instant claims not taught by limitations in the reference claims are bolded.
The reference claim in view of Liu teaches all the limitations of instant claim 15 except the transaction count updated by a second API. However, Peng teaches the transaction count updated by a second API ([0019]-[0020] and [0027] – a function call of an API is referred to as a kernel; [0051] – “Turning now to FIG. 5, one embodiment of a table 500 for supporting data broadcast for matrix operations is shown. In some embodiments, the instructions of a software application, such as a GEMM software application, includes instructions for setting up the table 500. In an embodiment, a particular compute kernel includes the instructions. […] Table 500 includes fields 512-524 for storing information used during the broadcast of shared data during matrix operations such as GEMM operations.”; [0054] – “Field 520 stores a count of a number of outstanding read access requests targeting the corresponding shared data.” A first kernel, i.e., a first API function call, sets up the table, including field 520 which stores a transaction count. [0055] – “Each time instructions of the software application cause logic in the processor core to detect an outstanding read access request targets particular shared data, the corresponding count in field 520 is updated. In an embodiment, updating the value stored in field 520 includes incrementing the value.”; [0066] – “The application generates multiple compute kernels. The application also assigns compute kernels sharing same data to compute units, each kernel capable of supporting broadcast of the shared data, by loading characteristics of the broadcast in a table (block 702).”; [0069] – “A compute kernel, executing for a thread group, conveys a read access request targeting shared data. The access of the targeted, shared data is detected (block 802). One or more of instructions of an application and circuitry of a processor increments a count of a number of read requests from the thread groups targeting the same shared data (block 804). In an embodiment, the application updates the field 520 of table 500.” A second compute kernel, i.e., a “second API” function call, conveys the read access request which causes the field 520, i.e., the “transaction count”, to be incremented.).
It would have been obvious to one of ordinary skill in the art to have modified the API taught by the reference claim in view of Liu such that the transaction count is updated by a second API as taught by Peng. Incorporating the methods of Peng, including the described manual transaction accounting based on a transaction count, would allow an application with high data reuse, such as one which performs a GEMM operation on tensors, to be more efficient by reducing a number of memory accesses to achieve decreased latency and increased performance (see Peng: [0003]-[0004] and [0032]).
This is a provisional nonstatutory double patenting rejection.
Table 1: Comparison of claims with reference application 18/086,433
Claim
Application No. 18/086,473 (instant)
Application No. 18/086,433 (reference)
1
One or more processors, comprising:
circuitry, wherein the circuitry, in response to an application programming interface (API) call, causes a first tensor to be translated into a second tensor according to a tensor map, wherein the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count.
One or more processors, comprising: circuitry to, in response to an application programming interface (API) call, cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor, wherein the API is to receive one or more source memory locations and one or more destination memory locations for the one or more memory transactions and to provide one or more functions to perform manual transaction accounting for the one or more memory transactions, and wherein the manual transaction accounting comprises updating an expected transaction count of a synchronization object based, at least in part, on an amount of data to be moved by the one or more memory transactions.
2
The one or more processors of claim 1, wherein the circuitry, in response to the API call, causes the second tensor to be stored by overwriting at least a portion of memory storing the first tensor.
See claim 1
3
The one or more processors of claim 1, wherein the circuitry, in response to the API call, causes memory storing the first tensor to be used to store the second tensor.
See claim 1
4
The one or more processors of claim 1, wherein the circuitry, in response to the API call, indicates whether a particular hardware unit is to perform the one or more functions provided by the API.
See claim 7: The one or more processors of claim 1, wherein the API is to provide to a user an indication of one or more hardware units to be used to perform the one or more memory transactions.
5
The one or more processors of claim 1, wherein the circuitry, in response to the API call, causes the second tensor to be asynchronously stored in memory that stores the first tensor.
See claim 1: “in response to an application programming interface (API) call, cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor”
6
The one or more processors of claim 1, wherein the circuitry, in response to the API call, indicates complete performance of the one or more functions provided by the API before the second tensor is stored.
See claim 1
7
The one or more processors of claim 1, wherein the circuitry, in response to the API call, causes at least a portion of memory storing the first tensor to store the second tensor.
See claim 1
8
A system, comprising: one or more processors to in response to an application programming interface (API) call, cause a first tensor to be translated into a second tensor according to a tensor map, wherein the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count.
A system, comprising: one or more processors to, in response to an application programming interface (API) call, cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor, wherein the API is to receive one or more source memory locations and one or more destination memory locations for the one or more memory transactions and to provide one or more functions to perform manual transaction accounting for the one or more memory transactions, and wherein the manual transaction accounting comprises updating an expected transaction count of a synchronization object based, at least in part, on an amount of data to be moved by the one or more memory transactions.
9
The system of claim 8, wherein the one or more processors, in response to the API call, cause at least one memory transaction to be asynchronously performed.
The system of claim 8, wherein the one or more memory transactions are asynchronous reduction operations to be performed by a graphics processing unit (GPU).
See claim 8: “in response to an application programming interface (API) call, cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor”
10
The system of claim 8, wherein the one or more processors, in response to the API call, cause an in-place transform involving the first tensor and second tensor.
See claim 8: “in response to an application programming interface (API) call, cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor”
11
The system of claim 8, wherein the one or more processors, in response to the API call, receive as input an indication of a location of the first tensor in storage.
See claim 8: “in response to an application programming interface (API) call, cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor, wherein the API is to receive one or more source memory locations and one or more destination memory locations for the one or more memory transactions”
12
The system of claim 8, wherein the one or more processors, in response to the API call, cause memory storing the first tensor to be used to store the second tensor.
See claim 8
13
The system of claim 8, wherein the one or more processors, in response to the API call, cause the second tensor to be stored in memory asynchronously.
See claim 8: “cause one or more memory transactions to asynchronously transform a first tensor into a different second tensor,”
14
A method, comprising: in response to receiving an application programming interface (API) call, causing a first tensor to be translated into a second tensor according to a tensor map, wherein the API provides one or more functions to perform a manual transaction
accounting of the translation based on a transaction count.
A method, comprising: receiving an application programming interface (API) call to perform an asynchronous tensor transformation from one or more source memory locations to one or more destination memory locations; in response to the API call, causing one or more memory transactions to asynchronously transform a first tensor into a different second tensor, wherein the API comprises one or more functions to perform manual transaction accounting for the one or more memory transactions, and wherein the manual transaction accounting comprises updating an expected transaction count of a synchronization object based, at least in part, on an amount of data to be moved by the one or more memory transactions; and performing the manual transaction accounting for the one or more memory transactions.
15
The method of claim 14, wherein manual transaction accounting is performed based, at least in part, on a transaction count updated by a second API.
See claim 14: “wherein the API comprises one or more functions to perform manual transaction accounting for the one or more memory transactions, and wherein the manual transaction accounting comprises updating an expected transaction count”
16
The method of claim 14, wherein, in response to receiving the API call, the method causes the second tensor to be stored by overwriting at least a portion of memory storing the first tensor.
See claim 14
18
The method of claim 14, wherein, in response to receiving the API call, the method overwrites tensor data in memory.
See claim 14
19
The method of claim 14, wherein, in response to receiving the API call, the method indicates whether one or more particular hardware units are to perform the one or more functions provided by the API.
See claim 7: The one or more processors of claim 1, wherein the API is to provide to a user an indication of one or more hardware units to be used to perform the one or more memory transactions.
See claim 1: “in response to an application programming interface (API) call, cause one or more memory transactions […] wherein the API is […] to provide one or more functions to perform manual transaction accounting for the one or more memory transactions”
20
A non-transitory computer-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to at least perform the method of claim 14.
A non-transitory computer-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to at least perform the method of claim 14.
Claim Objections
Claims 4, 6, and 19 are objected to because of the following informalities:
In claim 4, line 3, it is unclear whether “the API” is referring to the API call recited in claim 1, lines 2-3 and claim 4, line 2, or the API recited in claim 1, line 4.
In claim 6, line 3, it is unclear whether “the API” is referring to the API call recited in claim 1, lines 2-3 and claim 6, line 2, or the API recited in claim 1, line 4.
In claim 19, line 4, it is unclear whether “the API” is referring to the API call recited in claim 14, lines 2-3 and claim 19, line 2, or the API recited in claim 14, line 4.
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-20 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 API" in line 4. There is insufficient antecedent basis for this limitation in the claim. The claim previous recites “an application programming interface (API) call” but fails to recite an API. Thus, it is unclear whether “the API” is referring to the same previously recited API call, an API which includes the previously recited API call, another API call within an API which includes the previously recited API call, an entirely different API, etc.
Claims 2-7 depend from claim 1 and therefore inherit the deficiencies of claim 1.
Claim 8 recites the limitation "the API" in line 4. There is insufficient antecedent basis for this limitation in the claim. The claim previous recites “an application programming interface (API) call” but fails to recite an API. Thus, it is unclear whether “the API” is referring to the same previously recited API call, an API which includes the previously recited API call, another API call within an API which includes the previously recited API call, an entirely different API, etc.
Claims 9-13 depend from claim 8 and therefore inherit the deficiencies of claim 8.
Claim 14 recites the limitation "the API" in line 4. There is insufficient antecedent basis for this limitation in the claim. The claim previous recites “an application programming interface (API) call” but fails to recite an API. Thus, it is unclear whether “the API” is referring to the same previously recited API call, an API which includes the previously recited API call, another API call within an API which includes the previously recited API call, an entirely different API, etc.
Claims 15-20 depend from claim 14 and therefore inherit the deficiencies of claim 14.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
The claims are reciting one or more processors comprising circuitry which is a concrete thing consisting of parts, or of certain devices and combination of devices, and therefore are directed to a machine, which is one of the four statutory categories.
Step 2A, Prong One:
Claim 1 recites the limitations causes a first tensor to be translated into a second tensor according to a tensor map and perform a manual transaction accounting of the translation based on a transaction count which can be performed in the human mind through observation, judgement, evaluation and opinion, with the aid of pen and paper, and is therefore reciting an abstract idea (i.e., a mental process).
Step 2A, Prong Two:
The judicial exception is not integrated into a practical application because the additional claim limitations only recite mere instructions to apply the exception.
The additional elements of One or more processors, comprising: circuitry, wherein the circuitry, in response to an application programming interface (API) call, and wherein the API provides one or more functions to is reciting generic computing components, e.g. hardware and software, to implement the judicial exception. As such, the additional element amounts to no more than mere instructions to apply the judicial exception on a computer.
Mere instructions to apply the exception are not indicative of integration into a practical application (see MPEP 2106.04(d)); accordingly, the claim is directed to the judicial exception.
Step 2B:
As explained with respect to Step 2A, Prong Two, the additional element amounts to no more than mere instructions to apply the exception, as it is merely reciting generic computing components to perform the exception. Accordingly, the additional element does not amount to significantly more than the recited judicial exception (see MPEP 2106.05(f)), and does not provide an inventive concept. Thus, claim 1 in ineligible.
Claim 2 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 2 recites the additional element wherein the circuitry, in response to the API call, causes the second tensor to be stored by overwriting at least a portion of memory storing the first tensor which is insignificant extra solution activity of mere data outputting as it is merely outputting a result (the second tensor) of the mental process recited in claim 1 and does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 1, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of storing data as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 1, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 2 is not eligible.
Claim 3 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 3 recites the additional element wherein the circuitry, in response to the API call, causes memory storing the first tensor to be used to store the second tensor which is insignificant extra solution activity of mere data outputting as it is merely outputting a result (the second tensor) of the mental process recited in claim 1 and does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 1, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of storing data as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 1, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 3 is not eligible.
Claim 4 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Claim 4 further recites indicates whether a particular hardware unit is to perform the one or more functions provided by the API which can be performed in the human mind through observation, judgement, evaluation and opinion, with the aid of pen and paper, and is therefore reciting an abstract idea (i.e., a mental process).
Claim 4 recites the additional element wherein the circuitry, in response to the API call, which amounts to mere instructions to apply the exception for the same reasons presented with respect to claim 1. This additional element of mere instructions to apply the exception, when considered alone and in combination with the additional element recited in claim 1, is not indicative of integration into a practical application.
Further, this additional element of mere instructions to apply the exception does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 1, these additional elements represent mere instructions to apply the exceptions, and therefore do not provide an inventive concept. Accordingly, claim 4 is not eligible.
Claim 5 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 5 recites the additional element wherein the circuitry, in response to the API call, causes the second tensor to be asynchronously stored in memory that stores the first tensor which is insignificant extra solution activity of mere data outputting as it is merely outputting a result (the second tensor) of the mental process recited in claim 1 and does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 1, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of storing data as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 1, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 5 is not eligible.
Claim 6 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Claim 6 further recites indicates complete performance of the one or more functions provided by the API before the second tensor is stored which can be performed in the human mind through observation, judgement, evaluation and opinion, with the aid of pen and paper, and is therefore reciting an abstract idea (i.e., a mental process).
Claim 6 recites the additional element wherein the circuitry, in response to the API call, which amounts to mere instructions to apply the exception for the same reasons presented with respect to claim 1. This additional element of mere instructions to apply the exception, when considered alone and in combination with the additional element recited in claim 1, is not indicative of integration into a practical application.
Further, this additional element of mere instructions to apply the exception does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 1, these additional elements represent mere instructions to apply the exceptions, and therefore do not provide an inventive concept. Accordingly, claim 6 is not eligible.
Claim 7 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 7 recites the additional element wherein the circuitry, in response to the API call, causes at least a portion of memory storing the first tensor to store the second tensor which is insignificant extra solution activity of mere data outputting as it is merely outputting a result (the second tensor) of the mental process recited in claim 1 and does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 1, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of storing data as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 1, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 7 is not eligible.
Claims 8-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 8 and 12-13 are directed to A system, comprising: one or more processors to, in response to an application programming interface (API) call, perform the active functions performed by the processor of claims 1, 3 and 5, respectively. As such, in view of the abovementioned reasons presented with respect to claims 1, 3 and 5, claims 8 and 12-13 are also directed to a judicial exception without significantly more and are ineligible.
For clarity, the additional element of claim 8 recited above is considered to be mere instructions to apply the exception, which is not indicative of integration into a practical application nor does it amount to significantly more than the recited judicial exception.
Claim 9 is dependent on claim 8, and therefore inherits the same judicial exception recited in claim 8. The judicial exception recited in claim 8 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 9 recites the additional element wherein the one or more processors, in response to the API call, cause at least one memory transaction to be asynchronously performed which is insignificant extra solution activity of mere data gathering/outputting as it does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 8, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of storing and retrieving data from memory as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 8, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 9 is not eligible.
Claim 10 is dependent on claim 8, and therefore inherits the same judicial exception recited in claim 8. Claim 10 further recites cause an in-place transform involving the first tensor and second tensor which can be performed in the human mind through observation, judgement, evaluation and opinion, with the aid of pen and paper, and is therefore reciting an abstract idea (i.e., a mental process).
Claim 10 recites the additional element wherein the one or more processors, in response to the API call, which amounts to mere instructions to apply the exception for the same reasons presented with respect to claim 8. This additional element of mere instructions to apply the exception, when considered alone and in combination with the additional element recited in claim 8, is not indicative of integration into a practical application.
Further, this additional element of mere instructions to apply the exception does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 8, these additional elements represent mere instructions to apply the exceptions, and therefore do not provide an inventive concept. Accordingly, claim 10 is not eligible.
Claim 11 is dependent on claim 8, and therefore inherits the same judicial exception recited in claim 8. The judicial exception recited in claim 8 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 11 recites the additional element wherein the one or more processors, in response to the API call, receive as input an indication of a location of the first tensor in storage which is insignificant extra solution activity of mere data gathering (receiving information for obtaining the first tensor) as it does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 8, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of receiving data as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 8, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 11 is not eligible.
Claims 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 14 and 16 are directed to A method, comprising: in response to receiving an application programming interface (API) call, perform the active functions performed by the processor of claims 1 and 2, respectively. As such, in view of the abovementioned reasons presented with respect to claims 1 and 2, claims 14 and 16 are also directed to a judicial exception without significantly more and are ineligible.
For clarity, the additional element of claim 14 recited above is considered to be mere instructions to apply the exception, which is not indicative of integration into a practical application nor does it amount to significantly more than the recited judicial exception.
Claim 15 is dependent on claim 14, and therefore inherits the same judicial exception recited in claim 14. Claim 15 further recites wherein the manual transaction accounting is performed based, at least in part, on a transaction count updated which can be performed in the human mind through observation, judgement, evaluation and opinion, with the aid of pen and paper, and is therefore reciting an abstract idea (i.e., a mental process).
Claim 15 recites the additional element by a second API which amounts to mere instructions to apply the exception for the same reasons presented with respect to claim 14. This additional element of mere instructions to apply the exception, when considered alone and in combination with the additional element recited in claim 14, is not indicative of integration into a practical application.
Further, this additional element of mere instructions to apply the exception does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 14, these additional elements represent mere instructions to apply the exceptions, and therefore do not provide an inventive concept. Accordingly, claim 15 is not eligible.
Claim 17 is dependent on claim 14, and therefore inherits the same judicial exception recited in claim 14. The judicial exception recited in claim 14 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 17 recites the additional element wherein, in response to receiving the API call, the method obtains the tensor map from a storage location based, at least in part, on an input to the API call which is insignificant extra solution activity of mere data gathering (obtaining the tensor map) as it does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 14, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of retrieving data from memory as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 14, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 17 is not eligible.
Claim 18 is dependent on claim 14, and therefore inherits the same judicial exception recited in claim 14. The judicial exception recited in claim 14 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 18 recites the additional element wherein, in response to receiving the API call, the method overwrites tensor data in memory which is insignificant extra solution activity of mere data outputting as it does not meaningfully limit the recited judicial exception. This additional element of insignificant extra-solution activity, when considered alone and in combination with the additional element recited in claim 14, is not indicative of integration into a practical application.
Additionally, this limitation is well-understood, routine and conventional activity of storing data to memory as identified in MPEP 2106.05(d). This additional element of insignificant extra-solution activity/well understood, routine and conventional activity does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 14, these additional elements represent mere instructions to apply the exception and insignificant extra solution activity, and therefore do not provide an inventive concept. Accordingly, claim 18 is not eligible.
Claim 19 is dependent on claim 14, and therefore inherits the same judicial exception recited in claim 14. Claim 19 further recites indicates whether one or more particular hardware units are to perform the one or more functions provided by the API which can be performed in the human mind through observation, judgement, evaluation and opinion, with the aid of pen and paper, and is therefore reciting an abstract idea (i.e., a mental process).
Claim 19 recites the additional element in response to receiving the API call, the method which amounts to mere instructions to apply the exception for the same reasons presented with respect to claim 14. This additional element of mere instructions to apply the exception, when considered alone and in combination with the additional element recited in claim 14, is not indicative of integration into a practical application.
Further, this additional element of mere instructions to apply the exception does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 14, these additional elements represent mere instructions to apply the exceptions, and therefore do not provide an inventive concept. Accordingly, claim 19 is not eligible.
Claim 20 is dependent on claim 14, and therefore inherits the same judicial exception recited in claim 14. The judicial exception recited in claim 14 is not integrated into a practical application because the additional elements recited only represent mere instructions to apply the exception.
Claim 20 recites the additional element A non-transitory computer-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to at least perform the method of claim 14 which is mere instructions to apply the exception. This additional element mere instructions to apply the exception, when considered alone and in combination with the additional element recited in claim 14, is not indicative of integration into a practical application.
This additional element of mere instructions to apply the exception does not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element recited in claim 14, these additional elements represent mere instructions to apply the exception, and therefore do not provide an inventive concept. Accordingly, claim 20 is not eligible.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 8, 14-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (U.S. Pub. No. 2021/0117806), hereinafter Liu, in view of Peng et al. (U.S. Pub. No. 2021/0191758), hereinafter Peng.
Regarding claim 1, Liu teaches One or more processors, comprising:
circuitry, (FIG. 4C; [0100] – “processor 432 that includes a program 434. The program includes tensor manipulation instructions. When executed, the program 434 requests tensor manipulation instruction circuits 436 to perform the requested tensor manipulation instructions. The tensor manipulation instructions include one or more of instructions for manipulating generic tensor raw data 306 and/or instructions for manipulating generic tensor descriptors 308. In some implementations, these instructions are part of an instruction set architecture and the tensor manipulation instruction circuitry 436 executes such instructions.”; [0124] – “Suitable processors include, by way of example, […] Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC)”) wherein the circuitry, in response to an application programming interface (API) call ([0026] – “The individual operations are, in various implementations, performed by any of the following entities: […] hardware that performs the operations in response to an invocation such as an API call”; [0093] – “the operations are API functions that can be called by software”; [0120] – “When compiled, the compiled program 416 includes the requests to perform the manipulations on the generic tensor raw data (e.g., via function calls, API calls,”), causes a first tensor to be translated into a second tensor ([0088] – “The following operations act on the actual tensor raw data itself-that is, the following operations act on the data in generic tensor raw data: sliced copy; general matrix multiply ("GEMM") or batched GEMM on 2D or 3D generic tensors; reduction of an n-dimensional generic tensor; and algorithm specific transformations of an n-dimensional generic tensor.”; [0089] – “The sliced copy operation create new generic tensor raw data, or modify existing generic tensor raw data (for example, by using atomic add). This operation first creates a slicing window on one tensor (source tensor) and another slicing window on another tensor (destination tensor). The concept of "slicing window" is the same as the one defined in slice transformation for generic tensor descriptor. The sliced copy operation then uses the tensor raw data from the slicing window of the source tensor to set or modify (for example, atomic add) raw data inside the slice window of destination tensor, on per-element basis.”; [0090] – “both the inputs and result of a GEMM or batched GEMM operations referred in this writing are generic tensors. […] These operations generate new generic tensor raw data based on the matrix multiplication of two input generic tensors (raw data and generic tensor descriptors).”; [0091] – “The generic tensor reduction operation takes multiple input generic tensors with the same number of dimensions, and the same length on each of the dimensions, and reduces these multiple input generic tensors to a single output generic tensor with the same number of dimensions and the same length on each of the dimensions as the multiple input generic tensors. Each of the elements with multi-index (Ix, Iy, Iz) of the output generic tensor is the result of reduction of the elements with multi-index (Ix, Iy, Iz) from all the input generic tensors. A reduction operation on elements can be: max, min, summation”; [0092] – “For any of the above operations, the resulting tensor is written into any memory, including memories that are different than the memory from which the operand tensors originated.”; [0121] – “At step 606, the tensor manipulator requestor 302 requests the tensor manipulator 304 perform an operation on generic tensor raw data associated with the generic tensor descriptor. A large variety of operations are described herein. In contrast to the operations on the generic tensor descriptor, operations on the generic tensor raw data modifies the contents of the generic tensor raw data or generates new generic tensor raw data based on the specific operations requested.” Original tensor raw data (elements of a first tensor) is manipulated (“translated”) into new/modified tensor raw data of a result tensor (a “second tensor”).) according to a tensor map (Claim 1 – “receiving a second request to perform a second operation on generic tensor raw data associated with the generic tensor; and responsive to the second request, performing the second operation on the generic tensor raw data, the performing the second operation including mapping a tensor coordinate specified by the second request to a memory address”; [0098] – “The execution system 420 includes a processor 422 that executes the compiled program 416. When executed, the compiled program performs the operations to manipulate the generic tensor raw data 306 and accesses the manipulated generic tensor descriptors 308 and manipulated generic tensor raw data 306 as specified by the program source 414.”; [0120] – “The generic tensor descriptor is a construct that indicates how to obtain data elements of generic tensor raw data given an input multi-index.”; [0030] – “A generic tensor is described both by a generic tensor descriptor and generic tensor raw data. […] a 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.”; [0033] – “The “generic tensor descriptor” of T is the implementation of the address function g: X[Symbol font/0xAE]Y. The address function maps the set of all tensor coordinates of a generic tensor T to the set of all memory addresses associated with the generic tensor T.” To perform the operation (e.g., a translation to generate a new tensor) on the generic tensor raw data associated with a generic tensor descriptor (a “tensor map”), a coordinate is mapped to a memory address to obtain the generic tensor raw data of the operand tensor. This mapping is indicated by the generic tensor descriptor.), wherein the API provides one or more functions ([0025] – “The present disclosure presents a number of operations that can be combined to compose artificial neural network "kernels," where the term "kernel" means a program, portion of code, or hardware operation. […] Other kernels are application programming interface ("API") calls.”; [0093] – “the operations are API functions that can be called by software.”; [0122] – “compiled program 416 includes the requests to perform the manipulations on the generic tensor raw data (e.g., via function calls, API calls, or explicitly via specific instructions)”) […].
Liu fails to expressly teach the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count.
However, Peng teaches an API provides one or more functions ([0019]-[0020] – “a parallel computing platform and corresponding application programming interface (API) models for developing the software applications using GEMM operations . An example of the parallel computing platform is the OpenCL® (Open Computing Language) framework. The OpenCL framework (generally referred to herein as "OpenCL") includes a C-like language. […] A function call in the C-like language is referred to as an OpenCL kernel, a software kernel, a compute kernel, or simply a "kernel".”; [0027] – “The software application written by software developers includes the steps of matrix operation 130. For example, the software application uses a function call with a definition defined in a particular library. The software developers use one of multiple types of parallel computing platforms and application programming interface (API) models for developing software applications. A function call in these platforms is referred to as a "compute kernel", or simply a "kernel".”) to perform a manual transaction accounting of the translation based on a transaction count ([0051] – “Turning now to FIG. 5, one embodiment of a table 500 for supporting data broadcast for matrix operations is shown. In some embodiments, the instructions of a software application, such as a GEMM software application, includes instructions for setting up the table 500. In an embodiment, a particular compute kernel includes the instructions. […] Table 500 includes fields 512-524 for storing information used during the broadcast of shared data during matrix operations such as GEMM operations.”; [0052] – “Field 514 stores an indication of a number of thread groups accessing the shared data identified by the corresponding broadcast identifier.”; [0054] – “Field 520 stores a count of a number of outstanding read access requests targeting the corresponding shared data.”; [0055] – “Each time instructions of the software application cause logic in the processor core to detect an outstanding read access request targets particular shared data, the corresponding count in field 520 is updated. In an embodiment, updating the value stored in field 520 includes incrementing the value.”; [0066] – “The application generates multiple compute kernels. The application also assigns compute kernels sharing same data to compute units, each kernel capable of supporting broadcast of the shared data, by loading characteristics of the broadcast in a table (block 702).”; [0069] – “A compute kernel, executing for a thread group, conveys a read access request targeting shared data. The access of the targeted, shared data is detected (block 802). One or more of instructions of an application and circuitry of a processor increments a count of a number of read requests from the thread groups targeting the same shared data (block 804). In an embodiment, the application updates the field 520 of table 500.”; [0070] – “one or more of instructions of the application and circuitry of a processor compares the updated value in field 520 of table 500 to the threshold value in field 514 of table 500. If the threshold number of read requests from the thread groups is reached ("yes" branch of the conditional block 806), then the count is reset (block 810). The shared data is fetched with a single read access request (block 812). For example, the single read access request described earlier with one or more of a broadcast identifier and a bit mask is conveyed to the memory subsystem. When the shared data is returned from the memory subsystem, the shared data broadcast to corresponding compute units based on the broadcast characteristics such as the mask (block 814).” In a software application performing a GEMM operation (i.e., a “translation” of a first tensor to a second tensor also disclosed previously in Liu), a kernel (i.e., a “function” provided by the API) may establish the table 500, including field 520 which counts a number of read access requests (i.e., a count of requests for a memory transaction, or a “transaction count”) received from kernels executing for thread groups on compute units of a SIMD processor, until the count reaches the number of thread groups expected that is specified in field 514, at which point the shared data will be fetched from memory (i.e., a memory transaction is performed).).
Liu and Peng are considered to be analogous art to the claimed invention because they are in the same field of processors that perform an API to cause operations on tensors. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API including an API call which causes a first tensor to be translated into a second tensor according to a tensor map, e.g., through a GEMM operation on the first tensor, as taught by Liu to incorporate the teachings of Peng such that the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count. Incorporating the methods of Peng, including the described manual transaction accounting based on a transaction count, would allow an application with high data reuse, such as one which performs a GEMM operation on tensors, to be more efficient by reducing a number of memory accesses to achieve decreased latency and increased performance (see Peng: [0003]-[0004] and [0032]).
Regarding claim 8, Liu teaches A system, comprising: one or more processors (FIG. 1, processor 102) to implement the active functions performed by the one or more processors of claim 1. Thus, claim 8 is unpatentable over Liu in view of Peng for the same reasons presented with respect to claim 1.
Regarding claim 14, Liu teaches A method comprising: the active functions performed by the one or more processors of claim 1. Thus, claim 14 is unpatentable over Liu in view of Peng for the same reasons presented with respect to claim 1.
Regarding claim 15, the combination of Liu in view of Peng teaches The method of claim 14. Peng further teaches wherein the manual transaction accounting is performed based, at least in part, on a transaction count updated by a second API ([0019]-[0020] and [0027] – a function call of an API is referred to as a kernel; [0051] – “Turning now to FIG. 5, one embodiment of a table 500 for supporting data broadcast for matrix operations is shown. In some embodiments, the instructions of a software application, such as a GEMM software application, includes instructions for setting up the table 500. In an embodiment, a particular compute kernel includes the instructions. […] Table 500 includes fields 512-524 for storing information used during the broadcast of shared data during matrix operations such as GEMM operations.”; [0054] – “Field 520 stores a count of a number of outstanding read access requests targeting the corresponding shared data.” A first kernel, i.e., a first API function call, sets up the table, including field 520 which stores a transaction count. [0055] – “Each time instructions of the software application cause logic in the processor core to detect an outstanding read access request targets particular shared data, the corresponding count in field 520 is updated. In an embodiment, updating the value stored in field 520 includes incrementing the value.”; [0066] – “The application generates multiple compute kernels. The application also assigns compute kernels sharing same data to compute units, each kernel capable of supporting broadcast of the shared data, by loading characteristics of the broadcast in a table (block 702).”; [0069] – “A compute kernel, executing for a thread group, conveys a read access request targeting shared data. The access of the targeted, shared data is detected (block 802). One or more of instructions of an application and circuitry of a processor increments a count of a number of read requests from the thread groups targeting the same shared data (block 804). In an embodiment, the application updates the field 520 of table 500.” A second compute kernel, i.e., a “second API” function call, conveys the read access request which causes the field 520, i.e., the “transaction count”, to be incremented.).
It would have been obvious to one of ordinary skill in the art to have modified the API including an API call which causes a first tensor to be translated into a second tensor according to a tensor map, e.g., through a GEMM operation on the first tensor, as taught by Liu to incorporate the teachings of Peng such that the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count. Incorporating the methods of Peng, including the described manual transaction accounting based on a transaction count, would allow an application with high data reuse, such as one which performs a GEMM operation on tensors, to be more efficient by reducing a number of memory accesses to achieve decreased latency and increased performance (see Peng: [0003]-[0004] and [0032]).
Regarding claim 20, Liu teaches A non-transitory computer-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to at least perform ([0120] – “The various functional units illustrated in the figures and/or described herein […] are, in various implementations, implemented as a general purpose computer, a processor, or a processor core, or as a program, software, or firmware, stored in a non-transitory computer readable medium or in another medium, executable by a general purpose computer, a processor, or a processor core.”) the method of claim 14. Thus, claim 20 is unpatentable over Liu in view of Peng for the same reasons presented with respect to claim 1.
Claims 2-3, 7, 10, 12, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Peng as applied to claims 1, 8 and 14 above, and further in view of DESAPPAN et al. (U.S. Pub. No. 2020/0272892), hereinafter DESAPPAN.
Regarding claim 2, the combination of Liu in view of Peng teaches The one or more processors of claim 1. Liu further teaches wherein the circuitry, in response to the API call, causes the second tensor to be stored ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to expressly teach causing the second tensor to be stored by overwriting at least a portion of memory storing the first tensor.
However, DESAPPAN teaches causing the second tensor to be stored by overwriting at least a portion of memory storing the first tensor ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”; [0036] – “The set of values may be organized as a tensor. The first set of values may be an input set of values or an intermediate first set of values. At block 9 04, a first portion of the first set of values may be stored in an on-chip memory, […] the portion of the input tensor may be processed in an initial ML layer to generate a corresponding portion of a second output tensor. In certain cases, this processing may be performed by splitting the portion of the input tensor into tiles and processing the tiles. At block 908, the stored first portion of the first set of values is overwritten with the generated second portion. For example, as the portion of the input tensor is processed, the processed part of the input tensor is overwritten, in the cache memory, by the output correspond tensor.”; [0021] – “CNNs can include any number of layers. The layers represent a mathematical function performed for an input tensor and result in an output tensor. Examples of the mathematical functions include convolution/deconvolution functions, pooling, elementwise add, concatenate, etc.” A layer translates a first tensor to a resulting output tensor according to a mathematical function.).
DESAPPAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transforming and storing tensors. Therefore, it would have been obvious one of ordinary skill in the art to have modified the API which causes the second tensor to be stored as taught by Liu to store the second tensor by overwriting memory storing the first tensor as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
Regarding claim 3, the combination of Liu in view of Peng teaches The one or more processors of claim 1. Liu further teaches wherein the circuitry, in response to the API call, causes memory […] to be used to store the second tensor ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to teach the memory to be used to store the second tensor storing the first tensor.
However, DESAPPAN teaches the memory to be used to store the second tensor storing the first tensor ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”; [0036] – “The set of values may be organized as a tensor. The first set of values may be an input set of values or an intermediate first set of values. At block 9 04, a first portion of the first set of values may be stored in an on-chip memory, […] the portion of the input tensor may be processed in an initial ML layer to generate a corresponding portion of a second output tensor. In certain cases, this processing may be performed by splitting the portion of the input tensor into tiles and processing the tiles. At block 908, the stored first portion of the first set of values is overwritten with the generated second portion. For example, as the portion of the input tensor is processed, the processed part of the input tensor is overwritten, in the cache memory, by the output correspond tensor.”; [0021] – “CNNs can include any number of layers. The layers represent a mathematical function performed for an input tensor and result in an output tensor. Examples of the mathematical functions include convolution/deconvolution functions, pooling, elementwise add, concatenate, etc.” A layer translates a first tensor to a resulting output tensor according to a mathematical function.).
DESAPPAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transforming and storing tensors. Therefore, it would have been obvious one of ordinary skill in the art to have modified the API which causes the second tensor to be stored as taught by Liu to store the second tensor by causing memory storing the first tensor to be used to store the second tensor as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
Regarding claim 7, the combination of Liu in view of Peng teaches The one or more processors of claim 1. Liu further teaches wherein the circuitry, in response to the API call, causes at least a portion of memory […] to store the second tensor ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to teach the portion of memory to store the second tensor storing the first tensor.
However, DESAPPAN teaches the portion of memory to store the second tensor storing the first tensor ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”; [0036] – “The set of values may be organized as a tensor. The first set of values may be an input set of values or an intermediate first set of values. At block 904, a first portion of the first set of values may be stored in an on-chip memory, […] the portion of the input tensor may be processed in an initial ML layer to generate a corresponding portion of a second output tensor. In certain cases, this processing may be performed by splitting the portion of the input tensor into tiles and processing the tiles. At block 908, the stored first portion of the first set of values is overwritten with the generated second portion. For example, as the portion of the input tensor is processed, the processed part of the input tensor is overwritten, in the cache memory, by the output correspond tensor.”; [0021] – “CNNs can include any number of layers. The layers represent a mathematical function performed for an input tensor and result in an output tensor. Examples of the mathematical functions include convolution/deconvolution functions, pooling, elementwise add, concatenate, etc.” A layer translates a first tensor to a resulting output tensor according to a mathematical function.).
DESAPPAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transforming and storing tensors. Therefore, it would have been obvious one of ordinary skill in the art to have modified the API which causes the second tensor to be stored as taught by Liu to store the second tensor by causing at least a portion of memory storing the first tensor to be used to store the second tensor as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
Regarding claim 10, the combination of Liu in view of Peng teaches The system of claim 8. Liu further teaches wherein the one or more processors, in response to the API call, cause an […] transform involving the first tensor and second tensor ([0088] – “The following operations act on the actual tensor raw data itself-that is, the following operations act on the data in generic tensor raw data: sliced copy; general matrix multiply ("GEMM") or batched GEMM on 2D or 3D generic tensors; reduction of an n-dimensional generic tensor; and algorithm specific transformations of an n-dimensional generic tensor.”; [0089]-[0091] – describe specific operations and how they transform data of one or more input tensors to data of an output tensor; [0092] – “For any of the above operations, the resulting tensor is written into any memory, including memories that are different than the memory from which the operand tensors originated.”; [0121] – “At step 606, the tensor manipulator requestor 302 requests the tensor manipulator 304 perform an operation on generic tensor raw data associated with the generic tensor descriptor. A large variety of operations are described herein. In contrast to the operations on the generic tensor descriptor, operations on the generic tensor raw data modifies the contents of the generic tensor raw data or generates new generic tensor raw data based on the specific operations requested.” Original tensor raw data (elements of a first tensor) is manipulated (“transformed”) into new/modified tensor raw data of a result tensor (a “second tensor”).).
The combination of Liu in view of Peng fails to expressly teach the transform is an in-place transform.
However, DESAPPAN teaches a transform involving a first tensor and a second tensor is an in-place transform ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”; [0036] – “The set of values may be organized as a tensor. The first set of values may be an input set of values or an intermediate first set of values. At block 9 04, a first portion of the first set of values may be stored in an on-chip memory, […] the portion of the input tensor may be processed in an initial ML layer to generate a corresponding portion of a second output tensor. In certain cases, this processing may be performed by splitting the portion of the input tensor into tiles and processing the tiles. At block 908, the stored first portion of the first set of values is overwritten with the generated second portion. For example, as the portion of the input tensor is processed, the processed part of the input tensor is overwritten, in the cache memory, by the output correspond tensor.”; [0021] – “CNNs can include any number of layers. The layers represent a mathematical function performed for an input tensor and result in an output tensor. Examples of the mathematical functions include convolution/deconvolution functions, pooling, elementwise add, concatenate, etc.” A layer translates a first tensor to a resulting output tensor according to a mathematical function. The transform is “in-place” since the second, output tensor is stored in the same place as the first, input tensor.).
DESAPPAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transforming and storing tensors. Therefore, it would have been obvious one of ordinary skill in the art to have modified the API which causes a transform involving the first tensor and second tensor as taught by Liu cause an in-place transform as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
Claim 12 recites substantially the additional limitations as those performed by the one or more processors of claim 3, applied to the system of claim 8. Thus, claim 12 is rejected as being unpatentable over Liu in view Peng and further in view of DESAPPAN for the same reasons presented with respect to claim 3 above.
Claim 16 recites substantially the additional limitations as those performed by the one or more processors of claim 2, applied to the method of claim 14. Thus, claim 16 is rejected as being unpatentable over Liu in view Peng and further in view of DESAPPAN for the same reasons presented with respect to claim 2 above.
Regarding claim 18, the combination of Liu in view of Peng teaches The method of claim 14. Liu further teaches wherein, in response to receiving the API call, the method [writes] tensor data in memory ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to teach the method overwrites tensor data.
However, DESAPPAN teaches the method overwrites tensor data ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”; [0036] – “The set of values may be organized as a tensor. The first set of values may be an input set of values or an intermediate first set of values. At block 9 04, a first portion of the first set of values may be stored in an on-chip memory, […] the portion of the input tensor may be processed in an initial ML layer to generate a corresponding portion of a second output tensor. In certain cases, this processing may be performed by splitting the portion of the input tensor into tiles and processing the tiles. At block 908, the stored first portion of the first set of values is overwritten with the generated second portion. For example, as the portion of the input tensor is processed, the processed part of the input tensor is overwritten, in the cache memory, by the output correspond tensor.”; [0021] – “CNNs can include any number of layers. The layers represent a mathematical function performed for an input tensor and result in an output tensor. Examples of the mathematical functions include convolution/deconvolution functions, pooling, elementwise add, concatenate, etc.” A layer translates a first tensor to a resulting output tensor according to a mathematical function.).
DESAPPAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transforming and storing tensors. Therefore, it would have been obvious one of ordinary skill in the art to have modified the API which causes the second tensor to be stored as taught by Liu to store the second tensor by overwriting first tensor data in memory as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
Claims 4 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Peng as applied to claims 1 and 14 above, and further in view of Kerr et al. (U.S. Pub. No. 2021/0124582), hereinafter Kerr.
Regarding claim 4, the combination of Liu in view of Peng teaches The one or more processors of claim 1. Liu further teaches wherein the circuitry, in response to the API call, [a] hardware unit is to perform the one or more functions provided by the API ([0017]-[0018] – “APD 116 includes one or more parallel processing units configured to perform computations […] The driver 122 controls operation of the APD 116 by, for example, providing an application programming interface ("API") to software (e.g., applications 126) executing on the processor 102 to access various functionality of the APD 116.”; [0026] – “hardware that performs the operations in response to an invocation such as an API call”).
The combination of Liu in view of Peng fails to expressly teach the processor circuitry, in response to the API call, indicates whether a particular hardware unit is perform the functions of the API.
However, Kerr teaches the circuitry, in response to the API call, indicates whether a particular hardware unit is perform the functions of the API ([0161] – “a device driver may implement an application programming interface (API) that defines various functions that can be utilized by an application in order to generate graphical data for display. The API provides an abstraction for a programmer that lets a programmer utilize specialized graphics hardware, such as the PPU 300, to generate the graphical data without requiring the programmer to utilize the specific instruction set for the PPU 300. The application may include an API call that is routed to the device driver for the PPU 300. The device driver interprets the API call and performs various operations to respond to the API call. In some instances, the device driver may perform operations by executing instructions on the CPU. In other instances, the device driver may perform operations, at least in part, by launching operations on the PPU 300 utilizing an input/output interface between the CPU and the PPU 300. In an embodiment, the device driver is configured to implement the graphics processing pipeline 600 utilizing the hardware of the PPU 300.” The device driver, in implementing an API causes operations, i.e., “functions”, corresponding to an API call to be performed either on a CPU or a PPU – a particular hardware unit. Thus, the API of the device driver indicates, to either the CPU or the PPU, that they are supposed to perform the operations of the API call (“perform the API”). E.g., the device driver (and thus the circuitry executing the device driver) launching operations on the PPU is indicating the PPU is supposed to perform the API.).
Kerr is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API in a parallel computing environment. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API taught by Liu to indicate whether a particular hardware unit is used to perform the API as taught by Kerr. Using an API which indicates to a particular hardware unit of multiple hardware units whether it is to perform operations abstracts underlying details of using specialized hardware such that a programmer can utilize the hardware unit without knowing a specific instruction set (Kerr: [0161]).
Claim 19 recites substantially the additional limitations as those performed by the one or more processors of claim 4, applied to the method of claim 14. Thus, claim 19 is rejected as being unpatentable over Liu in view Peng and further in view of Kerr for the same reasons presented with respect to claim 4 above.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Peng as applied to claim 1 above, and further in view of DESAPPAN and Li et al. (U.S. Pub. No. 2022/0253488), hereinafter Li.
Regarding claim 5, the combination of Liu in view of Peng teaches The one or more processors of claim 1. Liu further teaches wherein the circuitry, in response to the API call, causes the second tensor to be […] stored in memory […] ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to teach second tensor is asynchronously stored, and that the memory to store the second tensor is memory that stores the first tensor.
However, DESAPPAN teaches the memory to store the second tensor is memory that stores the first tensor ([0026] – “a portion of an input tensor is overwritten by a corresponding output of processing that portion of input tensor. […] the memory 322 includes a first portion 328 of a first tensor. The first portion 328, in this example, may be an intermediate tensor output from a previous layer (not shown). The first portion 328 may be processed in a first layer 330 in conjunction with first ML network information 332 with model and/or weight information to produce a first layer output 334. The first output 334 is written back into the on-chip memory 322, overwriting portions of the on-chip memory 322 which were storing the first portion 328 to obtain a second portion 336 of a second tensor.”; [0036] – “The set of values may be organized as a tensor. The first set of values may be an input set of values or an intermediate first set of values. At block 9 04, a first portion of the first set of values may be stored in an on-chip memory, […] the portion of the input tensor may be processed in an initial ML layer to generate a corresponding portion of a second output tensor. In certain cases, this processing may be performed by splitting the portion of the input tensor into tiles and processing the tiles. At block 908, the stored first portion of the first set of values is overwritten with the generated second portion. For example, as the portion of the input tensor is processed, the processed part of the input tensor is overwritten, in the cache memory, by the output correspond tensor.”; [0021] – “CNNs can include any number of layers. The layers represent a mathematical function performed for an input tensor and result in an output tensor. Examples of the mathematical functions include convolution/deconvolution functions, pooling, elementwise add, concatenate, etc.” A layer translates a first tensor to a resulting output tensor according to a mathematical function.).
DESAPPAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transforming and storing tensors. Therefore, it would have been obvious one of ordinary skill in the art to have modified the API which causes the second tensor to be stored as taught by Liu to store the second tensor in memory that stores the first tensor as taught by DESAPPAN in order to more efficiently use memory and processing resources (DESAPPAN: [0029] and [0033]).
The combination of Liu in view Peng and DESAPPAN fails to expressly teach the second tensor is asynchronously stored.
However, Li teaches the second tensor is asynchronously stored ([0025] – “Operations such as Conv2D 212 are purposefully asynchronous and return a tensor whose data might not be computed yet. The operation is dispatched by the Ops API 120 to the WebNN thread 210 to be asynchronously executed by the WebNN Controller 140. […] Later, when the user code (e.g., the JavaScript instructions 110) needs to retrieve the data that is backing a tensor (e.g., to retrieve Tensor.data 250), the JavaScript-based thread 205 requests the data from the WebNN thread 210 (e.g., from the WebNN controller 140).”; [0030] – “tensor manager 510 implements an application programming interface (API) to enable access to a tensor, creation of tensors, and freeing of tensors by a user (and/or an application executed at the request of the user) to access tensor data. The example tensor manager 510 maintains the life cycle of tensors (e.g., manages storage of tensor data) and associates the tensor to delayed machine learning operations.”; [0032] – “The example tensor memory 515 of the illustrated example of FIG. 5 stores tensor data and/or objects at the direction of the tensor manager 510. As used herein, a tensor is a data object that includes data and a description of the data. The tensor description includes information such as a shape and/or other metadata describing the tensor data. The tensor is backed by a memory (e.g., the tensor memory 515). In examples disclosed herein, the tensor data is only accessible via the tensor manager 510.”; [0063] – “for a ML operation whose evaluation is delayed, referred to herein as delayed operation, the tensor manager 510 holds the reference to the input tensor much longer (e.g., until its output tensor is materialized)” A tensor operation which computes and stores an output (“second”) tensor for a corresponding input (“first”) tensor may be asynchronously executed; thus, the output tensor is asynchronously generated and stored.).
Li is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API to cause operations on tensors. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API taught by Liu in view of Peng and DESAPPAN such that the second tensor is asynchronously stored as taught by Li in order to allow a thread calling the API to be free to handle other tasks (Li: [0024]-[0025]).
Claim 6, 9, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Peng as applied to claims 1 and 8 above, and further in view of Li.
Regarding claim 6, the combination of Liu in view of Peng teaches The one or more processors of claim 1. Liu further teaches wherein the circuitry, in response to the API call, […] the second tensor is stored ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to expressly teaches the processor circuitry, in response to the API call, indicates complete performance of the one or more functions provided by the API before the second tensor is stored.
However, Li teaches the processor circuitry, in response to the API call, indicates complete performance of the one or more functions provided by the API before the second tensor is stored ([0025] – “Operations such as Conv2D 212 are purposefully asynchronous and return a tensor whose data might not be computed yet. The operation is dispatched by the Ops API 120 to the WebNN thread 210 to be asynchronously executed by the WebNN Controller 140. […] Later, when the user code (e.g., the JavaScript instructions 110) needs to retrieve the data that is backing a tensor (e.g., to retrieve Tensor.data 250), the JavaScript-based thread 205 requests the data from the WebNN thread 210 (e.g., from the WebNN controller 140).”; [0030] – “tensor manager 510 implements an application programming interface (API) to enable access to a tensor, creation of tensors, and freeing of tensors by a user (and/or an application executed at the request of the user) to access tensor data. The example tensor manager 510 maintains the life cycle of tensors (e.g., manages storage of tensor data) and associates the tensor to delayed machine learning operations.”; [0032] – “The example tensor memory 515 of the illustrated example of FIG. 5 stores tensor data and/or objects at the direction of the tensor manager 510. As used herein, a tensor is a data object that includes data and a description of the data. The tensor description includes information such as a shape and/or other metadata describing the tensor data. The tensor is backed by a memory (e.g., the tensor memory 515). In examples disclosed herein, the tensor data is only accessible via the tensor manager 510.”; [0063] – “for a ML operation whose evaluation is delayed, referred to herein as delayed operation, the tensor manager 510 holds the reference to the input tensor much longer (e.g., until its output tensor is materialized)”. An asynchronous tensor operation (“one or more functions of the API”) dispatched by calling an API returns a tensor (“indicates complete performance of the API”) before the data backing the output tensor has been computed. Since it is returned before the tensor data is computed, the tensor data also has not be stored.).
Li is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API to cause operations on tensors. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API taught by Liu in view of Peng such that the in response to the API call, the circuitry indicates complete performance of the one or more functions of the API before the second tensor is stored as taught by Li in order to allow a thread calling the API to be free to handle other tasks (Li: [0024]-[0025]).
Regarding claim 9, the combination of Liu in view of Peng teaches The system of claim 8. Liu further teaches wherein the one or more processors, in response to the API call, cause at least one memory transaction to be […] performed ([0028] – “tensor raw data is simply the data elements of a tensor laid out in memory addresses”; [0088]-[0092] – “For any of the above operations, the resulting tensor is written into any memory, including memories that are different than the memory from which the operand tensors originated.”; [0120]-[0121] – “The generic tensor descriptor is a construct that indicates how to obtain data elements of generic tensor raw data given an input multi-index. […] At step 606, the tensor manipulator requestor 302 requests the tensor manipulator 304 perform an operation on generic tensor raw data associated with the generic tensor descriptor. A large variety of operations are described herein. In contrast to the operations on the generic tensor descriptor, operations on the generic tensor raw data modifies the contents of the generic tensor raw data or generates new generic tensor raw data based on the specific operations requested. At step 608, the tensor manipulator 304 performs the operation requested at step 606.” Performing the operations in response to an API call to operate on the generic tensor raw data includes performing at least one memory transaction. Specifically, performing the API requires accessing generic tensor raw data stored in memory, modifying the data, and writing the resulting tensor data to memory, which can be considered a “memory transaction” since memory, and specifically a plurality of memory addresses, is being accessed in order to perform API.).
The combination of Liu in view of Peng fails to expressly teach the at least one memory transaction is asynchronously performed.
However, Li teaches at least one memory transaction (e.g., the second tensor is stored) is asynchronously performed ([0025] – “Operations such as Conv2D 212 are purposefully asynchronous and return a tensor whose data might not be computed yet. The operation is dispatched by the Ops API 120 to the WebNN thread 210 to be asynchronously executed by the WebNN Controller 140. […] Later, when the user code (e.g., the JavaScript instructions 110) needs to retrieve the data that is backing a tensor (e.g., to retrieve Tensor.data 250), the JavaScript-based thread 205 requests the data from the WebNN thread 210 (e.g., from the WebNN controller 140).”; [0030] – “tensor manager 510 implements an application programming interface (API) to enable access to a tensor, creation of tensors, and freeing of tensors by a user (and/or an application executed at the request of the user) to access tensor data. The example tensor manager 510 maintains the life cycle of tensors (e.g., manages storage of tensor data) and associates the tensor to delayed machine learning operations.”; [0032] – “The example tensor memory 515 of the illustrated example of FIG. 5 stores tensor data and/or objects at the direction of the tensor manager 510. As used herein, a tensor is a data object that includes data and a description of the data. The tensor description includes information such as a shape and/or other metadata describing the tensor data. The tensor is backed by a memory (e.g., the tensor memory 515). In examples disclosed herein, the tensor data is only accessible via the tensor manager 510.”; [0063] – “for a ML operation whose evaluation is delayed, referred to herein as delayed operation, the tensor manager 510 holds the reference to the input tensor much longer (e.g., until its output tensor is materialized)” A tensor operation which computes and stores an output (“second”) tensor for a corresponding input (“first”) tensor may be asynchronously executed; thus, the output tensor is asynchronously generated and stored.).
Li is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API to cause operations on tensors. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API taught by Liu in view of Peng such that the second tensor is asynchronously stored (i.e., a memory transaction is asynchronously performed) as taught by Li in order to allow a thread calling the API to be free to handle other tasks (Li: [0024]-[0025]).
Regarding claim 13, the combination of Liu in view of Peng teaches The system of claim 8. Liu further teaches wherein the one or more processors, in response to the API call, cause the second tensor to be stored in memory […] ([0092] – “For any of the above operations, the resulting tensor is written into any memory”).
The combination of Liu in view of Peng fails to expressly teaches the second tensor stored asynchronously.
However, Li teaches the second tensor is stored asynchronously ([0025] – “Operations such as Conv2D 212 are purposefully asynchronous and return a tensor whose data might not be computed yet. The operation is dispatched by the Ops API 120 to the WebNN thread 210 to be asynchronously executed by the WebNN Controller 140. […] Later, when the user code (e.g., the JavaScript instructions 110) needs to retrieve the data that is backing a tensor (e.g., to retrieve Tensor.data 250), the JavaScript-based thread 205 requests the data from the WebNN thread 210 (e.g., from the WebNN controller 140).”; [0030] – “tensor manager 510 implements an application programming interface (API) to enable access to a tensor, creation of tensors, and freeing of tensors by a user (and/or an application executed at the request of the user) to access tensor data. The example tensor manager 510 maintains the life cycle of tensors (e.g., manages storage of tensor data) and associates the tensor to delayed machine learning operations.”; [0032] – “The example tensor memory 515 of the illustrated example of FIG. 5 stores tensor data and/or objects at the direction of the tensor manager 510. As used herein, a tensor is a data object that includes data and a description of the data. The tensor description includes information such as a shape and/or other metadata describing the tensor data. The tensor is backed by a memory (e.g., the tensor memory 515). In examples disclosed herein, the tensor data is only accessible via the tensor manager 510.”; [0063] – “for a ML operation whose evaluation is delayed, referred to herein as delayed operation, the tensor manager 510 holds the reference to the input tensor much longer (e.g., until its output tensor is materialized)” A tensor operation which computes and stores an output (“second”) tensor for a corresponding input (“first”) tensor may be asynchronously executed; thus, the output tensor is asynchronously generated and stored.).
Li is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API to cause operations on tensors. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API taught by Liu such that the second tensor is asynchronously stored as taught by Li in order to allow a thread calling the API to be free to handle other tasks (Li: [0024]-[0025]).
Claim 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Peng as applied to claims 8 and 14 above, and further in view of Benfield et al. (U.S. Patent No. 12,175,222), hereinafter Benfield.
Regarding claim 11, the combination of Liu in view of Peng teaches The system of claim 8. Liu further teaches wherein the one or more processors, in response to the API call, [access] an indication of a location of the first tensor in storage (Claim 1 – “performing the second operation on the generic tensor raw data, the performing the second operation including mapping a tensor coordinate specified by the second request to a memory address,” The coordinate can be considered an “indication of a location of the first tensor in storage” because the coordinates are mapped to memory addresses comprising the tensor data according to the generic tensor descriptor (see [0030] and [0033]). [0089]-[0091] – the operations on generic tensor raw data require obtaining the raw data of the first tensor; [0098] – “When executed, the compiled program performs the operations to manipulate the generic tensor raw data 306 and accesses the manipulated generic tensor descriptors 308 and manipulated generic tensor raw data 306 as specified by the program source 414.”; [0101] – “the generic tensor raw data 306 and the generic tensor descriptors 308 are stored at any appropriate location such as a memory. In the descriptions of FIGS. 4A-4C, phrases such as "manipulating generic tensor raw data" means performing one or more of the operations described herein as operating on the generic tensor raw data”; [0120] – “The generic tensor descriptor is a construct that indicates how to obtain data elements of generic tensor raw data given an input multi-index.”).
The combination of Liu in view of Peng fails to expressly teach in response to an API call, receive as input the indication of the location of the first tensor.
However, Benfield teaches in response to an API call, receive as input an indication of the location of a first tensor in storage (Col. 2, lines 9-24 – “An artificial neural network generally includes processing nodes arranged on two or more layers. Processing nodes on a neural network layer may perform various operations, such as filtering, linear transformation, non-linear transformation, down-sampling, up-sampling, pooling, and the like, to map an input feature map (e.g., an input tensor) to an output feature map (e.g., an output tensor). These operations may use mathematical operations, such as multiplications, summations, subtractions, divisions, floor divisions, modulo operations, and the like, to select particular elements or slices of a tensor (which may be referred to as tensor indexing), map particular tensor elements of the input tensor to desired elements or slices in the output tensor, and/or perform mathematical calculations on selected tensor elements or slices.”; Col. 10, lines 51-54 – “the processor 302, through the execution of a driver 322, may need to perform steps such as configuring Direct Memory Access (DMA) descriptors for moving data into or out of the acceleration engine 312,”; Col. 11, lines 41-59 – “The driver 322 can provide an interface between applications executing on the host system 300 (or on another host system) and the acceleration engine 312. For example, the driver 322 can provide an Application Program Interface (API) that defines functions for feeding input data to the acceleration engine 312 and defining the operation to perform on the input data. In this and other examples, the driver 322 can configure the acceleration engine 312 to perform the operation. For example, the driver 322 can 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. The driver 322 can further load into the acceleration engine 312 or cause the acceleration engine 312 to load the compiled code 344, can load or cause the acceleration engine 312 to load the 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.” Col. 23, lines 25-52 – “to perform a set of operations, input data on which the operations are to be performed must first be moved into the accelerators 1202a-1202n. Additionally, in some cases, program code is also moved into the accelerators 1202a-1202n, which programs the operations that the accelerators 1202a-1202n will perform on the data. In the illustrated example, the acceleration engine 1200 includes n accelerators 1202a-1202n. Examples of accelerators that can be included in the acceleration engine 1200 include […] neural network accelerators […] input data and/or program code for the accelerators 1202a-1202n can be stored in the DRAM 1230.”; Col. 24, lines 52-58 – “descriptor identifies an address for a block of data and an operation (e.g., a read or a write) to perform. A descriptor, for example, can direct a DMA engine to instruct a DMA controller to read a block of data from DRAM 1230. A descriptor can, as a further example, instruct the DMA engine to write data, read by the DMA controller, to an accelerator”. The API of the driver defines functions for feeding (as input) input data and compiled code for execution on an acceleration engine. Thus the API causes the driver to load, i.e., receive from one storage location and move to another storage location, the input data, e.g., an input tensor for a neural network, as input to the acceleration engine.).
Benfield is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API to cause operations on tensors. Liu similarly teaches the API may be provided by a driver which allows software to control operations of an accelerated processing device used to perform calculations, e.g., tensor operations, for a neural network (Liu: [0018], [0024] and [0028]). Therefore, it would have been obvious to one of ordinary skill in the art to modify the teachings of Liu in view of Peng to incorporate the teachings of Benfield such that the API call of Liu receives the indication of the location of the first tensor in storage as input for the accelerated processing devices as evidenced by Benfield. Further, the methods of Benfield which use an API to load input tensors and neural network code as input to an acceleration engine enable more efficient tensor processing (Benfield: Col. 2, lines 37-46 and Col. 17, lines 57-61).
Regarding claim 17, the combination of Liu in view of Peng teaches The method of claim 14. Liu further teaches wherein, in response to receiving the API call, the method obtains the tensor map from a storage location ([0098] – “When executed, the compiled program performs the operations to manipulate the generic tensor raw data 306 and accesses the manipulated generic tensor descriptors 308 and manipulated generic tensor raw data 306 as specified by the program source 414.”; [0101] – “the generic tensor raw data 306 and the generic tensor descriptors 308 are stored at any appropriate location such as a memory” Claim 1, [0030] and [0033] – the generic tensor descriptor which indicates how the coordinates map to memory addresses of the tensor raw data must be obtained in order to map a tensor coordinate specified in the request to manipulate the tensor raw data).
The combination of Liu in view of Peng fails to expressly teach the storage location based, at least in part, on an input to the API call.
However, Benfield teaches a storage location of a tensor map based, at least in part, on an input to the API call (Col. 2, lines 47-55- “a compiler may generate, based on a representation of a tensor mapping (e.g., in a programming language, such as Python), a list of mappings from elements of an input tensor to elements of an output tensor, where the representation of the tensor mapping may include at least one of an integer division, a floor division, or a modulo operation. Each mapping in the list of mappings may map an element of the input tensor to an element of the output tensor and may be represented by a pair of matrix multiplications”. Compiled code may include mapping of tensors. Col. 10, lines 51-54 – “the processor 302, through the execution of a driver 322, may need to perform steps such as configuring Direct Memory Access (DMA) descriptors for moving data into or out of the acceleration engine 312,”; Col. 11, lines 41-59 – “The driver 322 can provide an interface between applications executing on the host system 300 (or on another host system) and the acceleration engine 312. For example, the driver 322 can provide an Application Program Interface (API) that defines functions for feeding input data to the acceleration engine 312 and defining the operation to perform on the input data. In this and other examples, the driver 322 can configure the acceleration engine 312 to perform the operation. For example, the driver 322 can 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. The driver 322 can further load into the acceleration engine 312 or cause the acceleration engine 312 to load the compiled code 344, can load or cause the acceleration engine 312 to load the 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.”; Col. 23, lines 25-52 – “to perform a set of operations, input data on which the operations are to be performed must first be moved into the accelerators 1202a-1202n. Additionally, in some cases, program code is also moved into the accelerators 1202a-1202n, which programs the operations that the accelerators 1202a-1202n will perform on the data. In the illustrated example, the acceleration engine 1200 includes n accelerators 1202a-1202n. Examples of accelerators that can be included in the acceleration engine 1200 include […] neural network accelerators […] input data and/or program code for the accelerators 1202a-1202n can be stored in the DRAM 1230.”; Col. 24, lines 52-58 – “descriptor identifies an address for a block of data and an operation (e.g., a read or a write) to perform. A descriptor, for example, can direct a DMA engine to instruct a DMA controller to read a block of data from DRAM 1230. A descriptor can, as a further example, instruct the DMA engine to write data, read by the DMA controller, to an accelerator”. The API of the driver defines functions for feeding (as input) input data and compiled code (including mappings of tensors) for execution on an acceleration engine via DMA descriptors which indicate a memory location from which to read data to be loaded. Thus, the API causes the driver to load the input data and compiled code, including a tensor mapping, from a storage location in a DMA descriptor configured by the processor through the API of the driver as input to the acceleration engine.).
Benfield is considered to be analogous art to the claimed invention because it is in the same field of processors that perform an API to cause operations on tensors. Liu similarly teaches the API may be provided by a driver which allows software to control operations of an accelerated processing device used to perform calculations, e.g., tensor operations, for a neural network (Liu: [0018], [0024] and [0028]). Therefore, it would have been obvious to one of ordinary skill in the art to modify the teachings of Liu in view of Benfield that the API call of Liu determines the storage location of the tensor map to be obtained based, at least in part on an input to the API call for the accelerated processing devices as evidenced by Benfield. Further, the methods of Benfield which use an API to load input tensors and neural network code including tensor mappings as input to an acceleration engine enable more efficient tensor processing (Benfield: Col. 2, lines 37-46 and Col. 17, lines 57-61).
Response to Arguments
Applicant's arguments filed 2/4/2026 regarding the double patenting rejections have been fully considered but they are not persuasive.
For clarity of the record, Applicant’s amendments to the claims have been fully considered and are sufficient to overcome the non-statutory double patenting rejections with co-pending applications 18/086,464 and 18/086,469 presented in the previous Office Action.
However, the amendments to the claims are not sufficient to overcome the non-statutory double patenting rejections with co-pending application 18/086,433.
The Applicant must file a terminal disclaimer as a complete and proper response to a double patenting rejection. Applicant's request to hold the non-statutory double patenting rejection in abeyance is not a complete response. "A complete response to a nonstatutory double patenting (NSDP) rejection is either a reply by applicant showing that the claims subject to the rejection are patentably distinct from the reference claims, or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP § 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional. As filing a terminal disclaimer, or filing a showing that the claims subject to the rejection are patentably distinct from the reference application's claims, is necessary for further consideration of the rejection of the claims, such a filing should not be held in abeyance. Only compliance with objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated." See MPEP 804(1)(8)(1). Additionally see MPEP 1490 for a discussion of terminal disclaimers.
Applicant's arguments with respect to the rejections of claims 1-20 under 35 U.S.C. 101, see pages 8-11 of the Remarks filed 2/4/2026 have been fully considered but they are not persuasive.
Arguments presented with respect to Step 2A, Prong One:
Applicant argues “a human cannot practically perform the claimed operation of translating a first tensor to a second tensor, nor using a tensor map to perform such an operation, as recited in amended claim 1. The Office's characterization of "cause a first tensor to be translated into a second tensor according to a tensor map" as an "observation, evaluation, judgment, [and] opinion" (Office Action at 29) does not align with what is actually recited in claim 1, as the translation does not involve observing information, forming an evaluation, or expressing an opinion, but instead requires the presence of processor circuitry to translate a tensor using a tensor map.”
Examiner disagrees. Through evaluation (e.g., performing translation of the first tensor to the second tensor, such as by performing a computation on or transformation of the elements of a tensor to obtain a new tensor), the human mind is able to “cause a first tensor to be translated into a second tensor.” The broadest reasonable interpretation of a tensor map is any data or information that indicates how to obtain second tensor from tensor data of a first tensor (e.g., see paragraph [0079] of the Specification). Thus, a person could be told to obtain a second tensor by multiplying each data element of a first tensor by 2, and the person “causes a first tensor to be translated into a second tensor according to a tensor map” by multiplying each element of the first tensor by 2. As evidenced by Wikipedia (NPL Document U on attached PTO-892), cited in the present Office Action as pertinent prior art, a matrix, e.g. a 2-D array, is a 2nd-order tensor, a vector, e.g., a 1-D array, is 1st-order tensor, and a scalar is a 0th order tensor. The human mind is practically able to handle computations/transformations on these small tensors, and translation of such tensors would not require the use of a processor.
As explained in the rejection of claim 1, specifically with respect to Step 2A, Prong Two, merely reciting a processor comprising circuitry, in response to an API call, performs these operations which can be performed in the human mind through evaluation amounts to mere instructions to implement the mental process on a computer.
Arguments presented with respect to Step 2A, Prong Two:
Applicant argues “the elements of claim 1, as amended, describe technical features that provide a practical application of the alleged abstract idea, such as by providing "one or more functions to perform a manual transaction accounting of the translation based on a transaction count." The one or more functions are not abstract instructions, but rather define executable operations that cause circuitry to perform a manual transaction accounting of the tensor translation. As described in Applicant's specification, in manual transaction accounting, computer program code can, for example, "perform[] one or more aspects of tracking data to be asynchronously moved (e.g., tracking a count of data in bytes, transactions, or some other suitable count)," where the API can "provide[] functions to be used to generate and/or use one or more thread synchronization objects (e.g., barriers and/or pipelines) with one or more asynchronous operations that use manual transaction accounting." Id. Thus, the recited API invokes circuitry to perform a manual transaction accounting of a tensor translation based on a transaction count, which enables, inter alia, synchronization of operations used to perform the tensor translations. This reflects a practical effect that improves memory management and coordination of data movement in tensor-based processing systems, rather than an abstract idea untethered from technological implementation.”
Examiner disagrees. The limitations recited by amended claim 1 “wherein the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count” do not require any memory operations, e.g., memory transactions, nor that data is being moved in a tensor-based processing system, e.g., in the memory of a tensor-based processing system. Further, there is no indication in the claims that the claimed functions provided by the API generate or use synchronization objects, so the claims do not reflect such an improvement to memory management through synchronization operations. Additionally, there is no detail in the claims regarding how the manual transaction accounting of the translation is performed, other than that it is “based on a transaction count”. Thus, claim 1 fails to reflect the alleged improvements.
The human mind is able to “perform a manual transaction accounting of the translation based on a transaction count”. For example, a person is told to translate a 2x2 matrix A (a 2nd-order tensor, i.e., “first tensor”) by multiplying each element by 2 to obtain a resulting matrix B (the “second tensor).
m
a
t
r
i
x
B
=
2
*
m
a
t
r
i
x
A
w
h
e
r
e
A
=
1
2
3
4
A person would know matrix B is also a 2x2 matrix with 4 elements respectively, determined by extracting an element of matrix A and multiplying by 2. The same person could “perform a manual transaction accounting of the translation based on a transaction count” by keeping a count as they obtain each element from matrix A and generate the corresponding element in matrix B (i.e., perform a transaction). For example, the person, with the aid of pen and paper:
i) starts with a transaction count at 0;
ii) determines the first element of matrix B by obtaining the first element of matrix A (i.e., obtaining the value 1) and calculating 1*2=2 to obtain the value of the first element of matrix B;
iii) writes the first element of matrix B down (e.g.,
m
a
t
r
i
x
B
=
2
?
?
?
);
iv) increments the transaction count to 1;
v) determines the second element of matrix B by obtaining the second element of matrix A (i.e., obtaining the value 2) and calculating 2*2=4 to obtain the value of the second element of matrix B;
vi) writes the second element of matrix B down (e.g.,
m
a
t
r
i
x
B
=
2
4
?
?
);
vii) increments the transaction count to 2;
viii) determines the third element of matrix B by obtaining the third element of matrix A (i.e., obtaining the value 3) and calculating 3*2=6 to obtain the value of the third element of matrix B;
ix) writes the third element of matrix B down (e.g.,
m
a
t
r
i
x
B
=
2
4
6
?
);
x) increments the transaction count to 3;
xi) determines the fourth element of matrix B by obtaining the fourth element of matrix A (i.e., obtaining the value 4) and calculating 4*2=8 to obtain the value of the fourth element of matrix B;
xii) writes the fourth element of matrix B down (e.g.,
m
a
t
r
i
x
B
=
2
4
6
8
);
xiii) increments the transaction count to 4, indicating the translation is complete.
Thus, the human mind, with the aid of pen and paper is practically able to “perform a manual transaction accounting of the translation based on a transaction count” as recited by the claims. Reciting “the API provides one or more functions to” perform the manual transaction accounting amounts to no more than mere instructions to implement the abstract idea on a computer.
Thus when considering claim 1 as a whole, the claims merely recite a processor comprising circuitry which, in response to an API, performs an abstract idea. "The courts have also identified limitations that did not integrate a judicial exception into a practical application: Merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer” see MPEP 2106.04(d).
Applicant further alleges “claim 1 recites a technical solution to a technical problem, demonstrating an improvement to the functioning of a computer and neural network technology. For example, as described in Applicant's specification, the processor circuitry performs tensor transformation with a tensor map in a manner that reduces overhead and memory usage while improving overall computational efficiency, such as by facilitating the use of "a data structure that indicates a transformation between a first tensor in global memory (e.g., global memory 218) of a GPU and a second tensor in shared memory (e.g., shared memory 220) of that GPU." Applicant's specification as filed, ¶ [0079]. Such transformation techniques are applicable to and improve various tensor operations, including "asynchronous data copy operations using a tensor map." Applicant's specification as filed, , ¶ [0082].”.
Examiner disagrees. A “tensor map” is not limited to the exemplary embodiment from the specification quoted in the arguments. Further in paragraph [0079], the Specification recites “In at least one embodiment, a tensor map is a data structure that indicates how to obtain second tensor from tensor data (e.g., a tile or subtensor) of first tensor.” Thus, a tensor map is not limited to a data structure that indicates how a first tensor stored a global memory of a GPU is transformed to a second tensor in shared memory of the GPU. Rather, the broadest reasonable interpretation of a tensor map is any data which indicates how to obtain a second tensor from a first tensor, such as an equation for how to obtain matrix B from matrix A provided by the Examiner’s example above.
Claim 1 fails to require either tensor stored in memory, fails to require tensor data being copied or moved, e.g. from one memory to another, and fails to require the use of a memory in general. Thus, claim 1 does not reflect the alleged technical solution which “reduces overhead and memory usage while improving overall computational efficiency” as argued by the Applicant.
As explained above, the limitations “causes a first tensor to be translated into a second tensor according to a tensor map” and “perform a manual transaction accounting of the translation based on a transaction count” can be performed in the human mind through evaluation, and thus are reciting abstract ideas. The additional elements of claim 1 are “One or more processors, comprising: circuitry, wherein the circuitry, in response to an application programming interface (API) call” and “wherein the API provides one or more functions to” which are mere instructions to implement the abstract ideas on a computer. Claim 1, as a whole, amounts to a processor, which in response to an API, implements an abstract idea (“causes a first tensor to be translated into a second tensor according to a tensor map” and “perform a manual transaction accounting of the translation based on a transaction count”). As explained above, claim 1 does not reflect a technological advancement; thus, claim 1 does not integrate the recited abstract ideas into a practical application, and claim 1 is directed to the recited abstract ideas.
Arguments presented with respect to Step 2B:
Applicant asserts amended claim 1 amounts to significantly more than an abstract idea for the same reasons presented with respect to Step 2A, Prong Two.
Examiner disagrees. As explain above, amended claim 1, when considered as a whole, fails to reflect any alleged improvement. Thus, the recitation that “one or more processors comprising circuitry, wherein the circuitry in response to an API call,” performs an abstract idea, “wherein the API provides one or more functions to” perform an abstract idea is not enough to qualify as significantly more as these additional elements, when considered individually and in combination, amount to mere instructions to implement the abstract idea on a computer. “Limitations that the courts have found not to be enough to qualify as "significantly more" when recited in a claim with a judicial exception include: i. Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer” (MPEP 2106.05).
No additional arguments beyond those presented with respect to claim 1 were presented with respect to claims 2-20.
Applicant’s arguments with respect to the rejections of claims 1-20 under 35 U.S.C. 103, see pages 12-16 of the Remarks filed 2/4/2026 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.
Specifically, Applicant’s arguments are that the previously cited references do not teach the new limitation “wherein the API provides one or more functions to perform a manual transaction accounting of the translation based on a transaction count” recited in the amendments to claims 1, 8 and 14. However, the Examiner relies upon new reference Peng et al. (U.S. Pub. No. 2021/0191758) to teach the new limitation.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wikipedia (NPL Document U on PTO-892 titled “Tensor”) teaches “a matrix (a 2-dimensional array), and therefore is a 2nd-order tensor. A simple vector can be represented as a 1-dimensional array, and is therefore a 1st-order tensor. Scalars are simple numbers and are thus 0th-order tensors” (see page 9).
Maiyuran et al. (U.S. Pub. No. 2022/0198735) teaches a tiling mechanism in which transactions for an incoming workload of objects are collected and stored in a transaction storage structure, wherein a scoreboard is maintained to track the transactions (e.g., writes and reads) at each storage location of the transactions storage structure, and when tiling is enabled, the incoming transactions are grouped into batches (see [0206]). It also teaches tile registers for storing tensor/matric values (see [0055]).
Tan et al. (U.S. Pub. No. 2024/0103813) teaches a compute channel which performs computations, such as tensor normalize or tensor reduction, may count the number of data elements of a tensor being streamed into the compute channel and writes the count to memory (see [0026] and [0055])).
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 JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights