DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The objection to the claims and the specifications have been withdrawn in view of the amendments filed on 09/08/2026.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 6, 8-12, 16, 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (U.S. Doc. No. 11321606) in view of Van Eijndhoven et al. (U.S. Doc. No. 9081928).
Regarding claim 1, Sharma discloses a method for evaluating (col 24, ” Below, this specification describes a novel method for analytically calculating the optimal breakdown of the platform resources 3140 for the exemplary architecture presented in 2000.”; also, col 25, “In one implementation, the scheduler step 3113 evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available.”) a hardware accelerator, the method comprising (col 1, “For one embodiment of the present invention, a hardware accelerator with a heterogenous architecture for training quantized neural networks is described.”; also, col 6, “The accelerator may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine or a device), or a combination of both.”; also, col 14, “In reality, however, even quantized DNNs have a large memory footprint and hence performance of the generated FPGA accelerator depends both on the breakdown of the FPGA's resources and the organization of on-chip memory.”): generating a data processing graph (col 12, “the DNN workflow begins with a programmer defining a Dataflow Graph (DFG) of the DNN using a high-level API”; also, col 23, “the workflow 3100 begins with the programmer defining the DataFlow Graph (DFG) of the neural network in step 3110”) for describing at least one algorithmic operation (col 12, This API allows the programmer to specify the precision for each operation in the DNN.”; also, col 13, “This operation 1010a includes the dataflow analyzer component iterating over the nodes of the dataflow graph of the DNN and generates a list of pairs (e.g., operation type, precision, operation count) for the forward and backward passes of training.”); evaluating a complexity (col 13, “This operation 1010a includes the dataflow analyzer component iterating over the nodes of the dataflow graph of the DNN and generates a list of pairs (e.g., operation type, precision, operation count) for the forward and backward passes of training.”; also, col 23, “"The first part 3120 of the DFG analysis 3111 is to analyze the number and type of computations by the Neural Network.”) and a performance of the data processing graph (col 1, “The processor is configured to perform a dataflow analysis operation to analyze resource requirements for a dataflow graph of a neural network (NN) model, to perform a resource partitioning operation to analytically split resources of a hardware accelerator, to perform a cycle-accurate scheduling operation to obtain cycle counts for forward and backward passes of the dataflow graph, and to generate a synthesizable hardware accelerator using an optimal resource breakdown.”; also, col 12-13, “As shown in the FIG. 10, this workflow includes four operations: (1010) a dataflow analysis operation to analyze the resource requirements for the dataflow graph, (1020) a resource partitioning operation to analytically split the FPGA's resources, (1030) a cycle-accurate scheduling operation to obtain cycle counts, and (1040) a builder operation to generate a synthesizable accelerator using the optimal resource breakdown from operation 1030.”; also, col 25, “The scheduler generates the cycle counts for Q-array 2010 and MP-array 2020.”; also, col 25, “In one implementation, the scheduler step 3113 evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available.”) using a complexity metric (col 13, “In one example, the operation type is a type of scalar operation (e.g., multiply, add, etc), the precision field is a tuple of the data-types required by the operands (e.g., fixed-point, floating-point, or power-of-2), and the operation count field describes the number of scalar operations.”) and performance metric (col 24, “Next, the resource partitioning component optimizes the ideal number of cycles required by the forward and backward operations given by the following equation:”; also, col 25, “Using the cycle-counts, the scheduler updates the compute ratio c defined in Equation [5] as follows.”), wherein the evaluating evaluates a) a number of operations used in the at least one algorithmic operation for the data processing graph (col 23, “The first part 3120 of the DFG analysis 3111 is to analyze the number and type of computations by the Neural Network.”; also, col 23, “To this end, the dataflow analyzer component iterates over the nodes of the dataflow graph of the Neural Network and generates a list of (operation type, precision, operation count) pairs for the forward propagation and backward propagation phases of training.”; also, col 23, “The operation type is the type of scalar operation (multiply, add, etc), the precision field is a tuple of the data-types required by the operands (fixed-point, floating-point, or power-of-2), the operation count field describes the number of scalar operations.”) against b) the performance of the data processing graph (col 25, “Here, the c term in Equation 5 is the ratio of non-zero computations in the backward pass to the non-zero computations in the forward pass, and r term in Equation 6 is the one minus the ratio of resources required for the backward pass to the resources required by the forward pass.”; also, col 1, “The processor is configured to perform a dataflow analysis operation to analyze resource requirements for a dataflow graph of a neural network (NN) model, to perform a resource partitioning operation to analytically split resources of a hardware accelerator, to perform a cycle-accurate scheduling operation to obtain cycle counts for forward and backward passes of the dataflow graph, and to generate a synthesizable hardware accelerator using an optimal resource breakdown.”; also, col 24, “Next, the resource partitioning component optimizes the ideal number of cycles required by the forward and backward operations given by the following equation:”; also, col 25, “In one implementation, the scheduler step 3113 evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available.”; also, col 25, “Using the cycle-counts, the scheduler updates the compute ratio c defined in Equation [5] as follows.”; also, col 26, “The scheduler then feeds back the updated compute ratio to the resource partitioner step 3112.”); data processing graph based on set constraints, and the evaluated complexity and the performance to generate multiple data processing graphs; evaluating the multiple data processing graphs using the complexity metric and the performance metric; and selecting at least one optimal graph from among the multiple data processing graphs for design of the hardware accelerator.
However, in a similar field of endeavor, Van Eijndhoven discloses modifying the data processing graph (col 22, “A transformation implementation step 2320 discussed in more detail below executes the transformation commands 2319 on a seed design 2298.”; also, col 28, “The original loop as shown in FIG. 18(a) in the CDFG is first unrolled twice, i.e., the loop nodes are duplicated.”; also, col 28, “Clearly, such CDFG transformation must maintain the original code functionality.”) based on set constraints (col 17, “Transformation step 2200 identifies a bottleneck in a seed design 2298 that is selected from the seed pool 2499. The selection is based on the user-specified design constraints 2001 and the area and delay estimates of the seed design.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”), and the evaluated complexity and the performance (col 17, “Transformation step 2200 identifies a bottleneck in a seed design 2298 that is selected from the seed pool 2499. The selection is based on the user-specified design constraints 2001 and the area and delay estimates of the seed design.”; also, col 22, “Also, a new transformation may be defined in step 2310 based on the results 2399 of a previous transformation.”; also, col 17, “The estimator 2100 uses the CDFG 1157 and the execution counts of loop bodies and instructions in the tree 1299 to estimate the delay of each tree node.”; also, col 17, “An estimator 2100 estimates various characteristics of each of the design alternatives 2999 for a given target architecture.”; also, col 17, “The remainder of this document refers only to area and delay as characteristics or optimization targets of a design.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”) to generate multiple (col 17, “The design transformation process 2000 transforms the initial design 1999 as produced by the analysis step 1000 into multiple design alternatives 2999, each with different area and delay trade-offs.”; also, col 7-8, “These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”) data processing graphs (col 8, “As shown in FIG. 7, a design is a data structure containing information about a computer program and its mapping to an embedded system that consists of three top-level parts: application 9100, mapping 9200, and architecture 9300.”; also, col 8, “The application 9100 in FIG. 8 links a CDFG 9110, a tree 9120, and a process network 9130.”; also, col 8-9, “In the initial design 1999, these would be CDFG 1157, tree 1299 and process network 1803.”; also, col 9, “A design such as shown in FIG. 8 would only be obtained after several transformation operations as discussed below.”; also, col 17, “Each design alternative contains a variation of the initial program 996 that takes particular area and delay trade-offs into account.”; also, col 8, “A control-dataflow graph 1157 (abbreviated CDFG) captures the static structure of the program 996.”; also, col 28, “The original loop as shown in FIG. 18(a) in the CDFG is first unrolled twice, i.e., the loop nodes are duplicated.”; also, col 28, “Clearly, such CDFG transformation must maintain the original code functionality.”); evaluating the multiple data processing graphs (col 17, “An estimator 2100 estimates various characteristics of each of the design alternatives 2999 for a given target architecture.”; also, col 22, “Thereto, an estimator 2100 updates the delay and area estimates of the transformed design 2329. If the resulting design 2339 is a pareto point with respect to the design alternatives 2399, it is added to the design alternatives 2399, otherwise it is discarded.”) using the complexity metric and the performance metric (col 17, “The remainder of this document refers only to area and delay as characteristics or optimization targets of a design.”; also, col 29, “The location of these points is given by the value of characterizing quantities of the design they correspond to. Examples of these quantities are area, delay, power consumption and monetary cost.”); and selecting at least one optimal graph from among the multiple data processing graphs (col 8, “In the selection step 3000 the design alternatives 2999 are presented for comparison to allow for user selection of the most optimal design.”; also, col 28, “This design space view 3001 allows the user to conveniently select a design 3999 of his choice.”; also, col 29, “A pareto point 3004 is a design point which is not strictly dominated by another design point. This means that each pareto point represents a design that is the best choice in the design space close to that point.”; also, col 18, “It then iteratively optimizes this design by selecting the design alternative with the lowest delay and adding this design alternative to the seed pool 2499 for the next optimization. Each intermediate pareto point is added to the design alternatives 2999.”) for design of the hardware accelerator (col 8, “In the build step 4000 the selected design is mapped to a combination of software and hardware that represents the desired embedded system 4999.”; also, col 32, “The input design 4199 specifies that some sections of its program are to be mapped into a function-specific hardware accelerator structure.”; also, col 32, “Accelerator generator 4300 converts each such program section into RTL code, which is the low-level specification of the accelerator to be implemented.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma's invention of a method for evaluating a hardware accelerator in which a programmer defines a dataflow graph of the algorithm to be accelerated, in which the dataflow analyzer counts the operations of that graph and the resource partitioner and scheduler evaluate that operation count against the cycle count of executing the graph, with the features of Van Eijndhoven's invention of transforming an initial design, under user-specified design constraints and the area and delay estimates of that design, into multiple design alternatives, re-estimating the delay and area of each alternative, and selecting a pareto point, which represents a design that is the best choice in the design space close to that point. The combination would have been obvious because Sharma tunes a single architecture by feeding profiled results back into the same graph analysis, so that the output 3150 is fed back to the dfg analysis step 3111 for the next iterations, and Sharma does not describe generating alternative graphs to compare against one another. Van Eijndhoven answers exactly that need in the same field of mapping a design onto computation hardware, by transforming the initial design into multiple design alternatives 2999, each with different area and delay trade-offs, and by keeping only those that are pareto points. Van Eijndhoven selects the seed design to transform based on the user-specified design constraints 2001 and the area and delay estimates of the seed design, and its estimator uses the CDFG and the execution counts of loop bodies and instructions to estimate delay, so a person of ordinary skill applying Van Eijndhoven's transformation and pareto selection to Sharma's evaluated dataflow graph would predictably have produced a set of candidate graphs and a chosen optimal graph for the synthesizable accelerator, with the improvements Van Eijndhoven identifies as reduced costs or circuit board space and faster operating or response time.
Regarding claim 2, Sharma as modified by Van Eijndhoven discloses the method of claim 1, wherein Van Eijndhoven further discloses the evaluating the multiple data processing graphs comprises evaluating for the set constraints (col 17, “Transformation step 2200 identifies a bottleneck in a seed design 2298 that is selected from the seed pool 2499. The selection is based on the user-specified design constraints 2001 and the area and delay estimates of the seed design.”; also, col 7-8, “These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”; also, col 22, “Thereto, an estimator 2100 updates the delay and area estimates of the transformed design 2329. If the resulting design 2339 is a pareto point with respect to the design alternatives 2399, it is added to the design alternatives 2399, otherwise it is discarded.”) at least one or more of performance characteristics, hardware overhead and power consumption (col 1, “They differ from personal computer systems because the hardware and software is specifically designed for a limited number of functions, and the system must meet several constraints, for example on response time, power consumption, cost, size, weight or form factor.”; also, col 17, “The remainder of this document refers only to area and delay as characteristics or optimization targets of a design.”; also, col 17, “However, the described method can be applied for other design characteristics, such as power consumption.”; also, col 29, “The location of these points is given by the value of characterizing quantities of the design they correspond to. Examples of these quantities are area, delay, power consumption and monetary cost.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma as modified by Van Eijndhoven, in which the dataflow graph of the algorithm is evaluated for its operation count and cycle count and then transformed into multiple design alternatives from which a pareto point is selected, with the features of Van Eijndhoven's invention of deriving design alternatives that satisfy the design criteria, in which each design is located in the design space by characterizing quantities such as area, delay, power consumption and monetary cost, and in which an embedded system must meet constraints on response time, power consumption, cost and size. The combination would have been obvious because Van Eijndhoven derives design alternatives that satisfy the design criteria, re-estimates the delay and area of each transformed design and keeps it only when it is a pareto point, and names response time, power consumption, cost and size as constraints an embedded system must meet, which correspond to the performance characteristics, power consumption and hardware overhead the claim recites. A person of ordinary skill applying Van Eijndhoven's evaluation to the candidate graphs of the combined flow would have evaluated each candidate for those constraints because Van Eijndhoven's alternatives are derived to satisfy the design criteria and are located by those characterizing quantities, and doing so predictably yields a candidate set screened against the constraints the user set.
Regarding claim 3, Sharma as modified by Van Eijndhoven discloses the method of claim 1, wherein Sharma further discloses the evaluating a complexity and performance of the data processing graph comprises determining the complexity metric based on one or more of a number of edges, a number of nodes, a number of connectivity components, an operation index, a number of available operations, a number of times an operation is used in the data processing graph, a complexity level of the operation, and weight coefficients (col 13, “the dataflow analyzer component iterating over the nodes of the dataflow graph of the DNN and generates a list of pairs (e.g., operation type, precision, operation count) for the forward and backward passes of training”; also, col 13, “In one example, the operation type is a type of scalar operation (e.g., multiply, add, etc), the precision field is a tuple of the data-types required by the operands (e.g., fixed-point, floating-point, or power-of-2), and the operation count field describes the number of scalar operations.”).
Regarding claim 6, Sharma as modified by Van Eijndhoven discloses the method of claim 1, wherein Van Eijndhoven further discloses the modifying the data processing graph to generate multiple data processing graphs provide graphs (col 17, ‘The design transformation process 2000 transforms the initial design 1999 as produced by the analysis step 1000 into multiple design alternatives 2999, each with different area and delay trade-offs.”; also, col 7-8, “These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”; also, col 8, “The application 9100 in FIG. 8 links a CDFG 9110, a tree 9120, and a process network 9130.”; also, col 28, “Clearly, such CDFG transformation must maintain the original code functionality.”) that satisfy the set constraints (col 7-8, ‘These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”), reduce the evaluated complexity (col 7, “The invention provides for an automated transformation of such a functional specification into a hardware-level representation and consequently into a complete design of an embedded system which has an improved partitioning of specific hardware and software.”; also, col 7, “Such improvements may be found in reduced costs or circuit board space, faster operating or response time or a better choice for specific hardware components.”) and increase the evaluated performance (col 2, “The optimization process 2300 may then decide to resort to a "remote procedure call" transformation that does not increase parallelism but maps the loop to a fast accelerator to reduce overall execution delay.”; also, col 17, “Optimizations include design transformations to increase concurrency and to map elements in the design alternative's program variation to computation and communication hardware in the embedded system.”; also, col 7, “Such improvements may be found in reduced costs or circuit board space, faster operating or response time or a better choice for specific hardware components.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma as modified by Van Eijndhoven, in which the dataflow graph of the algorithm is evaluated for its operation count and cycle count and then transformed into multiple design alternatives from which a pareto point is selected, with the features of Van Eijndhoven's invention of an automated transformation into a design having an improved partitioning of specific hardware and software, the improvements being reduced costs or circuit board space and faster operating or response time, together with transformations that increase concurrency. The combination would have been obvious because Van Eijndhoven derives design alternatives that satisfy the design criteria, states that the improvement its transformation provides is found in reduced costs or circuit board space and faster operating or response time, and maps a loop to a fast accelerator to reduce overall execution delay, so that the alternatives it produces are graphs that satisfy the constraints while reducing hardware cost and increasing speed. A person of ordinary skill applying those transformations to the graph of the combined flow would have obtained candidate graphs with those properties because those are the improvements Van Eijndhoven states its transformation provides.
Regarding claim 8, Sharma as modified by Van Eijndhoven discloses the method of claim 1, wherein Sharma further comprising: generating hardware description language (HDL) descriptions of the multiple data processing graphs (col 3, “Gorilla++: A programming model and language with both dataflow and shared-memory constructs as well as a toolset that generates HW/SW from a Gorilla++ description.”; also, col 26, “The last component, the builder 3114 generates a synthesizable accelerator in case of FPGA implementation, along with the optimized values of circuit parameters using both the optimized set of architectural parameter and execution schedule.”; also, col 12-13, “As shown in the FIG. 10, this workflow includes four operations: (1010) a dataflow analysis operation to analyze the resource requirements for the dataflow graph, (1020) a resource partitioning operation to analytically split the FPGA's resources, (1030) a cycle-accurate scheduling operation to obtain cycle counts, and (1040) a builder operation to generate a synthesizable accelerator using the optimal resource breakdown from operation 1030.”).
Regarding claim 9, Sharma as modified by Van Eijndhoven discloses the method of claim 8, wherein Sharma further comprising: implementing a hardware based on the HDL descriptions (col 3, “Gorilla++: A programming model and language with both dataflow and shared-memory constructs as well as a toolset that generates HW/SW from a Gorilla++ description.”; also, col 4, “To overcome the challenges mentioned above, the present design targets FPGAs for their flexibility and develops a heterogenous architecture, which is an accelerator for training quantized DNNs.”; also, col 14, “First, the simulator component divides the FPGA's LUT and DSP resources into 16x16 systolic arrays for the forward and backward passes using the p obtained from the resource partitioner.”).
Regarding claim 10, Sharma as modified by Van Eijndhoven discloses the method of claim 9, wherein Sharma further comprising: analyzing the implementation results of the hardware (col 26, “the dfg analysis step 3111 then repeats the process of observing and sampling runtime characteristics of the Neural Network during the execution of training iterations.”; also, col 26, “the output 3150 is fed back to the dfg analysis step 3111 for the next plurality of iterations of Neural Network training and inference”).
Regarding claim 11, Sharma discloses a system comprising (col 1, “In one example, a data processing system to perform a workflow for generating a hardware accelerator, comprises memory; and a processor coupled to the memory.”; also, col 18, “FIG. 15 is a diagram of a computer system including a data processing system that utilizes an accelerator according to an embodiment of the invention.”): a host (col 18, “Data processing system 1202, as disclosed above, includes a general purpose instruction-based processor 1227 and an accelerator 1226 (e.g., in-line accelerator, offload accelerator for offloading processing from another computing resource, accelerator with heterogenous architecture for DNN training, etc.).”) configured for hardware accelerator development (col 1, “In one example, a data processing system to perform a workflow for generating a hardware accelerator, comprises memory; and a processor coupled to the memory.”; also, col 19, “Processor 1227 and accelerator 1226 execute various software components stored in memory 1204 to perform various functions for system 1200.”; also, col 12-13, “As shown in the FIG. 10, this workflow includes four operations: (1010) a dataflow analysis operation to analyze the resource requirements for the dataflow graph, (1020) a resource partitioning operation to analytically split the FPGA's resources, (1030) a cycle-accurate scheduling operation to obtain cycle counts, and (1040) a builder operation to generate a synthesizable accelerator using the optimal resource breakdown from operation 1030.”); a storage device (col 19, “The exemplary computer system 1200 includes a data processing system 1202, a main memory 1204 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory 1206 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1216 (e.g., a secondary memory unit in the form of a drive unit, which may include fixed or removable computer-readable storage medium), which communicate with each other via a bus 1208.”); and a hardware accelerator (col 18, “Data processing system 1202, as disclosed above, includes a general purpose instruction-based processor 1227 and an accelerator 1226 (e.g., in-line accelerator, offload accelerator for offloading processing from another computing resource, accelerator with heterogenous architecture for DNN training, etc.).”; also, col 6, “The accelerator may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine or a device), or a combination of both.”) designable by the host (col 1, “The processor is configured to perform a dataflow analysis operation to analyze resource requirements for a dataflow graph of a neural network (NN) model, to perform a resource partitioning operation to analytically split resources of a hardware accelerator, to perform a cycle-accurate scheduling operation to obtain cycle counts for forward and backward passes of the dataflow graph, and to generate a synthesizable hardware accelerator using an optimal resource breakdown.”; also, col 19, “Data processing system 1202 is configured to implement the data processing system for performing the operations and steps discussed herein.”; also, col 12-13, “As shown in the FIG. 10, this workflow includes four operations: (1010) a dataflow analysis operation to analyze the resource requirements for the dataflow graph, (1020) a resource partitioning operation to analytically split the FPGA's resources, (1030) a cycle-accurate scheduling operation to obtain cycle counts, and (1040) a builder operation to generate a synthesizable accelerator using the optimal resource breakdown from operation 1030.”; also, col 26, “The last component, the builder 3114 generates a synthesizable accelerator in case of FPGA implementation, along with the optimized values of circuit parameters using both the optimized set of architectural parameter and execution schedule.”) and coupled between the host and the storage device (col 3, “In-line accelerator: An accelerator for I/O-intensive applications that can send and receive data without CPU involvement.”; also, col 3, “If an in-line accelerator cannot finish the processing of an input data, it passes the data to the CPU for further processing.”; also, col 17, “In an embodiment, accelerator 1311 communicates with other I/O interfaces, for example, storage elements through direct memory access (DMA) to retrieve data without involving general purpose instruction-based processor 1320.”; also, col 17, “Only when accelerator 1311 cannot handle the input packet by itself, the packet is transferred to general purpose instruction-based processor 1320.”), wherein the storage device is configured to store data (col 19, “The exemplary computer system 1200 includes a data processing system 1202, a main memory 1204 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory 1206 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1216 (e.g., a secondary memory unit in the form of a drive unit, which may include fixed or removable computer-readable storage medium), which communicate with each other via a bus 1208.”; also, col 19, “The storage units disclosed in computer system 1200 may be configured to implement the data storing mechanisms for performing the operations and steps discussed herein.”; also, col 19, “Memory 1206 can store code and/or data for use by processor 1227 or accelerator 1226.”) associated with a calculated performance of the hardware accelerator (col 25, “the scheduler generates the cycle counts for Q-array 2010 and MP-array 2020.”; also, col 25, “In one implementation, the scheduler step 3113 evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available.”; also, col 25, “In reality, however, even quantized DNNs have a large memory footprint and hence performance of the generated FPGA accelerator depends both on the breakdown of the FPGA's resources and the organization of on-chip memory.”), wherein the host is configured to (col 1, “In one example, a data processing system to perform a workflow for generating a hardware accelerator, comprises memory; and a processor coupled to the memory.”; also, col 1, “The processor is configured to perform a dataflow analysis operation to analyze resource requirements for a dataflow graph of a neural network (NN) model, to perform a resource partitioning operation to analytically split resources of a hardware accelerator, to perform a cycle-accurate scheduling operation to obtain cycle counts for forward and backward passes of the dataflow graph, and to generate a synthesizable hardware accelerator using an optimal resource breakdown.”; also, col 4, “While it can be argued that the transcendental functions and the data movement operations can be offloaded to the host CPU”; also, col 19, “Processor 1227 and accelerator 1226 execute various software components stored in memory 1204 to perform various functions for system 1200.”): generate a data processing graph (col 12, “The DNN workflow begins with a programmer defining a Dataflow Graph (DFG) of the DNN using a high-level API.”; also, col 23, “The workflow 3100 begins with the programmer defining the DataFlow Graph (DFG) of the neural network in step 3110.”) for describing at least one algorithmic operation (col 12, “This API allows the programmer to specify the precision for each operation in the DNN.”; also, col 13, “This operation 1010a includes the dataflow analyzer component iterating over the nodes of the dataflow graph of the DNN and generates a list of pairs (e.g., operation type, precision, operation count) for the forward and backward passes of training.”); evaluate a complexity (col 13, “This operation 1010a includes the dataflow analyzer component iterating over the nodes of the dataflow graph of the DNN and generates a list of pairs (e.g., operation type, precision, operation count) for the forward and backward passes of training.”; also, col 23, “The first part 3120 of the DFG analysis 3111 is to analyze the number and type of computations by the Neural Network.”) and a performance of the data processing graph (col 1, “The processor is configured to perform a dataflow analysis operation to analyze resource requirements for a dataflow graph of a neural network (NN) model, to perform a resource partitioning operation to analytically split resources of a hardware accelerator, to perform a cycle-accurate scheduling operation to obtain cycle counts for forward and backward passes of the dataflow graph, and to generate a synthesizable hardware accelerator using an optimal resource breakdown.”; also, col 12-13, “As shown in the FIG. 10, this workflow includes four operations: (1010) a dataflow analysis operation to analyze the resource requirements for the dataflow graph, (1020) a resource partitioning operation to analytically split the FPGA's resources, (1030) a cycle-accurate scheduling operation to obtain cycle counts, and (1040) a builder operation to generate a synthesizable accelerator using the optimal resource breakdown from operation 1030.”; also, col 25, “The scheduler generates the cycle counts for Q-array 2010 and MP-array 2020.”; also, col 25, “In one implementation, the scheduler step 3113 evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available.”) using a complexity metric (col 13, “In one example, the operation type is a type of scalar operation (e.g., multiply, add, etc), the precision field is a tuple of the data-types required by the operands (e.g., fixed-point, floating-point, or power-of-2), and the operation count field describes the number of scalar operations.”) and performance metric (col 24, “Next, the resource partitioning component optimizes the ideal number of cycles required by the forward and backward operations given by the following equation:”; also, col 25, “Using the cycle-counts, the scheduler updates the compute ratio c defined in Equation [5] as follows.”), wherein a number of operations used in the at least one algorithmic operation for the data processing graph (col 23, “The first part 3120 of the DFG analysis 3111 is to analyze the number and type of computations by the Neural Network. “; also, col 23, “To this end, the dataflow analyzer component iterates over the nodes of the dataflow graph of the Neural Network and generates a list of (operation type, precision, operation count) pairs for the forward propagation and backward propagation phases of training.“; also, col 23, “The operation type is the type of scalar operation (multiply, add, etc), the precision field is a tuple of the data-types required by the operands (fixed-point, floating-point, or power-of-2), the operation count field describes the number of scalar operations.”) is evaluated against the performance of the data processing graph (col 25, “Here, the c term in Equation 5 is the ratio of non-zero computations in the backward pass to the non-zero computations in the forward pass, and r term in Equation 6 is the one minus the ratio of resources required for the backward pass to the resources required by the forward pass.”; also, col 1, “The processor is configured to perform a dataflow analysis operation to analyze resource requirements for a dataflow graph of a neural network (NN) model, to perform a resource partitioning operation to analytically split resources of a hardware accelerator, to perform a cycle-accurate scheduling operation to obtain cycle counts for forward and backward passes of the dataflow graph, and to generate a synthesizable hardware accelerator using an optimal resource breakdown.”; also, col 24, “Next, the resource partitioning component optimizes the ideal number of cycles required by the forward and backward operations given by the following equation:”; also, col 25, “In one implementation, the scheduler step 3113 evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available.”; also, col 25, “Using the cycle-counts, the scheduler updates the compute ratio c defined in Equation [5] as follows.”; also, col 26, “The scheduler then feeds back the updated compute ratio to the resource partitioner step 3112.”); data processing graph based on set constraints, and the evaluated complexity and the performance to generate multiple data processing graphs; and evaluate the multiple data processing graphs using the complexity metric and the performance metric to select at least one optimal graph from among the multiple data processing graphs for design of the hardware accelerator.
However, in a similar field of endeavor, Van Eijndhoven discloses modify the data processing graph (col 22, “A transformation implementation step 2320 discussed in more detail below executes the transformation commands 2319 on a seed design 2298.”; also, col 28, “The original loop as shown in FIG. 18(a) in the CDFG is first unrolled twice, i.e., the loop nodes are duplicated.”; also, col 28, “Clearly, such CDFG transformation must maintain the original code functionality.”) based on set constraints (col 17, “Transformation step 2200 identifies a bottleneck in a seed design 2298 that is selected from the seed pool 2499. The selection is based on the user-specified design constraints 2001 and the area and delay estimates of the seed design.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”), and the evaluated complexity and the performance (col 17, “Transformation step 2200 identifies a bottleneck in a seed design 2298 that is selected from the seed pool 2499. The selection is based on the user-specified design constraints 2001 and the area and delay estimates of the seed design.”; also, col 22, “Also, a new transformation may be defined in step 2310 based on the results 2399 of a previous transformation.”; also, col 17, “The estimator 2100 uses the CDFG 1157 and the execution counts of loop bodies and instructions in the tree 1299 to estimate the delay of each tree node.”; also, col 17, “An estimator 2100 estimates various characteristics of each of the design alternatives 2999 for a given target architecture.”; also, col 17, “The remainder of this document refers only to area and delay as characteristics or optimization targets of a design.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”) to generate multiple (col 17, “The design transformation process 2000 transforms the initial design 1999 as produced by the analysis step 1000 into multiple design alternatives 2999, each with different area and delay trade-offs.”; also, col 7-8, “These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”) data processing graphs (col 8, “As shown in FIG. 7, a design is a data structure containing information about a computer program and its mapping to an embedded system that consists of three top-level parts: application 9100, mapping 9200, and architecture 9300.”; also, col 8, “The application 9100 in FIG. 8 links a CDFG 9110, a tree 9120, and a process network 9130.”; also, col 8-9, “In the initial design 1999, these would be CDFG 1157, tree 1299 and process network 1803.”; also, col 9, “A design such as shown in FIG. 8 would only be obtained after several transformation operations as discussed below.”; also, col 17, “Each design alternative contains a variation of the initial program 996 that takes particular area and delay trade-offs into account.”; also, col 8, “A control-dataflow graph 1157 (abbreviated CDFG) captures the static structure of the program 996.”; also, col 28, “The original loop as shown in FIG. 18(a) in the CDFG is first unrolled twice, i.e., the loop nodes are duplicated.”; also, col 28, “Clearly, such CDFG transformation must maintain the original code functionality.”); and evaluate the multiple data processing graphs (col 17, “An estimator 2100 estimates various characteristics of each of the design alternatives 2999 for a given target architecture.”; also, col 22, “Thereto, an estimator 2100 updates the delay and area estimates of the transformed design 2329. If the resulting design 2339 is a pareto point with respect to the design alternatives 2399, it is added to the design alternatives 2399, otherwise it is discarded.”) using the complexity metric and the performance metric (col 17, “The remainder of this document refers only to area and delay as characteristics or optimization targets of a design.”; also, col 29, “The location of these points is given by the value of characterizing quantities of the design they correspond to. Examples of these quantities are area, delay, power consumption and monetary cost.”) to select at least one optimal graph from among the multiple data processing graphs (col 8, “In the selection step 3000 the design alternatives 2999 are presented for comparison to allow for user selection of the most optimal design.”; also, col 28, “This design space view 3001 allows the user to conveniently select a design 3999 of his choice.”; also, col 29, “A pareto point 3004 is a design point which is not strictly dominated by another design point. This means that each pareto point represents a design that is the best choice in the design space close to that point.”; also, col 18, “It then iteratively optimizes this design by selecting the design alternative with the lowest delay and adding this design alternative to the seed pool 2499 for the next optimization. Each intermediate pareto point is added to the design alternatives 2999.”) for design of the hardware accelerator (col 8, “In the build step 4000 the selected design is mapped to a combination of software and hardware that represents the desired embedded system 4999.”; also, col 32, “The input design 4199 specifies that some sections of its program are to be mapped into a function-specific hardware accelerator structure.”; also, col 32, “Accelerator generator 4300 converts each such program section into RTL code, which is the low-level specification of the accelerator to be implemented.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma's invention of a data processing system having a host processor, memory, a data storage device, and an accelerator, in which a dataflow graph of the algorithm to be accelerated is defined and the processor performs a dataflow analysis that counts the operations of that graph and evaluates that operation count against the cycle count of executing the graph, and in which the scheduler generates the cycle counts, with the features of Van Eijndhoven's invention of transforming an initial design, under user-specified design constraints and the area and delay estimates of that design, into multiple design alternatives, re-estimating the delay and area of each alternative, and selecting a pareto point, which represents a design that is the best choice in the design space close to that point. The combination would have been obvious because Sharma tunes a single architecture by feeding profiled results back into the same graph analysis, so that the output 3150 is fed back to the dfg analysis step 3111 for the next iterations, and Sharma does not describe generating alternative graphs to compare against one another. Van Eijndhoven answers exactly that need in the same field of mapping a design onto computation hardware, by transforming the initial design into multiple design alternatives 2999, each with different area and delay trade-offs, and by keeping only those that are pareto points. Van Eijndhoven selects the seed design to transform based on the user-specified design constraints 2001 and the area and delay estimates of the seed design, and its estimator uses the CDFG and the execution counts of loop bodies and instructions to estimate delay, so a person of ordinary skill configuring Sharma's processor to apply Van Eijndhoven's transformation and pareto selection to the evaluated dataflow graph would predictably have produced a set of candidate graphs and a chosen optimal graph for the synthesizable accelerator, with the improvements Van Eijndhoven identifies as reduced costs or circuit board space and faster operating or response time.
Regarding claim 12, Sharma as modified by Van Eijndhoven discloses the system of claim 11, wherein Van Eijndhoven further discloses the set constraints include performance characteristics, hardware overhead and power consumption. Sharma does not disclose the set constraints include performance characteristics, hardware overhead and power consumption (col 1, “They differ from personal computer systems because the hardware and software is specifically designed for a limited number of functions, and the system must meet several constraints, for example on response time, power consumption, cost, size, weight or form factor.”; also, col 17, “Transformation step 2200 identifies a bottleneck in a seed design 2298 that is selected from the seed pool 2499. The selection is based on the user-specified design constraints 2001 and the area and delay estimates of the seed design.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”; also, col 17, “However, the described method can be applied for other design characteristics, such as power consumption.”; also, col 29, “The location of these points is given by the value of characterizing quantities of the design they correspond to. Examples of these quantities are area, delay, power consumption and monetary cost.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma as modified by Van Eijndhoven, in which the host evaluates the dataflow graph of the algorithm for its operation count and cycle count and then transforms it into multiple design alternatives from which a pareto point is selected, with the features of Van Eijndhoven's invention of user-specified design constraints applied together with the area and delay estimates of a design, in a design space whose characterizing quantities are area, delay, power consumption and monetary cost. The combination would have been obvious because Van Eijndhoven selects the seed design to transform on the user-specified design constraints 2001 together with the area and delay estimates, and it names response time, power consumption, cost and size as constraints an embedded system must meet, which correspond to the performance characteristics, power consumption and hardware overhead the claim recites. A person of ordinary skill configuring the host of the combined system to accept constraints would have expressed them in those same quantities because they are the characterizing quantities Van Eijndhoven names for a design and the estimates its seed selection compares against, and doing so predictably bounds the search for the optimal candidate by the constraints the user set.
Regarding claim 16, Sharma as modified by Van Eijndhoven discloses the system of claim 11, wherein Van Eijndhoven further discloses the multiple data processing graphs include graphs (col 17, “The design transformation process 2000 transforms the initial design 1999 as produced by the analysis step 1000 into multiple design alternatives 2999, each with different area and delay trade-offs.”; also, col 7-8, “These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”; also, col 8, “The application 9100 in FIG. 8 links a CDFG 9110, a tree 9120, and a process network 9130.”; also, col 28, “Clearly, such CDFG transformation must maintain the original code functionality.”) that satisfy the set constraints (col 7-8, “These models are used in the transformation step 2000 to derive a number of so-called design alternatives 2999 that satisfy the design criteria.”; also, col 22, “The optimization process 2300 may try different transformations to achieve the area or delay target specified in the optimize command 2299.”), reduce the evaluated complexity (col 7, “The invention provides for an automated transformation of such a functional specification into a hardware-level representation and consequently into a complete design of an embedded system which has an improved partitioning of specific hardware and software.”; also, col 7, “Such improvements may be found in reduced costs or circuit board space, faster operating or response time or a better choice for specific hardware components.”) and increase the evaluated performance (col 2, “The optimization process 2300 may then decide to resort to a "remote procedure call" transformation that does not increase parallelism but maps the loop to a fast accelerator to reduce overall execution delay.”; also, col 17, “Optimizations include design transformations to increase concurrency and to map elements in the design alternative's program variation to computation and communication hardware in the embedded system.”; also, col 7, “Such improvements may be found in reduced costs or circuit board space, faster operating or response time or a better choice for specific hardware components.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma as modified by Van Eijndhoven, in which the host evaluates the dataflow graph of the algorithm for its operation count and cycle count and then transforms it into multiple design alternatives from which a pareto point is selected, with the features of Van Eijndhoven's invention of an automated transformation into a design having an improved partitioning of specific hardware and software, the improvements being reduced costs or circuit board space and faster operating or response time, together with transformations that increase concurrency. The combination would have been obvious because Van Eijndhoven derives design alternatives that satisfy the design criteria, states that the improvement its transformation provides is found in reduced costs or circuit board space and faster operating or response time, and maps a loop to a fast accelerator to reduce overall execution delay, so that the alternatives it produces are graphs that satisfy the constraints while reducing hardware cost and increasing speed. A person of ordinary skill configuring the host of the combined system to apply those transformations would have obtained candidate graphs with those properties because those are the improvements Van Eijndhoven states its transformation provides.
Regarding claim 18, Sharma as modified by Van Eijndhoven discloses the system of claim 11, wherein Sharma further discloses the host is further configured to generate hardware description language (HDL) descriptions of the multiple data processing graphs (col 3, “Gorilla++: A programming model and language with both dataflow and shared-memory constructs as well as a toolset that generates HW/SW from a Gorilla++ description.”; also, col 26: the builder 3114 generates a synthesizable accelerator in case of FPGA implementation, along with the optimized values of circuit parameters using both the optimized set of architectural parameter and execution schedule.”; also, col 12-13, “As shown in the FIG. 10, this workflow includes four operations: (1010) a dataflow analysis operation to analyze the resource requirements for the dataflow graph, (1020) a resource partitioning operation to analytically split the FPGA's resources, (1030) a cycle-accurate scheduling operation to obtain cycle counts, and (1040) a builder operation to generate a synthesizable accelerator using the optimal resource breakdown from operation 1030.”).
Regarding claim 19, Sharma as modified by Van Eijndhoven discloses the system of claim 18, wherein the hardware accelerator comprises hardware based on the HDL descriptions (col 3, “Gorilla++: A programming model and language with both dataflow and shared-memory constructs as well as a toolset that generates HW/SW from a Gorilla++ description.”; also, Col 4, “the present design targets FPGAs for their flexibility and develops a heterogenous architecture, which is an accelerator for training quantized DNNs.”; also, col 14, “the simulator component divides the FPGA's LUT and DSP resources into 16×16 systolic arrays for the forward and backward passes using the p obtained from the resource partitioner.”).
Regarding claim 20, Sharma as modified by Van Eijndhoven discloses the system of claim 19, wherein Sharma further discloses the host is further configured to analyze implementation results of the hardware (col 26, “the dfg analysis step 3111 then repeats the process of observing and sampling runtime characteristics of the Neural Network during the execution of training iterations.”; also, col 26, “the output 3150 is fed back to the dfg analysis step 3111 for the next plurality of iterations of Neural Network training and inference.”).
Allowable Subject Matter
Claims 4, 5, 7, 13, 14, 15, and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 4 requires that the weight coefficients used in determining the complexity metric "include a first coefficient for indicating an importance of graph structure optimization, and a second coefficient for the importance of the number and complexity of the operations within the data processing graph." The closest art counts the scalar operations of a dataflow graph by type and precision and uses those counts directly in a cycle model, and the next closest art estimates area and delay for each design alternative and compares the alternatives on those estimates; neither weights a graph-structure term and an operation-count term against each other inside one complexity metric, and neither exposes such weights as coefficients that a developer sets to express which of the two matters more. The specification explains that the two coefficients let the developer steer the choice of optimal graph toward a simpler structure or toward fewer and cheaper operations before any hardware is built. In the located art the operation counts and the structural quantities feed fixed models with no such adjustable weighting, so a person of ordinary skill had no reason to introduce a first coefficient for the structure and a second coefficient for the operations.
Claim 5 requires "determining the performance metric based on a number of levels in the data processing graph and at least one maximal complexity among the operations at the levels." The closest art obtains performance from cycle counts produced by cycle-accurate scheduling of a partitioned accelerator, and the next closest art obtains performance from a delay estimate of each design alternative; the art that restructures an expression graph into a class of equivalent graphs selects among them by latency or area and obtains performance from the tree height of the restructured graph. In the located art nothing derives a performance metric from the number of levels of the graph combined with the maximal complexity of the operations at each level. The specification ties this metric to the clock frequency the synthesized accelerator reaches, because the slowest operation at each level bounds the delay of that level and the number of levels multiplies it. The located art has no per-level maximal complexity to multiply by, so a person of ordinary skill had no reason to form the claimed metric from those two quantities.
Claim 7 requires that "the optimal graph selected comprises a graph with the highest performance and the lowest power consumption from among the multiple data processing graphs." The closest art that selects among multiple candidates selects the pareto point that is not strictly dominated by another point along an area and delay trade-off, and iterates by taking the alternative with the lowest delay; a pareto selection by its nature returns a candidate that is best on one axis at some cost on the other, and it does not require the selected candidate to be simultaneously best on two axes. The other art of record selects an optimal resource breakdown for a single architecture rather than among multiple graphs. The specification describes selecting, from the compared graphs, the accelerator with the lowest power consumption or the highest performance according to the developer's constraints. A person of ordinary skill practicing a pareto selection had no reason to require the single selected graph to hold both the highest performance and the lowest power consumption, since the trade-off curve the located art selects along presumes those two are in tension.
Claim 13 requires that the complexity metric be determined "based on a number of edges, a number of nodes, a number of connectivity components, an operation index, a number of available operations, a number of times the operation is used in the data processing graph, a complexity level of the operation, and weight coefficients," recited in the conjunctive so that every listed quantity contributes to the metric. Parallel claim 3 recites the same list disjunctively and is reached by art that counts operations by type; claim 13 is not. The closest art counts operations by type, precision, and count, and the next closest art estimates area and delay; neither forms a single complexity metric from a number of connectivity components, an operation index, a complexity level of each operation, and weight coefficients together with the edge, node, and operation counts. The specification gives this metric as a graph-structure term formed from edges, nodes, and connectivity components added to a weighted sum over the operation index of the times each available operation is used multiplied by its complexity level, and shows it tracking the lookup-table cost of the synthesized designs. Nothing in the located art combines those structural and operation-level quantities, so a person of ordinary skill had no reason to determine a complexity metric from all of them.
Claim 14 requires the same first and second weight coefficients as claim 4, applied within the system of claim 13, and is allowable for the reasons given for claim 4 and by inheritance of the conjunctive complexity metric of claim 13.
Claim 15 requires the same performance metric as claim 5, determined from a number of levels and at least one maximal complexity among the operations at the levels, and is allowable for the reasons given for claim 5 and by inheritance of the conjunctive complexity metric of claim 13.
Claim 17 requires the same selection as claim 7, an optimal graph with the highest performance and the lowest power consumption from among the multiple data processing graphs, and is allowable for the reasons given for claim 7.
Response to Arguments
Applicants arguments filed on 09/08/2026 have been fully considered.
On page 11 of the Applicant's Remarks, with respect to the rejection of claims 4 and 14 under 35 U.S.C. 112(b), the Applicant argues that "Claim 4 and 14 has been amended, and as amended, claims 4 and 14 are submitted to be definite." The arguments are persuasive with respect to claims 4 and 14, because the amendment deletes "the" before "graph structure optimization" in each claim, so that the phrase no longer refers back to an earlier recitation that the claims do not contain. That rejection has therefore been withdrawn.
On page 15 of the Applicant's Remarks, with respect to the rejection of claims 1-3, 6, 8-12, 16, and 18-20 under 35 U.S.C. 103, the Applicant argues that "these descriptions in Sharma of the list of pairs (e.g., operation type, precision, operation count) and the cycle counts is not a disclosure or suggestion of evaluating a) a number of operations used in the at least one algorithmic operation for the data processing graph against b) the performance of the data processing graph," that "these disclosures occur at different sections in Sharma addressing different issues," that "The list of pairs in Sharma is used for training of the deep neural network(DNN)," that "The cycle counts in Sharma are used for feedback of an updated compute ratio to a resource partitioner," and that there is, in the Applicant's words, no evaluation of "list of pairs" against "cycle counts" in Sharma. The argument is not persuasive. The limitation that the evaluating uses a complexity metric and a performance metric was recited in original claim 1 and was found in Sharma in the Office action of June 8, 2026 at column 13 and column 25, and the amendment does not remove that finding; what the amendment adds is that the number of operations of the graph is evaluated against the performance of the graph, and the Applicant's own specification at paragraph [0067] describes that evaluation as a weighting in which "the number of used operations is more important than the performance," so that under the broadest reasonable interpretation the limitation is met by an evaluation in which the operation count of the graph and the performance of the graph are set against each other in one determination. Sharma performs exactly that determination, and it does so in one continuous passage rather than in unrelated sections. As shown in the citations, Sharma discloses that "The first part 3120 of the DFG analysis 3111 is to analyze the number and type of computations by the Neural Network." (Sharma, col. 23), that the pairs the dataflow analyzer generates carry the operation count because "the operation count field describes the number of scalar operations." (Sharma, col. 23), that the resource partitioner takes those counts and "optimizes the ideal number of cycles required by the forward and backward operations given by the following equation:" (Sharma, col. 24), in which "the c term in Equation 5 is the ratio of non-zero computations in the backward pass to the non-zero computations in the forward pass" (Sharma, col. 25), and that the scheduler "evaluates the quality of the solution generated by the resource partitioner by either (1) using a cycle-accurate simulation model for determining the quality of the partitioning solution; or (2) observing the performance of the partitioning solution using performance counters when a simulation model is not available." (Sharma, col. 25), after which "Using the cycle-counts, the scheduler updates the compute ratio c defined in Equation [5] as follows." (Sharma, col. 25) and "The scheduler then feeds back the updated compute ratio to the resource partitioner step 3112." (Sharma, col. 26). The operation counts in the list of pairs are the counts of the forward and backward operations whose ideal number of cycles the partitioner optimizes, the compute ratio c is defined as a ratio of computation counts, and the scheduler updates that ratio using the cycle counts and feeds it back, so the number of operations of the dataflow graph is evaluated against the cycle count, which is the performance of executing that graph, within a single loop that runs from the dataflow analysis at column 23 through the feedback at column 26. The list of pairs is generated for the forward and backward passes of training because those passes are the algorithm the accelerator executes, and the cycle counts are fed back through the compute ratio precisely because they are the performance against which the operation counts are evaluated; neither fact separates the two quantities, and each is a step of the same evaluation.
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 Jai Li whose telephone number is (571)272-1170. The examiner can normally be reached Mon-Thu between 06:00-16:00 EST.
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, Xiao Wu can be reached at (571)272-7761. 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.
/JAI W LI/Junior Patent Examiner, Art Unit 2613
/XIAO M WU/Supervisory Patent Examiner, Art Unit 2613
Prosecution Insights