DETAILED ACTION
This action is in response to the claims filed February 2, 2026. Claims 1-20 are pending. Claims 1, 8, and 15 are independent claims.
The rejection of the claims for double patenting is withdrawn in view of Applicant’s arguments.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 8, and 15 recite “a kernel generator comprising a kernel parameterization and code of a set of generators”. The specification does not disclose the kernel generator comprising “a set of generators”. Rather, the specification only discloses the kernel generator comprising sets of operators. Claims 2-7, 9-14, and 16-20 are rejected in view of their reliance on claims 1, 8, and 15 respectively.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over “The Next 700 Accelerated Layers: From Mathematical Expressions of Network Computation Graphs to Accelerated GPU Kernels, Automatically” by Vasilache et. al, (hereinafter “Vasilache”), in view of US 20210294602 A1 (hereinafter “Jakubiuk”), further in view of “Composable and Modular Code Generation in MLIR: A Structured and Retargetable Approach to Tensor Compiler Construction” by Vasilache et. al (hereinafter “Zinenko” and referred to by second author to prevent confusion with first Vasilache reference.).
Regarding claim 1, Vasilache discloses:
A computer-implemented method comprising:
receiving, by one or more processors, a kernel generator comprising a kernel parameterization and code of a set of generators … (Page 5, last paragraph - Page 6, paragraph 1, “The Tensor Comprehensions workflow consists of several stages, progressively lowering the level of abstraction (Figure 2). Given a TC with specialized tensor sizes and strides, we lower it to a parametric Halide-IR expression... Complementing this flow, an autotuner and serializable compilation engine interacts with scheduling and mapping strategies to search the optimization space”; Page 12, Paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation [receiving, by one or more processors, a kernel generator comprising a kernel parameterization and code of a set of generators]”) [Examiner’s remarks: The generator (autotuner) receives kernel parameterization information (shape, target architecture) that is used to tune the kernel and a set of generators (code that is being lowered in abstraction).];
…
- translating code of the each generator into an intermediate representation of the each generator in an intermediate language (Page 5, last paragraph, “The Tensor Comprehensions workflow consists of several stages, progressively lowering the level of abstraction (Figure 2). Given a TC with specialized tensor sizes and strides, we lower it to a parametric Halide-IR expression, which is further lowered to a polyhedral representation where most transformations are applied [translating code of the each generator into an intermediate representation of the each generator in an intermediate language]”), …
- determining a configuration of the each generator based on the kernel parameterization and the intermediate representation of the each generator (Page 6, first paragraph, “Complementing this flow, an autotuner and serializable compilation engine interacts with scheduling and mapping strategies to search the optimization space”; Page 12, Paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation [determining a configuration of the each generator based on the kernel parameterization and the intermediate representation of the each generator]”) [Examiner’s remarks: An optimized configuration is found for each generator based on kernel parameterization (kernels of similar shapes/target architecture) and on the intermediate representation of the generator (polyhedral representation).]; and
- generating a [executable] of the each generator of a set of binary objects of the set of generators based on the configuration (Page 5, late paragraph – Page 6, first paragraph, “The output of the polyhedral flow is CUDA code that can be further JIT-compiled with NVRTC and executed. Complementing this flow, an autotuner and serializable compilation engine interacts with scheduling and mapping strategies to search the optimization space [generating a binary object of the each generator of a set of binary objects of the set of generators based on the configuration]” [Examiner’s remarks: The compiler may generate executable code, which is a binary object.]; and
Vasilache does not explicitly disclose:
… written in a general purpose programming language;
for each generator of the set of generators, performing operations comprising:
… the translating comprising accessing a set of regions of the each generator as parameter arguments, the set of regions comprising a body of code passed down and accessible to meta programming constructs;
…
composing a kernel corresponding to the kernel generator based on the set of binary objects of the set of operations and the kernel parameterization.
However, Jakubiuk discloses:
… written in a general purpose programming language (Paragraph [0062], “Specifically, the diagram illustrates an example of the present method utilizing kernels and microkernels. Op1 and Op2 are both hardware-independent, meaning they are unaware of and unconcerned with which specific hardware component must implement the op in question. The ops are each implemented via a Kernel 1 and a Kernel 2, respectively. These kernels are also hardware-independent, and are represented by high-level software code [… written in a general purpose programming language]”) [Examiner’s remarks: The generator is provided a set of operators (Op1 and Op2), implemented in a general purpose programming language (Kernel 1 and Kernel 2 are written in high-level software code.];
for each generator of the set of generators, performing operations comprising (Paragraph [0062], “Specifically, the diagram illustrates an example of the present method utilizing kernels and microkernels. Op1 and Op2 are both hardware-independent, meaning they are unaware of and unconcerned with which specific hardware component must implement the op in question. The ops are each implemented via a Kernel 1 and a Kernel 2, respectively [for each generator of the set of generators, performing operations comprising]”):
…
composing a kernel corresponding to the kernel generator based on the set of [executable] objects of the set of operations and the kernel parameterization (Paragraph [0062], “Specifically, the diagram illustrates an example of the present method utilizing kernels and microkernels. Op1 and Op2 are both hardware-independent, meaning they are unaware of and unconcerned with which specific hardware component must implement the op in question. The ops are each implemented via a Kernel 1 and a Kernel 2, respectively. These kernels are also hardware-independent, and are represented by high-level software code. This software code is also written in such a way that the hardware being used is unknown and not needed for implementation. Finally, each kernel calls one or more microkernels which implement an x86 CPU and an ARM CPU, respectively, in hardware-specific software code composing a kernel corresponding to the kernel generator based on the set of [executable] objects of the set of operations and the kernel parameterization]”) [Examiner’s remarks: The kernel is composed based on executable code of the operators (microkernels in hard-ware specific code) and kernel parameterization (microkernel based on target hardware type).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Jakubiuk into Vasilache to include “… written in a general purpose programming language”, “for each generator of the set of generators, performing operations comprising”, and “composing a kernel corresponding to the kernel generator based on the set of [executable] objects of the set of operations and the kernel parameterization”. As stated in Jakubiuk, “Operators and developers of AI networks are interested in making them as efficient as possible, on many possible hardware components and across many different hardware architectures. One challenge involved in this goal is that in order to run an AI network on a particular piece of hardware, it's necessary to support every op that particular AI network uses on that particular piece of hardware” (Paragraph [0007]). Creating customizable and composable kernels based on kernel parameterization and a given set of operations allows for more flexible and optimizable projects, with fewer requirements for human programming hours. Therefore, it would be obvious to one of ordinary skill in the art to combine customized kernels with kernel composition.
Vasilache discloses executable code. The combination of Vasilache and Jakubiuk does not explicitly disclose:
- the executable code being a binary object.
… the translating comprising accessing a set of regions of the each generator as parameter arguments, the set of regions comprising a body of code passed down and accessible to meta programming constructs;
However, Zinenko discloses:
- the executable code being a binary object (Page 2, “From a compiler practitioner’s point of view, it is interesting to realize that virtually all modern compiler solutions bottom-out on the LLVM compiler to produce optimized binaries”).
… the translating comprising accessing a set of regions of the each generator as parameter arguments, the set of regions comprising a body of code passed down and accessible to meta programming constructs (Page 3, “It offers a comprehensive collection of solutions to compiler construction challenges by: … (2) unifying compiler analyses and transformations across semantic domains through generic programming concepts such as operation traits and interfaces, (3) providing a declarative system for defining operations with nested regions, and domain-specific type systems”; Page 5, “Fig. 2. MLIR concepts in the generic format. MLIR has an open set of attributes, operations and types. Operations may recursively contain regions of blocks with further operations”; Page 6, “2.3.5 scf Dialect. The structured control flow scf dialect provides operations that represent looping and conditionals (e.g. regular scf.for and scf.while loops without early exit as well as an scf.if conditional construct) and embeds them into the SSA+regions form of MLIR. This is structured at a higher-level of abstraction than a control flow graph. Notably, scf loop operations may yield SSA values and compose well with other operations and dialects with either memory-based side-effecting semantics or SSA-based side-effect-free semantics”; Page 17, “Furthermore, in presence of a meta-programming dialect suitable for IR manipulation, it becomes possible to express the transformations entirely declaratively as yet another MLIR dialect. Optimizing transformations can be then stored, analyzed and transformed, and shipped separately from the main compiler. It provides a way to specify transformations and the units of IR they manipulate and produce, while enabling local pattern rewrites almost everywhere”, Page 19, “MLIR provides a set of bindings for Python that support IR creation and manipulation at a generic level.9 The infrastructure described in this paper aims to facilitate multi-level metaprogramming and drove the design of these bindings”; Page 36, “The affine dialect in MLIR addresses these long-standing issues. In particular, it maintains the IR in the same form — loops with additional constraints on how the bounds are expressed — throughout the compilation flow. It also embeds the polyhedral representation into the SSA form through attributes and regions, facilitating the combination of polyhedral and SSA-based transformations”) [Examiner’s remarks: Zinenko discloses a translation (transformation) of IR with a set of parameters including regions which represent blocks of code. Meta-programing may be used on units of IR. One of ordinary skill in the art understands that units of IR may include specified regions of IR.];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zanenko into the combination of Vasilache and Jakubiuk to include “a binary object” and “the translating comprising accessing a set of regions of the each generator as parameter arguments, the set of regions comprising a body of code passed down and accessible to meta programming constructs”. As stated in Zanenko, “This paper discusses a structured approach to the construction of domain specific code generators for tensor compilers, with the stated goal of improving the productivity of both compiler engineers and end-users. The approach leverages the natural structure of tensor algebra” (Abstract). Specifying code regions for translations may save time during translation and improve code access by only allowing metaprogramming on specified regions. Therefore, it would be obvious to one of ordinary skill in the art to combine customized kernels specified regions of translation.
Regarding claim 2, the rejection of claim 1 is incorporated; and Vasilache further discloses:
- wherein translating code of the each generator comprises lowering code of the each generator to a lower intermediate language (Page 5, last paragraph, “The Tensor Comprehensions workflow consists of several stages, progressively lowering the level of abstraction (Figure 2). Given a TC with specialized tensor sizes and strides, we lower it to a parametric Halide-IR expression, which is further lowered to a polyhedral representation where most transformations are applied [wherein translating code of the each operator comprises lowering code of the each generator to a lower intermediate language]”).
Regarding claim 3, the rejection of claim 1 is incorporated; and Vasilache further discloses:
determining the configuration of the each generator comprises:
- generating a set of configurations of the each generator based on the kernel parameterization and the intermediate representation of the each generator (Page 12, paragraphs 5-6, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation. The tuning session is defined by a list of parameters to tune and their admissible values, initial values, and the search strategy [generating a set of configurations of the each generator based on the kernel parameterization and the intermediate representation of the each generator]”) [Examiner’s remarks: A set of configurations (list of parameters) are generated for tuning the generator and run on polyhedral IR for JIT compiling.];
- generating an executable set of test functions based on the set of configurations (Page 13, paragraph 2, “Autotuning evaluates hundreds to thousands of versions for each kernel. We devise a generic multi-threaded, multi-GPU autotuner. It maintains a queue of candidates to compile with the polyhedral flow and a queue of compiled kernels ready to be profiled on the GPU (see Figure 4). Candidates or kernels are picked up by available worker threads and compiled or profiled concurrently. Profiling results are accumulated in the tuning database and used for setting up successive search steps [generating an executable set of test functions based on the set of configurations]”);
- executing the set of test functions to determine a set of respective performance scores (Page 13, paragraph 2, “Autotuning evaluates hundreds to thousands of versions for each kernel. We devise a generic multi-threaded, multi-GPU autotuner. It maintains a queue of candidates to compile with the polyhedral flow and a queue of compiled kernels ready to be profiled on the GPU (see Figure 4). Candidates or kernels are picked up by available worker threads and compiled or profiled concurrently. Profiling results are accumulated in the tuning database and used for setting up successive search steps [executing the set of test functions to determine a set of respective performance scores]”);
- selecting an optimal configuration of the set of configurations based on the set of respective performance scores (Page 12, Paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation”; Page 13, paragraph 3, “Because CUDA kernels cannot be stopped once launched, we rely on the following pruning heuristics to decrease the autotuning time by an order of magnitude. (1) Parameter specialization allows the exact number of active threads and blocks to be computed beforehand. Kernels with fewer threads than some configurable threshold (e.g., 256) are not launched. (2) If during the first run, a kernel is more than 100× slower than the best version so far, or it is 5× slower after warmup, it is pruned immediately [selecting an optimal configuration of the set of configurations based on the set of respective performance scores]”); and
- determining the configuration of the each generator based on the optimal configuration (Page 12, paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation [determining the configuration of the each generator based on the optimal configuration]”).
Regarding claim 4, the rejection of claim 3 is incorporated; and Vasilache further discloses:
- wherein generating the set of configurations is further based on a target machine parameterization (Page 12, paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation [wherein generating the set of configurations is further based on a target machine parameterization]”) [Examiner’s remarks: The configurations are generated which may be based on stored options based on target architecture (machine parameterization).].
Regarding claim 5, the rejection of claim 3 is incorporated; and Vasilache further discloses:
- wherein the set of test functions are executed on a plurality of machines (Page 14, paragraph 4, “We evaluate our framework on two systems: (1) Nvidia Pascal nodes with 2 socket, 14 core Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, with two Quadro P100-12GB; and (2) Nvidia Volta nodes with 2 socket, 20 core Intel(R) Xeon(R) CPU E5-2698 v4 @ 2.20GHz, with eight Tesla V100-SXM2-16GB. Both systems use CUDA 9.0 and cuDNN 7.0 [wherein the set of test functions are executed on a plurality of machines]”).
Regarding claim 6, the rejection of claim 3 is incorporated; and Vasilache further discloses:
wherein the performance scores include a set of an execution time and a loading time (Page 13, paragraph 3, “Because CUDA kernels cannot be stopped once launched, we rely on the following pruning heuristics to decrease the autotuning time by an order of magnitude. (1) Parameter specialization allows the exact number of active threads and blocks to be computed beforehand. Kernels with fewer threads than some configurable threshold (e.g., 256) are not launched. (2) If during the first run, a kernel is more than 100× slower than the best version so far, or it is 5× slower after warmup, it is pruned immediately [wherein the performance scores include a set of an execution time and a loading time]”) [Examiner’s remarks: Performance scores take into account execution time (being too slow) and loading time (warmup time).].
Regarding claim 7, the rejection of claim 3 is incorporated; and Vasilache further discloses:
wherein generating the set of test functions comprises:
for each configuration of the set of configurations, performing operations comprising (Page 12, Paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation [for each configuration of the set of configurations, performing operations comprising]”):
- selecting a library of generators from a set of libraries based on the each configuration (Page 12, paragraph 2, “While TC aims at generating code for any computational kernel expressible in the DSL, if (part of) a kernel happens to match a pattern that is heavily optimized by some library, then it may as well be handled by that library. In particular, and as a proof of concept, TC looks for opportunities for letting CUB handle specific forms of reductions. It is currently restricted to single-dimensional addition reductions [selecting a library of generators from a set of libraries based on the each configuration]”); and
- generating a test function of the set of test functions based on the selected library and the each configuration (Page 12, paragraph 5, “Different kernels need different, target-specific optimization trade-offs. We thus complement our flow by an autotuner that varies the options of the polyhedral JIT compiler marked as tunable in the previous section. These options can be stored and reused for similar operations/kernels (similar shapes, target architecture), since autotuning may require significantly more time than compilation [generating a test function of the set of test functions based on the selected library and the each configuration]”).
Claims 8-14 are apparatus claims corresponding to the method claims hereinabove (claims 1-7 respectively). Therefore, claims 8-14 are rejected for the same reasons as set forth in the rejection of claims 1-7, respectively.
Claims 15-20 are machine-storage medium claims corresponding to the method claims hereinabove (claims 1-6, respectively). Therefore, claims 15-20 are rejected for the same reasons as set forth in the rejection of claims 1-6, respectively.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights