DETAILED ACTION
This final office action is responsive to application 18/352,784 with applicant’s amendments and request for reconsideration as submitted 29 July 2026.
Claim status is currently pending and under examination for claims 1-2, 4-11, 13-18 and 20-23; claims of independent form are 1, 10 and 20; amended claims are 1, 4-11, 13-18 and 20; cancelled claims are 3, 12 and 19; newly presented are claims 21-23.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Remarks
Examiner thanks applicant for responsive remarks filed 07/29/26 which are considered together with amendments on the issues as follows:
Objection to the specification and claims are withdrawn as necessitated by amendments.
The rejection of claims 1-19 under 35 U.S.C. 112(b) are hereby withdrawn as necessitated by applicant’s amendments made to the claims.
The rejection of claim 20 under 35 U.S.C. 101 as directed to non-statutory subject matter is overcome by amendment.
Applicant’s remarks regarding the prior art have been considered, but they are moot in view of the new grounds of rejection as necessitated by applicant’s amendments. Updated search identifies additional prior art references of at least Graf and Dooley applied below. Dooley, of Tenstorrent, is similar to Abts, of Groq (instant applicant), which is applied to newly presented dependent claims. Examiner respectfully submits that these identified references provide the skilled artisan with teachings sufficient to arrive at the invention as claimed. Therefore, an updated rejection under 35 U.S.C. 103 is detailed below.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 10-11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over: Graf, Alexander “Compiler Backend Generation using the VADL Processor Description Language” hereinafter Graf, in view of Dooley et al., US PG Pub No 2023/0051122A1 hereinafter Dooley (Tenstorrent, Toronto), in view of Zhu et al., “ROLLER: Fast and Efficient Tensor Compilation for Deep Learning” hereinafter Zhu (Usenix, Univ. of Toronto).
With respect to claim 1, Graf teaches:
A system {Graf [P.1 ¶1] “processor design” cont’d [P.2 ¶2] “Aim of this work… hardware model will be generated” for a processor/hardware system} comprising:
a composer that generates a plurality of operation information tables respectively corresponding to a plurality of functional units and generates a general chip model (GCM) specifying a spatial arrangement of the plurality of functional units based on the plurality of operation information tables {Graf [P.11 ¶2] “TableGen files. These files, together with the rest of the components provided by the framework, are composed to the final compiler” specifically [P.29-30 Sect.4.2.2] “TableGen files have the ‘td’ extension… td files to form a target and processor model” model of processor/chip is (GCM) formed from the TableGen(erated) files that specify target registers, call function arguments and operation instructions, see e.g. [P.10 ¶3] “functional units that work in parallel” and more particularly [P.45-49] Listings 4.9–4.16 define the functions of TableGen with values loaded from addressed memory for hardware registers which may be arranged by group as a register class, spatial arrangement may comprise location such as relocation [P.25 ¶3], [P.60 ¶3], noting at least some spatial arrangement is requisite in a physical hardware system. Additionally see [P.33,44] Fig 4.1 and Alg 4.1 which employs a DAG - directed acyclic graph}; and
the composable processor architecture providing for selectively setting values for one or more hardware design parameters {Graf [P.48] Listings 4.14-15 “assigning the values to a list of registers” as “assigning function parameters of a certain type to argument registers” assigning is selectively setting, assigned to hardware registers as noted Listing 4.11, introduces [P.3 ¶2] “creating new and enhanced processor architectures. By allowing rapid design exploration”}.
However, Graf does not prima facie make clear how the spatial arrangement of functional units is specified.
Dooley supports this with teachings to cure any such deficiency. Particularly, Dooley at Fig 2 functional processing units 201, 102 and 202 shown in layout with relation to the registers in area of execution by processor 100 - related Figs 1 and 5. Spatial arrangement is specified where [0021] “registers can be located proximate the functional processing unit” disclosing that functional processing units may be “arranged” in parallel or pipeline [0019], and noting [0052] “functional processing units 501 and 502 could be connected to the same pipeline stage in the processor, could be in sequence in a systolic array paradigm, and/or could be mutually connected to a set of staging registers” emphasis connected i.e. connectivity between functional units and registers that are located proximate. This arrangement is similar to instant drawing Fig 11 showing connectivity between the FU - functional units and SR - streaming registers.
Dooley Fig 2 Instant Fig 11
PNG
media_image1.png
1132
1090
media_image1.png
Greyscale
PNG
media_image2.png
952
1294
media_image2.png
Greyscale
Dooley is directed to processor design in the hardware space with composite instructions for compilers thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify spatial arrangement for functional units per Dooley in combination with Graf for a motivation being that [0019] “The functional processing units can take on various forms and be arranged in various ways on the processor…arranged entirely in parallel or in a computation pipeline” with “benefit of pre-staging instructions, that will be repeatedly executed, will repeatedly save the time and energy associated with fetching the instructions from memory regardless of the size of the execution area… specialized functional processing units and sets of functional processing units are possible depending upon the application for which the processor is designed. For example, the functional processing units could form a graphics rendering pipeline or a systolic array for dense linear algebra.”
However, the combination of Graf and Dooley does not expressly disclose machine learning for the models to include machine learning models which is disclosed by Zhu:
a compiler that compiles a machine learning model for execution by a composable processor architecture defined by the GCM {Zhu [P.235 Sect.3 ¶1] “DNN compiler” for the DNN models Fig 2, introduced [P.233 ¶1] “DNN model are abstracted as operators and implemented as kernels, executed on modern accelerators”, compiler described [P.239 ¶2] “ROLLER’s compilation pipeline is as follows. Its input is an ONNX graph… and generates corresponding rProgram by ROLLER’s construction algorithm” whereby [P.234 ¶3] “rProgram that saturates a single execution unit of the accelerator (e.g., an SM, a streaming multi-processor in a NVIDIA GPU)” is execution by processor, the processor’s architecture [P.239 Last2¶] “GPUs with different architectures on the streaming multi-processors” and composable is suggested as scaling [P.237 ¶4 – P.238 ¶2] the scaling leverages parallelism through replication and enlarging tiles. Zhu also considers Graphcore-IPU architecture [P.240 ¶3]} and
generates a compiled program for execution on a processor having the composable processor architecture {Zhu see [P.235 Sect.3 ¶1] “generate efficient tensor programs (named rProgram)… generating rProgram” simply rProg() Alg.1 Lines4-5 of Fig 8, also Figs 7a, 6, 2, compiled per [P.239 ¶2] “ROLLER’s compilation pipeline is as follows. Its input is an ONNX graph… and generates corresponding rProgram by ROLLER’s construction algorithm” whereby [P.234 ¶3] “rProgram that saturates a single execution unit of the accelerator (e.g., an SM, a streaming multi-processor in a NVIDIA GPU)” is execution by processor, the processor’s architecture [P.239 Last2¶] “GPUs with different architectures on the streaming multi-processors” and composable is suggested as scaling [P.237 ¶4 – P.238 ¶2] the scaling leverages parallelism through replication and enlarging tiles. Zhu also considers Graphcore-IPU architecture [P.240 ¶3]},
Zhu is directed to GPU hardware aligned optimization for accelerators with composed computations thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to compile DNNs for generated program as per Zhu for the processor model of Graf supported by Dooley in combination to arrive at the invention as claimed for a motivation of [P.234 ¶4] “speeding up the compilation process” with [P.237 ¶3] “the optimization goal of the corresponding rProgram is to maximize the throughput… computation and memory movement should leverage the hardware features” and scales out by [P.238 ¶2] “distributing all the partitions evenly to all execution units… the system can explicitly control the parallelism of a rProgram when scaling out.”
With respect to claim 2, the combination of Graf, Dooley and Zhu teaches the system of claim 1, wherein
the composer comprises a hardware composer {Graf [P.46] “hardware encoding” Listing 4.11 provides example, thereby [P.11 ¶3] “composed of a specification of the hardware resources” see e.g. Fig 4.1-top, processor description, entails processor model [P.26 ¶1] or [P.30 ¶1]}.
Claim 3 (Cancelled).
With respect to claim 10, the rejection of claim 1 is incorporated. The scope being broader without final limitation of selectively setting, and differing as a method to perform limitations of system claim 1. Graf discloses [P.28 ¶5] “steps of the compiler backend” hence title, with algorithmic implementation [P.44]. The remainder of this claim is rejected for the same rationale as claim 1.
With respect to claim 11, the combination of Graf, Dooley and Zhu teaches the method of claim 10, and further teaches the limitation of claim 2. Therefore, the rejection of claim 2 is applied to claim 11.
Claim 12 (Cancelled).
Claim 19 (Cancelled).
With respect to claim 20, the rejection of claim 1 is incorporated. The scope being broader without final limitation of selectively setting, and differing as a non-transitory machine-readable storage medium comprising instructions executable by processor to perform operations of system claim 1. Graf discloses [P.64] “software and hardware components that were used” Table 5.1 includes CPU, memory is replete e.g. [P.16 Last¶], [P.45 Last¶]. The remainder of this claim is rejected for the same rationale as claim 1.
Claims 4, 13 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over: Graf, Dooley and Zhu in view of Sankaralingam et al., “The Mozart Reuse Dataflow Processor for AI and Beyond” hereinafter Sankaralingam.
With respect to claim 4, the combination of Graf, Dooley and Zhu teaches the system of claim 1. Sankaralingam teaches wherein
the plurality of operation information tables represents operational characteristics of a respective functional unit {Sankaralingam [P.983 ¶1] discloses lookup table for managing global address space partitioned over compute array to perform matrix operations [P.980 Sect. 2.3], matrix and array of row/column also represent table structures. More particularly, see [P.986 ¶4] “timing of operands for functional units” teaches respective functional units where the operational characteristics is a timing. This is consistent with instant specification [0086-87], [0091-91] “timing characteristics”}.
Sankaralingam is directed to processor execution modeling for deep learning workloads with compiler thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to include timing for functional units as operand characteristics per Sankaralingam in combination to arrive at the invention as claimed for stated motivation [P.988 ¶3] “key motivation of the architecture was to expose reuse behavior and achieve as much low-latency” emphasis low-latency as a timing characteristic where [P.986 ¶4] “scheduler is a key intellectual aspect …matching the timing of operands for functional units”. See contributions [P.979 ¶3-4].
With respect to claim 13, the combination of Graf, Dooley and Zhu teaches the method of claim 11, and further combination with Sankaralingam teaches the limitation of claim 4. Therefore, the rejection of claim 4 with equal motivation is applied to claim 13.
With respect to claim 23, the combination of Graf, Dooley and Zhu teaches the system of claim 1. Sankaralingam teaches wherein
the composer aggregates a subset of the plurality of functional units into a functional unit group, wherein each functional unit in the functional unit group is of a shared component type and shares instruction timing characteristics {Sankaralingam [P.984 Sect.3.3 ¶2] “array of functional units interconnected by a circuit-switched, software re-configurable network. The configuration is produced by a scheduler” where [P.986 ¶4] “scheduler is the key intellectual aspect…matching the timing of operands for functional-units and ports” ports are components of the functional unit array termed CSCA shown Fig 5(b), the array is a group of functional units for tiling Fig 5(a) similar to instant [0052], the aggregation may comprise accumulator [P.986 ¶5], [P.980 ¶1-2], and/or operator fusion [P.987 ¶2,1] to support recurrence stream [P.984 Sect. 3.3 ¶4]. See also Figs 7, 2 and 1}.
Sankaralingam is directed to processor execution modeling for deep learning workloads with compiler thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify functional units with the teachings of Sankaralingam in combination to arrive at the invention as claimed for a stated motivation [P.988 ¶3] “key motivation of the architecture was to expose reuse behavior and achieve as much low-latency execution as possible without needing an embarrassing parallelism” with further benefit [P.987 ¶2] “we can perform arbitrary specialized computation like Softmax, ERF and others using the CSCA array without any hardware functional unit specialization” using a scheduler as key aspect [P.986 ¶4]. See contributions [P.979 ¶3-4] as well as Sankaralingam’s consideration of Groq’s Think Fast by Abts [P.989 Last2¶].
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Graf, Dooley, Zhu and Sankaralingam in view of Zhang “Towards Automatic and Agile AI/ML Accelerator Design with End-to-End Synthesis” and further in view of Jin et al., “Compiling ONNX Neural Network Models Using MLIR” hereinafter Jin (arXiv: 2008.08272v2)
With respect to claim 5, the combination of Graf, Dooley, Zhu and Sankaralingam teaches the system of claim 4. Zhang teaches wherein
the plurality of operation information tables comprise cost, {Zhang [P.222 ¶2] “generate a custom TableGen… then integrate the specialized functional units” particularly comprising [P.219 Last¶] “cost, size and cooling requirements” multi-objective optimizations of the soda-compiler framework Fig 2, further discloses [P.220 ¶2] “custom instruction set architecture (ISAs)” e.g. Fig 5}.
Zhang is directed to hardware synthesis and design with compilers and machine learning models thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to include cost and cooling requirements for TableGen files integrating functional units per Zhang in combination for a motivation being that [P.219 Last¶] “different optimization parameters will influence the final hardware designs generated by the SODA Synthesizer. Thus, there is a need to explore the accelerator designs space…implements a pluggable set of multi-objective optimization algorithms… efficient design space exploration obviously depends on obtaining accurate results from the evaluation of generated designs” and [P.221 Last2¶] “functional units also need to be characterized, at least in terms of performance (e.g. latency of the critical path) and area of the target technology of choice… we can further optimize the circuit design, applying techniques like chaining of functional units” e.g. [P.222 ¶4] “speculative functional units… speculate on the result of the arithmetic operations (for example, not considering the carry bits in additions), thus potentially allowing to reach higher degrees of parallelism and higher frequencies (or reduced power).”
However, Zhang in combination does not disclose skew which is disclosed by Jin.
Particularly, Jin at [P.6 Last2¶] “skew…using tablegen records” described for schedules that are composable and Listing 6 at top of page details TableGen definitions, such that “If users want to define custom declaration in the class, it can be done via the ‘extraClassDeclaration field (Line 7)”
Jin is directed to neural compilers for target hardware using TableGen thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to include skew using the custom class declaration in TableGen per Jin in combination with Zhang to arrive at the invention as claimed because known work in one field may prompt variations of it in the same field based on design incentives if the variations are predictable the skilled artisan. Here, the skilled artisan is given a tool for customizing information to be included in TableGen files and gives a design incentive that points to composable schedules [P.6 Last2¶] and further notes the ability to carry out optimizations over transformations including skew [P.4 ¶3], [P.5 ¶2].
With respect to claim 14, the combination of Gra, Dooley, Zhu, and Sankaralingam teaches the method of claim 13, and further combination with Zhang and Jin teaches the limitation of claim 5. Therefore, the rejection of claim 5 with equal motivation is applied to claim 14.
Claims 6, 9, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Graf, Dooley and Zhu in view of Li et al., “Compiler-Driven Simulation of Reconfigurable Hardware Accelerators” hereinafter Li (arXiv: 2202.00739v1).
With respect to claim 6, the combination of Graf, Dooley and Zhu teaches the system of claim 2. Li teaches wherein
the hardware composer generates a value for the one or more hardware design parameters of the composable processor architecture by selectively adding additional resources to the composable processor architecture or reducing selected resources that are under-utilized when a selected model is being compiled by the compiler {Li discloses [P.2 Sect. II.A ¶1-2] “define the hardware resources that make up an accelerator…instantiate components like processing elements (PEs) and memories” where [P.8 Rt.Col] “each PE reads a value, modify and writes to a neighbor PE” thus PEs generate values, and selectively add [P.2 Sect. II.A ¶2] “add_comp to add” Fig 2, or [P.12 ¶1] “reduce the 16 processors to 4” Fig 2 shows Reg, SRAM and PE structure declarations with EQueue program, further employs AI engine for deep learning computations [P.2 ¶2], [P.11-12] code ai_eng, and generates systolic array architecture using MLIR compiler [P.7 Sect.B] or [P.2 ¶1]}.
Li is directed to compilers for hardware accelerator design thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify hardware resources according to the teachings of Li in combination to arrive at the invention as claimed for a motivation [P.8 ¶2] “Benefits. EQueue programs can modularize hardware components (e.g., SRAM interfaces and processors) and thereby study the individual effect of a components… allows a programmer to concentrate on architecture design” e.g. [P.2 ¶2-3] “designers can easily switch among different architectures for the same computation… EQueue’s flexibility can guide designers to improve their designs on a real-world reconfigurable architecture” and helps to [P.5 SectV.B] “avoid waste or increase computation utilization.”
With respect to claim 9, the combination of Graf, Dooley, Zhu and Li teaches the system of claim 6, wherein
the hardware composer generates a value for the one or more hardware design parameters of the composable processor architecture based on a preconfigured processor architecture selected from a library {Li [P.6 ¶2] “library of components, such as SRAM memories and processors. Designers can extend the library with custom components to introduce custom simulation logic… users can specify arbitrary behavior for components in EQueue programs” customized to designer’s configuration choice from library of template components using [P.7 ¶2,4] “generator that emits EQueue code to model systolic array architectures… generator to pass values systolically between PEs” are the generated values of the [P.1 ¶3] “generated architectures”}. Motivation for combination is applied similarly as in claim 6.
With respect to claim 15, the combination of Graf, Dooley and Zhu teaches the method of claim 11, and further combination with Li teaches the limitation of claim 6. Therefore, the rejection of claim 6 with equal motivation is applied to claim 15.
With respect to claim 18, the combination of Graf, Dooley and Zhu teaches the method of claim 11, and further combination with Li teaches the limitation of claim 9. Therefore, the rejection of claim 9 with equal motivation is applied to claim 18.
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Graf, Dooley, Zhu and Li in view of Yang et al., “Co-Exploration of Neural Architectures and Heterogeneous ASIC Accelerator Designs Targeting Multiple Tasks” hereinafter Yang (arXiv: 2002.04116v1).
With respect to claim 7, the combination of Graf, Dooley, Zhu and Li teaches the system of claim 6. Yang teaches wherein
the hardware composer generates a respective layer processor architecture for each layer of the machine learning model {Yang [P.2] Fig 2 accelerator synthesis for neural network layers, described [P.3 Sect.III Rt.Col] “we map network layers to sub-accelerators… A map function map(li,j) = aick is defined, which indicates the jth network layer li,j in the ith DNN Di to be mapped to the kth sub-accelerator aick. Based on the mapping, we determine the execution order of the layers on sub-accelerator aick following a schedule function sch(aick) …mapping and scheduling of each layer” respectively as corresponding [P.4 Rt.Col] “pair of network layer ∀li ∈ L and sub-accelerator aicj”}.
Yang is directed to co-exploration of neural networks with hardware design thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify layers mapped to processors per Yang to arrive at the invention as claimed for motivation [P.4 ¶5,8] “explore the best hardware for a previous identified neural architecture …for mapping and scheduling, we need to obtain the latency and energy of each layer” in other words the hardware performance (latency, energy) is based on DNN layer-by-layer evaluation.
With respect to claim 8, the combination of Graf, Dooley, Zhu, Li and Yang teaches the system of claim 7, wherein
the respective layer processor architecture for each layer of the machine learning model is manufactured as a semiconductor processor for executing the model {Yang [P.2] Fig 2 illustrates Synthesis yielding Resultant Accelerator with NN layers where synthesis corresponds to manufacture, the accelerator or sub-accelerator includes ASIC as a semiconductor for processing and DNN layers are mapped for scheduled execution, see [P.2-3 Sect.III], and [P.4 Rt.Col] paired layer and sub-accelerator, see also Figs 3, 5}.
A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to synthesize per Yang to arrive at the invention as claimed for a motivation being [P.2 ¶4-5] “ASIC designs grant the maximum flexibility to designers to determine the hardware organization… enables the co-exploration of neural architectures and ASIC designs by incorporating hardware allocation” and such that the neural architectures of DNN layers provides resultant accelerator based on maximum accuracy of DNNs with corresponding hardware constraints e.g. latency and energy [P.3 ¶9].
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Graf, Dooley and Zhu in view of Yang.
With respect to claim 16, the combination of Graf, Dooley and Zhu teaches the method of claim 11, and further combination with Yang teaches the limitation of claim 7. Therefore, the rejection of claim 7 with equal motivation is applied to claim 16.
With respect to claim 17, the combination of Graf, Dooley and Zhu teaches the method of claim 11, and further combination with Yang teaches the limitation of claim 8. Therefore, the rejection of claim 8 with equal motivation is applied to claim 17.
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over: Graf, Dooley and Zhu in view of Abts et al., “Think Fast: A Tensor Streaming Processor (TSP) for Accelerating Deep Learning Workloads” hereinafter Abts (Groq).
With respect to claim 21, the combination of Graf, Dooley and Zhu teaches the system of claim 1. Abts teaches wherein
the one or more hardware design parameters comprise at least one of: a vector length of vector instructions supported by a given functional unit type, a number of stream register paths (SRPs), a number of stream registers within a stream register file (SRF), or a location of a functional unit group along a stream register path (SRP) {Abts [P.151 Sect.F] “vector length (VL) can vary from 16 to 320 elements” for [P.152 ¶4] “filling the IQ with 640-bytes (a pair of 320-byte vectors) of instructions” describes fetching instructions with functional slices which comprise functional units per [P.146 ¶2,4] “heterogeneous collection of functional units… different function types”. Additionally see [P.147 ¶4] “streaming register file (SR)” paths of which are between locations being specified per [P.151 Sect.III] “from stream register location i (SRi) to j (SRj)” … SRi (stream register at location i in Figure 4) en route to the consumer at SRj” i.e. (SRP) is from SRi to SRj streaming register locations. See Figs 4-5 and 1-3}.
Abts is directed to processor models with compiler and composite functions thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify vector length per Abts in combination to arrive at the invention as claimed for a motivation [P.151 Sect.F] “scalable vector approach allows us to grow the VL …powering-down the unused tiles, yielding a more energy-proportional system” or employ streaming registers with associated files, paths and locations for a motivation [P.151 Sect.III] “TSP programming model relies on two critical elements: (1) deterministic data paths in hardware, and (2) exposing temporal information about an instruction’s execution latency through the ISA, the compiler’s back-end can precisely track the position and time-of-use of any stream on-chip… giving rise to ‘software-defined hardware.’”
With respect to claim 22, the combination of Graf, Dooley and Zhu teaches the system of claim 1, wherein
the spatial arrangement specifies connectivity of the plurality of functional units to a stream register path (SRP) comprising a chain of stream register files (SRFs), each SRF tracking a local cost value representing a travel time across a respective stream register, wherein an accumulating travel time indicator (TZIDX) defines relative instruction execution timing between functional units at compile time {Abts [P.149 Sect.A ¶2] “Fig. 4 provides a graphical depiction of the interleaving of functional units and stream registers” interleaving is connectivity between FU and SR respectively functional units and stream registers, the path of which is between locations specified [P.151 Sect.III] “from stream register location i (SRi) to j (SRj)” … SRi (stream register at location i in Figure 4) en route to the consumer at SRj” i.e. (SRP is from SRi to SRj). SRF is introduced [P.147 ¶4] “streaming register file” where plurality may comprise where [P.156 ¶2] “each compute cluster has access to its own bank of a stream register file”. TZIDX is Eq.4 [P.151 Sect.III] where T is time and dfunc denotes functional delay and δ is transit delay, described for compiler “allow the compiler precise control of each instruction’s dispatch time… compiler’s back-end can precisely track the position and time-of-use of any stream on-chip”}.
Abts is directed to processor models with compiler and composite functions thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify vector length per Abts in combination to arrive at the invention as claimed for motivation [P.146 ¶1] “computational elements are arranged spatially by function to take advantage of dataflow locality” with consideration that [P.151 Sect.III] “TSP programming model relies on two critical elements: (1) deterministic data paths in hardware, and (2) exposing temporal information about an instruction’s execution latency through the ISA, the compiler’s back-end can precisely track the position and time-of-use of any stream on-chip… giving rise to ‘software-defined hardware’” and generally [P.153 Last2¶] “As a broad objective, the model implementation seeks to maximize functional slice utilization, and minimize latency. This means we want to take advantage of streaming operands.”
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Bajic et al., US PG Pub No 2023/0196124 Tenstorrent see Fig 2:210 shows neural compiler assignment to cores [0046]
Tenstorrent family: Grayskull/Tensix and Wormhole architectures disclosed in references: Vasiljevic et al., “Compute Substrate for Software 2.0” and Ignatovic et al., “The Wormhole AI Training Processor”
Lucia et al., US PG Pub No 2022/0244965A1 Carnegie Mellon [0062] “arbitrary FUs” integrated with PE array through CGRA Figs 1-4, “bring your own functional unit” with [0057] “compiled SRAM” and spatial vector execution [0013]
Tang et al., US Patent No 11,868,304B1 Meta, LUT accelerator with generated cost table
Lattner et al., “MLIR: A Compiler Infrastructure for the End of Moore’s Law” arXiv: 2002.11054v2 Google compiler discloses TableGen
Joseph et al., US PG Pub No 2024/0256239A1 Google hierarchical compiler, TPU accel.
Yu et al., “NN-LUT: Neural Approximation of Non-Linear Operations for Efficient Transformer Inference” arXiv: 2112.02191v1 Figs 1,3 accel. core runs BERT, neural network lookup table
Yu, Douglas “TSMC Packaging Technologies for Chiplets and 3D” overview slides, cooling
Ahmed et al., US PG Pub No 2023/0409882A1 tensor streaming processor, provisional filing based on Answer Fast, the follow-up to Think Fast (Abts)
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 Chase P Hinckley whose telephone number is (571)272-7935. The examiner can normally be reached M-F 9:00 - 5:00.
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, Miranda M. Huang can be reached at 571-270-7092. 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.
/CHASE P. HINCKLEY/Examiner, Art Unit 2124
