Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 and 21-22 are rejected under 35 U.S.C 101 because the claimed invention is directed to a judicial exception without significantly more.
Claim 1.
STEP 1: Yes. The claim is directed to a “method” which is a process.
STEP 2A PRONE ONE:
The claim recites multiple mental processes.
generating a plurality of candidate hardware architectures that are specific to a particular machine learning task by repeatedly performing the following operations:
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation based on a set of determinations in the subsequent limitations.
selecting, based on (i) a hardware design policy and (ii) the one or more predetermined parameter values for each of one or more of the plurality of hardware parameters, a respective value for each of the plurality of hardware parameters;
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation based on (i) and (ii) the values of hardware parameters.
determining, from the selected values for the plurality of hardware parameters, a candidate hardware architecture;
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation on parameters to determine a hardware architecture.
determining whether the candidate hardware architecture satisfies pre-evaluation criteria, including (i) determining a feasibility of the candidate hardware architecture and (ii) determining an estimated performance measure of the candidate hardware architecture on the particular machine learning task; and
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of whether the hardware architecture satisfies the pre-evaluation criteria.
in response to a positive determination, evaluating, using one or more hardware performance simulators, a performance measure of the candidate hardware architecture on the particular machine learning task; and
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of a positive determination and a judgement which is a performance measure.
generating a final hardware architecture based on the plurality of candidate hardware architectures and on the performance measures.
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of candidate hardware architectures and performance measures to choose a final hardware architecture.
STEP 2A PRONG TWO: The claim does not integrate the exception into a practical application.
receiving data specifying a plurality of hardware parameters each associated with one or more values;
MPEP 2106.05(g) – This is pre solution data gathering activity.
receiving data specifying one or more predetermined values for each of one or more of the plurality of hardware parameters;
MPEP 2106.05(g) – This is pre solution data gathering activity.
STEP 2B: The claim does not recite an inventive concept or significantly more than the exception.
Conclusion: Claim 1 is directed to mental processes, not integrated into a practical application and lacks an inventive concept. Therefore, it is ineligible under 35 U.S.C 101.
Regarding Claims 2, 3, 4, 5, and 6:
These claims merely narrow the abstract idea by naming the mathematical search/optimization algorithm used to select the parameter values. Uniform random sampling (claim 2), Bayesian optimizations (claim 3), regularized evolutionary search (claim 4), model-based optimization (claim 5), and population based black box optimization (claim 6). Each remains a mathematical concept and mental process. MPEP 2106.05 (a). This does not integrate the judicial exception into a practical application. The claims do not resolve the issues from the claims they depend upon.
Regarding Claims 7, 9, and 10:
These claims merely refine the iterative search by updating the hardware design policy based on the performance measure (claim 7) or the negative determination (claim 9), and by removing a candidate from the plurality (claim 10). Policy feedback is a part of the abstract optimization, and candidate removal is routine storing and retrieving data. MPEP 2106.05(a); MPEP 2106.05(d). This does not integrate the judicial exception into a practical application. The claims do not resolve the issues from the claims they depend upon.
Regarding Claims 8 and 14:
These claims merely recite bypassing the hardware performance simulators in response to a negative determination (claim 8) and estimating performance by comparison against previously simulated candidates (claim 14). Each is itself part of the abstract idea a conditional decision or a calculation that is a mental process and mathematical concept. MPEP 2106.05(a). These remain mental processes or add a mathematical abstraction. This does not integrate the judicial exception into a practical application. The claims do not resolve the issues from the claims they depend upon.
Regarding Claims 11, 16, 17, and 19:
These claims merely add pre-solution data gathering, MPEP 2106.05(g), or they narrow the input data type and link the field of use, MPEP 2106.05(h) in specifying the machine learning task (claim 11), the association of the predetermined parameter value (claim 16, claim 19), and the categories of hardware parameter values (claims 16 and 19), and the categories of hardware parameters as compute, memory, and bandwidth (claim 17). This does not integrate the judicial exception into a practical application. The claims do not resolve the issues from the claims they depend upon.
Regarding Claims 12, 13, and 18:
These claims merely narrow the abstract idea by specifying what is computed or judged. That is defining the performance as latency, area, or power (claim 12), defining feasibility as satisfaction of hardware design constraints (claim 13), and defining the parameters as the number of processing elements along orthogonal dimensions (claims 18). These remain mental processes or add a mathematical abstraction. This does not integrate the judicial exception into a practical application. The claims do not resolve the issues from the claims they depend upon.
Regarding Claim 15:
This claim merely recites a cycle accurate simulator or an analytical model. An analytical model is itself a mathematical set of relationships and the tool is recited generically, so the simulator is not a particular machine. MPEP 2106.05(b). MPEP 2106.05(f). These remain mental processes or add a mathematical abstraction. This does not integrate the judicial exception into a practical application. The claims do not resolve the issues from the claims they depend upon.
Claim 21.
STEP 1: Yes. The claim is directed to a “system” which is a manufacture.
STEP 2A PRONE ONE:
The claim recites multiple mental processes.
generating a plurality of candidate hardware architectures that are specific to a particular machine learning task by repeatedly performing the following operations:
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation based on a set of determinations in the subsequent limitations.
selecting, based on (i) a hardware design policy and (ii) the one or more predetermined parameter values for each of one or more of the plurality of hardware parameters, a respective value for each of the plurality of hardware parameters;
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation based on (i) and (ii) the values of hardware parameters.
determining, from the selected values for the plurality of hardware parameters, a candidate hardware architecture;
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation on parameters to determine a hardware architecture.
determining whether the candidate hardware architecture satisfies pre-evaluation criteria, including (i) determining a feasibility of the candidate hardware architecture and (ii) determining an estimated performance measure of the candidate hardware architecture on the particular machine learning task; and
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of whether the hardware architecture satisfies the pre-evaluation criteria.
in response to a positive determination, evaluating, using one or more hardware performance simulators, a performance measure of the candidate hardware architecture on the particular machine learning task; and
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of a positive determination and a judgement which is a performance measure.
generating a final hardware architecture based on the plurality of candidate hardware architectures and on the performance measures.
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of candidate hardware architectures and performance measures to choose a final hardware architecture.
STEP 2A PRONG TWO: The claim does not integrate the exception into a practical application.
A system comprising one or more computers and one or more storage devices storing instructions that when executed by the one or more computers cause the one or more computers to perform operations comprising
MPEP 2106.05(g) – Generic computer components to apply the abstract idea.
receiving data specifying a plurality of hardware parameters each associated with one or more values;
MPEP 2106.05(g) – This is pre solution data gathering activity.
receiving data specifying one or more predetermined values for each of one or more of the plurality of hardware parameters;
MPEP 2106.05(g) – This is pre solution data gathering activity.
STEP 2B: The claim does not recite an inventive concept or significantly more than the exception.
Conclusion: Claim 21 is directed to mental processes, not integrated into a practical application and lacks an inventive concept. Therefore, it is ineligible under 35 U.S.C 101.
Claim 22.
STEP 1: Yes. The claim is directed to a “…One or more computer storage media…” which is a manufacture.
STEP 2A PRONE ONE:
The claim recites multiple mental processes.
generating a plurality of candidate hardware architectures that are specific to a particular machine learning task by repeatedly performing the following operations:
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation based on a set of determinations in the subsequent limitations.
selecting, based on (i) a hardware design policy and (ii) the one or more predetermined parameter values for each of one or more of the plurality of hardware parameters, a respective value for each of the plurality of hardware parameters;
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation based on (i) and (ii) the values of hardware parameters.
determining, from the selected values for the plurality of hardware parameters, a candidate hardware architecture;
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation on parameters to determine a hardware architecture.
determining whether the candidate hardware architecture satisfies pre-evaluation criteria, including (i) determining a feasibility of the candidate hardware architecture and (ii) determining an estimated performance measure of the candidate hardware architecture on the particular machine learning task; and
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of whether the hardware architecture satisfies the pre-evaluation criteria.
in response to a positive determination, evaluating, using one or more hardware performance simulators, a performance measure of the candidate hardware architecture on the particular machine learning task; and
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of a positive determination and a judgement which is a performance measure.
generating a final hardware architecture based on the plurality of candidate hardware architectures and on the performance measures.
This describes an observation, evaluation, judgment or opinion that can be done in the mind or with aid of pen and paper. In this case an evaluation of candidate hardware architectures and performance measures to choose a final hardware architecture.
STEP 2A PRONG TWO: The claim does not integrate the exception into a practical application.
one or more computer storage media storing instructions that when executed by one or more computers cause the one or more computers to perform operations comprising
MPEP 2106.05(g) – Generic computer components to apply the abstract idea.
receiving data specifying a plurality of hardware parameters each associated with one or more values;
MPEP 2106.05(g) – This is pre solution data gathering activity.
receiving data specifying one or more predetermined values for each of one or more of the plurality of hardware parameters;
MPEP 2106.05(g) – This is pre solution data gathering activity.
STEP 2B: The claim does not recite an inventive concept or significantly more than the exception.
Conclusion: Claim 22 is directed to mental processes, not integrated into a practical application and lacks an inventive concept. Therefore, it is ineligible under 35 U.S.C 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 8, 10-13, 15-19, 21, and 22 are rejected under 35 U.S.C 102 as being unpatentable over XU et al “AutoDNNchip: An Automated DNN Chip Predictor and Builder for Both FPGAs and ASICs” (2020).
Regarding Claim 1, XU teaches
A method performed by one or more computers, the method comprising:
receiving data specifying a plurality of hardware parameters each associated with one or more values;
“One-for-all Design Space Description. We make use of a graph-based representation that can unify design factors in all of the three design abstraction levels (including IP, architecture, and hardware-mapping levels) of DNN accelerator design, allowing highly flexible architecture configuration, scalable architecture/IP/mapping co-optimization, and algorithm-adaptive accelerator design.”. (Pg. 2).
This shows a “design space description” is the received set of hardware design factors (hardware parameters), each spanning configurable options/ranges (one / more values).
receiving data specifying one or more predetermined values for each of one or more of the plurality of hardware parameters;
“… we will briefly describe four graph based accelerator templates corresponding to four state-of-the-art DNN accelerators which are stored in the Hardware IP Pool (see Fig. 2 under the User Specified Inputs) of Auto DNN chip together with other templates to provide a sufficient number of design candidates, and then discuss the IP attributes for the nodes and edges.”. (Pg. 3 Section 4).
This shows searching received predefined accelerators / IP templates each fixing values for design factors drawn from its Hardware IP Pool, supplying the “predetermined values” for one or more of the hardware parameters.
generating a plurality of candidate hardware architectures that are specific to a particular machine learning task by repeatedly performing the following operations:
“To effectively explore the design space (e.g., the design factors in Table 1), AutoDNNchip involves three major steps as shown in Fig. 2: (1) the 1st-stage DSE: an early stage architecture and IP configuration exploration to efficiently rule out infeasible designs using the Chip Predictor’s coarse-grained mode; (2) the 2nd-stage DSE: an inter-IP pipeline exploration and IP optimization to effectively boost the performance of the remaining design candidates resulting from the 1st-stageDSE; and (3) a design validation through RTL generation and execution.”. (Pg. 6 Section 6).
“Second, according to the given DNN model, performance requirements (e.g., latency and throughput) and hardware budgets (e.g., resource and power budget of FPGA or ASIC), a design space of size N1 is generated by fetching commonly-used or promising hardware architecture templates and hardware IP templates from the Hardware IP pool.”. (Pg. 6 Section 6).
This shows “Auto DNN Chip” iteratively explores the accelerator design space for a given target DNN (particular machine learning task), generating many “design candidates “, i.e. generating candidate hardware architectures specific to an ML task.
selecting, based on (i) a hardware design policy and (ii) the one or more predetermined parameter values for each of one or more of the plurality of hardware parameters, a respective value for each of the plurality of hardware parameters;
“Second, according to the given DNN model, performance requirements (e.g., latency and throughput) and hardware budgets (e.g., resource and power budget of FPGA or ASIC), a design space of size N1 is generated by fetching commonly-used or promising hardware architecture templates and hardware IP templates from the Hardware IP pool. For example, when the given resource budgets are tight, a folded hardware architecture will be chosen instead of a flattened one; whereas flattened structures which facilitate IP pipelines are preferred when there are sufficient budgets.”. (Pg. 6 Section 6).
Auto DNN Chip selects values for the design factors (e.g., latency and throughput, IP configurations, folded vs flattened) by applying selection rules the “hardware design policy” to the predefined templates fetched from the hardware IP pool (predetermined parameter values).
determining, from the selected values for the plurality of hardware parameters, a candidate hardware architecture;
“Specifically, a basic directed graph is first constructed using the PE array architecture, memory architecture and mapping / data flow factors, where each node in the graph denotes a computation / data-path / memory IP and each directed edge denotes an interconnection between nodes whose direction is determined by the corresponding data movement’s direction. Proper attributes (e.g., those in Table 2) are then assigned to the nodes and edges of the directed graph in an object-oriented manner.”. (Pg. 3 Section 4).Each candidate accelerator is instantiated as a directed graph design built from the selected design factor values i.e. a candidate hardware architecture determined from the selected values.
determining whether the candidate hardware architecture satisfies pre-evaluation criteria, including (i) determining a feasibility of the candidate hardware architecture and (ii) determining an estimated performance measure of the candidate hardware architecture on the particular machine learning task; and
“Third, an architecture and IP configuration optimization is then performed to rule out most of the infeasible choices and trim down the design space to N2 (N2 < N1) promising candidates, e.g, more efficient with a lower latency. This fast early exploration makes use of the analytical nature of the Chip Predictor’s coarse-grained mode.”. (Pg. 6 Section 6).
This is AUTO DNN Chip 1st stage screen it rules out the infeasible candidates (i) and keeps the “promising” ones using the chip predictors estimated performance (ii) i.e. the pre-evaluation criteria.
in response to a positive determination, evaluating, using one or more hardware performance simulators, a performance measure of the candidate hardware architecture on the particular machine learning task; and
“…features a two-stage Design Space Exploration (DSE) methodology. Specifically, our Chip Builder realizes: (1) an architecture/IP design based on the Chip Predictor’s coarse-grained, analytical model-based prediction for a 1st-stage fast exploration and optimization, and (2) an IP/pipeline design based on the Chip Predictor’s fine-grained, run-time-simulation based prediction as a 2nd-stage IP-pipeline co-optimization. Experiments show that the Chip Builder’s 1st-stage DSE can efficiently rule out infeasible choices, while its 2nd-stage co-optimization can effectively boost the performance of remaining design candidates”. (Pg.2 Section 1).
“This step accepts the resulting N2 designs and performs further exploration and IP optimization using Algorithm 2... the bottleneck IPs will be recorded during Algorithm 1’s run-time simulations and then optimized…”. (Pg .6).
Only the candidates that survive the 1st stage screen (the positive determination) go to the 2nd stage, where their performance is evaluated using the chip predictors fine grained run time simulation (hardware performance simulator) for the given DNN i.e. the conditional simulator evaluation.
generating a final hardware architecture based on the plurality of candidate hardware architectures and on the performance measures.
“Select top Nopt candidates in DG”. (Pg. 6 Algorithm 2).
“… so the Chip Builder will launch the Chip Predictor to simulate the whole graph iteratively in order to generate an optimal design for the whole accelerator system.”. (Pg. 6 Section 5.3).
“Fig. 1 shows an overview of the proposed Auto DNN chip, which can automatically generate optimized FPGA or ASIC based DNN accelerators as well as an optimal algorithm to hardware map ping (i.e., dataflow), according to three customized inputs…”. (Pg. 3 Section 3).
This shows generating a final hardware architecture based on from the explored pools by their predicted / simulated performance to output a final design.
Regarding Claim 8, XU teaches
The method claim 1, further comprising:
in response to a negative determination, bypassing using the one or more hardware performance simulators to evaluate the performance measure of the candidate hardware architecture on the particular machine learning task.
“Third, an architecture and IP configuration optimization is then performed to rule out most of the infeasible choices and trim down the design space to N2 (N2 < N1) promising candidates, e.g, more efficient with a lower latency. This fast early exploration makes use of the analytical nature of the Chip Predictor’s coarse-grained mode.”. (Pg. 6 Section 6).
“…the 1st-stage DSE: an early-stage architecture and IP configuration exploration to efficiently rule out infeasible designs using the Chip Predictor’s coarse-grained mode; (2) the 2nd-stage DSE: an inter-IP pipeline exploration and IP optimization to effectively boost the performance of the remaining design candidates…”. (Pg. 6 Section 6).
Only the candidates that survive the 1st stage screen (“remaining design candidates”) are passed to the 2nd stage run time simulation, the candidates ruled out by a negative determination are trimmed and never evaluated by the run time simulator i.e. bypassing the hardware performance simulator in response to a negative determination.
Regarding Claim 10, XU teaches
The method of claim 8, further comprising removing the candidate hardware architecture from the plurality of candidate hardware architectures based on which the final hardware architecture is to be generated.
“Third, an architecture and IP configuration optimization is then performed to rule out most of the infeasible choices and trim down the design space to N2 (N2 < N1) promising candidates, e.g, more efficient with a lower latency.”. (Pg. 6 Section 6).
“…its 2nd-stage co-optimization can effectively boost the performance of remaining design candidates”. (Pg. 2 Section 1).
AUTO DNN CHIP removes the ruled-out candidates from the design space (trimming the pool to promising candidates) only those remaining candidates are carried forwarded to produce the final optimized design i.e. removing a candidate hardware architecture from the plurality of candidates based on which the final hardware architecture is generated.
Regarding Claim 11, XU teaches
The method of claim 1, wherein the particular machine learning task comprises one or more of an image classification, object detection, semantic segmentation, speech recognition, or optical character recognition task.
“…for solving real-life problems, such as image classification [1, 2], object detection [3], natural language processing [4], etc.”. (Pg. 1 Section 1).
“…set to meet real-time applications of visual recognition (e.g., image classification and object detection [3]) on edge devices.”. (Pg. 9 Section 7.2).
AUTO DNN CHIP target ML tasks include image classifications and object detection satisfying one or more.
Regarding Claim 12, XU teaches
The method of claim 1, wherein the performance measure of the candidate hardware architecture on the particular machine learning task comprises one or more of, for a hardware accelerator having the candidate hardware architecture:
a runtime latency of a neural network configured to perform the particular machine learning task deployed on the hardware accelerator,
an area of the hardware accelerator, or
a power consumption of the hardware accelerator.
“…an algorithm/hardware co-design is needed to allow the same DNN functionality to have a different decomposition, which would require different hardware IPs that correspond to dramatically different performance/energy/area tradeoffs.”. (Abstract).
“…and then outputs the estimated energy consumption, latency, and resource consumption…”. (Pg. 4 Section 5.1).
This shows the performance measure being one of the recited in the list.
Regarding Claim 13, XU teaches
The method of claim 1, wherein determining the feasibility of the candidate hardware architecture comprises determining whether the selected values of the plurality of hardware parameters satisfy one or more hardware design constraints.
“…according to the given DNN model, performance requirements (e.g., latency and throughput) and hardware budgets (e.g., resource and power budget of FPGA or ASIC), a design space of size N1 is generated… an architecture and IP configuration optimization is then performed to rule out most of the infeasible choices and trim down the design space…”. (Pg. 6 Section 5.3).
“…(denotedastemplate1/2/3inFig.14), (2) memory size and # of Pes within the resource constraint…”. (Pg. 10 Section 7.2).
AUTO DNN CHIP determines feasibly by checking whether the candidates selected parameter values (e.g. memory size and number of PEs) fall within the hardware design constraints (the resource and power budgets), ruling out the choices that don’t i.e. determining whether the selected values of the hardware parameters satisfy one or more hardware design constraints.
Regarding Claim 15, XU teaches
The method of claim 1, wherein the one or more hardware performance simulators comprise a cycle-accurate simulator or an analytical model.
“Chip Predictor … we propose a DNN Chip Predictor, a multi-grained performance estimation/simulation tool, which includes a coarse-grained, analytical-model based mode and a fine-grained, runtime-simulation based mode.”. (Pg. 2 Section 1).
AUTO DNN CHIP’s performance simulator includes an analytical model-based mode satisfying the recited alternative.
Regarding Claim 16, XU teaches
The method of claim 1, wherein the one or more predetermined values for each of one or more of the plurality of hardware parameters are associated with one or more predetermined hardware architectures for different hardware accelerators.
“…we will briefly describe four graph-based accelerator templates corresponding to four state-of-the-art DNN accelerators which are stored in the Hardware IP Pool”. (Pg. 3).
“An illustration of 4 architecture templates in our Hardware IP Pool including 2 architectures for both state-of the-art FPGA-and ASIC-based DNN accelerators.”. (Pg. 4).
AUTO DNN CHIP predetermined template values are tied to predetermined hardware architectures four templates corresponding to state-of-the-art DDN accelerators i.e. predetermined values associated with one or more predetermined hardware architectures for different hardware accelerators.
Regarding Claim 17, XU teaches
The method of claim 1, wherein the plurality of hardware parameters include:
one or more compute parameters;
one or more memory parameters, and/or
one or more bandwidth parameters.
“…the design space is large due to the numerous de sign choices of dataflows, processing elements, memory hierarchy…”. (Abstract).
“…architectures (e.g., memory hierarchy, number of PEs, NoC design, etc.)”. (Pg. 4 Section 5.1).
AUTO DNN CHIP’s hardware parameters include compute parameters (processing elements / number of PEs) and memory parameters (memory hierarchy), with NoC design covering interconnect bandwidth.
Regarding Claim 18, XU teaches
The method of claim 1, wherein the hardware parameters define the number of processing elements along a first a dimension of a hardware accelerator and/or along a second, orthogonal, direction of the hardware accelerator.
“…hardware parameters, such as the number of processing elements…”. (Pg. 2 Section 1).
“In this 3×3 systolic array with the local-data-forwarding…”. (Pg. 6 Section 5.3).
AUTO DNN CHIP parametrizes the number of processing elements and instantiates them as a 2D array PEs arranged along two orthogonal dimensions corresponding to the number of PEs along a first dimension and/or second orthogonal direction.
Regarding Claim 19, XU teaches
The method of claim 1, wherein receiving data specifying the one or more predetermined values for each of one or more of the plurality of hardware parameters comprises:
receiving data specifying a known hardware design policy; and
implementing and using the known hardware design policy to determine the one or more predetermined values for each of one or more of the plurality of hardware parameters.
“…a design space of size N1 is generated by fetching commonly-used or promising hardware architecture templates and hardware IP templates from the Hardware IP pool.”. (Pg. 6 Section 5.3).
“…a commonly-used architecture on FPGA-based accelerators…”. (Pg. 4 Section 4).
AUTO DNN CHIP obtains the predetermined values by fetching and instantiating commonly used/known hardware architecture and IP templates from its hardware pool.
Claim 21 recites sustainably the same limitations as claim 1 except this claim is directed to a “system”. Therefore this, claim is rejected for the same rationale as addressed above.
Claim 22 recites sustainably the same limitations as claim 1 except this claim is directed to “One or more computer storage media”. Therefore this, claim is rejected for the same rationale as addressed above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 non-obviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 2 is rejected under 35 U.S.C 103 as being unpatentable over XU et al “AutoDNNchip: An Automated DNN Chip Predictor and Builder for Both FPGAs and ASICs” (2020) and GOLOVIN et al “Google Vizier: A Service for Black-Box Optimization” (2017).
Regarding Claim 2, XU does not explicitly teach but GOLOVIN teaches
The method of claim 1, wherein the hardware design policy comprises a random policy which performs sampling from the plurality of hardware parameters each associated with one or more values with uniform randomness.
“Hence, black-box optimization has become increasingly important as systems have become more complex. In this paper we describe Google Vizier, a Google-internal service for performing black-box optimization that has become the de facto parameter tuning engine at Google. Google Vizier is used to optimize many of our machine learning models”. (Abstract).
“Several classes of algorithms have been proposed for the problem. The simplest of these are non-adaptive procedures such as Random Search, which selects XT uniformly at random from X at each time step t independent of the previous points selected, {Xτ : 1 ≤ τ.}, and GRID SEARCH”. (Pg. 1 Section 1.1).
This shows the design policy being of uniform randomness.
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of GOLOVIN’s random policy with XU’s method of generating hardware architectures. The motivation for doing so would have been to improve the efficiency of XU’s design space exploration because GOLOVIN teaches that “When function evaluations are expensive, it makes sense to carefully and adaptively select values to evaluate…”. (Pg. 1), thereby reducing design evaluations.
Claims 3, 5, 6, 7, and 14 are rejected under 35 U.S.C 103 as being unpatentable over XU et al “AutoDNNchip: An Automated DNN Chip Predictor and Builder for Both FPGAs and ASICs” (2020) and REAGEN et al “A Case for Efficient Accelerator Design Space Exploration via Bayesian Optimization” (2017).
Regarding Claim 3, XU does not explicitly teach but REAGEN teaches
The method of claim 1, wherein the hardware design policy comprises a Bayesian optimization policy.
“In this paper we propose using machine learning to improve the design of deep neural network hardware accelerators. We show how to adapt multi-objective Bayesian optimization to overcome a challenging design problem: optimizing deep neural network hardware accelerators for both accuracy and energy efficiency. DNN accelerators exhibit all aspects of a challenging optimization space: the landscape is rough, evaluating designs is expensive, the objectives compete with each other, and both design spaces (algorithmic and microarchitectural) are unwieldy. With multi-objective Bayesian optimization, the design space exploration is made tractable and the design points found vastly outperform traditional methods across all metrics of interest.”. (Abstract).
“Bayesian optimization is a statistical framework that uses in formation gained from past experiments to model and minimize an arbitrary objective function. BayesOpt works by building and querying cheap surrogate models which estimate the behavior of real objective functions which are expensive to evaluate.”. (Pg. 3 Section 3).
“Each exploration iteration begins with Spearmint selecting values for each of the 14 parameters. Parameter values are chosen based on their ability to maximize expected utility…”. (Pg. 4 Step 1).
The DSE policy is Bayesian Optimization selecting the accelerators hardware parameter values.
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of REAGEN’s optimization policy with XU’s method of generating hardware architectures. The motivation for doing so would have been to improve the efficiency of XU’s design space exploration because REAGEN teaches that “…can intelligently choose the next set of parameters such that solutions are found with a minimal number of expensive objective function evaluations.”. (Pg. 3), thereby reducing design evaluations.
Regarding Claim 5, XU does not explicitly teach but REAGEN teaches
The method of claim 1, wherein the hardware design policy comprises a model-based optimization policy.
“BayesOpt works by building and querying cheap surrogate models which estimate the behavior of real objective functions which are expensive to evaluate. Surrogate models are typically built using Gaussian Processes (GPs) [14]. GPs are fit to previously observed data and used to make predictions about the objectives' values in areas not yet explored.”. (Pg. 3 Section III).
REAGEN’s policy guides the search by building and querying surrogate models (GPs fit to the previously observed data) that predict objective values i.e. a model-based optimization policy.
Regarding Claim 6, XU does not explicitly teach but REAGEN teaches
The method of claim 1, wherein the hardware design policy comprises a population-based black-box optimization policy.
“GA goes a step further by attempting to isolate good parameter combinations, saving them to be interchanged with others, and exploring more suspected-good points.”. (Pg. 2 Section II B).
“Each optimization technique considers the objection functions as black boxes.”. (Pg. 4 Section IV).
REAGEN’s algorithm optimizer maintains and recombines as population of parameter combinations and treats the objective functions as black boxes (black box optimization).
Regarding Claim 7, XU does not explicitly teach but REAGEN teaches
The method of claim 5, wherein the following operations further comprise:
updating the hardware design policy based on the performance measure of the candidate hardware architecture on the particular machine learning task.
“Step 3-Update Design Space Models: The outputs from the function evaluations, model error and accelerator energy consumption, are fed back to Spearmint. Spearmint uses this information to update the posterior distribution of its surrogate model (i.e., the GPs). The AF can then be recomputed (bottom of Figure 1) and the process repeated.”. (Pg. 4 Section IV).
REAGEN’s feeds the evaluated performance measure (model error on the task and accelerator energy) back to Spearmint, which updates its surrogate model the design policy before repeating the loop.
Regarding Claim 14, XU does not explicitly teach but REAGEN teaches
The method of claim 1, wherein determining the estimated performance measure of the candidate hardware architecture on the particular machine learning task comprises comparing the selected values for the plurality of hardware parameters of the candidate hardware architecture with respective values of the plurality of hardware parameters of other candidate hardware architectures the performance measures of which have already been evaluated using the one or more hardware performance simulators.
“In this paper we propose using machine learning to improve the design of deep neural network hardware accelerators.”. (Abstract).
“GPs are fit to previously observed data and used to make predictions about the objectives' values in areas not yet explored.”. (Pg. 3 Section III).
“…the algorithm uses all previous observations {(Xl, YI), ... , (xn, Yn)}, and leverages GPs to model the design space and make predictions about Yn+l given Xn+l and Dn.”. (Pg. 3 Section 3).
REAGEN estimates a new candidate’s performance by querying a surrogate fit to the previously evaluate candidates and their measured outcomes the prediction for the candidates selected parameter values is derive form the values and already evaluated measures of other candidates i.e. comparing the candidate’s selected values with the respective values of other candidates whose performance was already evaluated.
Claims 4 is rejected under 35 U.S.C 103 as being unpatentable over XU et al “AutoDNNchip: An Automated DNN Chip Predictor and Builder for Both FPGAs and ASICs” (2020) and REAL et al “Regularized Evolution for Image Classifier Architecture Search” (2019).
Regarding Claim 4, XU does not explicitly teach but REAL teaches
The method of claim 1, wherein the hardware design policy comprises a regularized evolutionary search policy.
“First, we propose a change to the well-established tournament selection evolutionary algorithm [19] that we refer to as aging evolution or regularized evolution. Whereas in tournament selection, the best genotypes (architectures) are kept, we propose to associate each genotype with an age, and bias the tournament selection to choose the younger genotypes.”. (Pg. 1 Introduction).
“…the oldest individual in the population. This permits removing such oldest individual at each cycle (keeping a constant population size).”. (Pg. 2 Related Work).
REAL names and defines the “regularized evolutionary search” policy an aged biased selection evolutionary algorithm that removes the oldest from each cycle.
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of REAL’s optimization policy with XU’s method of generating hardware architectures. The motivation for doing so would have been to improve the efficiency of XU’s design space exploration because REAL teaches that “the finite lifetimes of aging evolution can give better results than direct tournament selection, while retaining its efficiency.”. (Pg. 2), thereby reducing design evaluations.
Claims 9 is rejected under 35 U.S.C 103 as being unpatentable over XU et al “AutoDNNchip: An Automated DNN Chip Predictor and Builder for Both FPGAs and ASICs” (2020) and LIU et al “GASPAD: A General and Efficient mm-wave Integrated Circuit Synthesis Method Based on Surrogate Model Assisted Evolutionary Algorithm” (2014).
Regarding Claim 9, XU does not explicitly teach but LIU teaches
The method of claim 8, further comprising updating the hardware design policy based on the negative determination.
“…select in each iteration the best generated candidate design based on prescreening for full-fletched simulation, and then update the population.”. (Pg. 5 Section III).
“The feasible design solutions (if any) rank higher than the infeasible design solutions... The infeasible design solutions are ranked based on the sorting of the sum of the constraint violation values in ascending order.”. (Pg. 5 Section III).
GASPAD updates its evolutionary population each iteration and its constraint handling rank the infeasible (negative determination) candidates by their constraint violation so those negatives feed into the population / policy update i.e. updating the design policy based on the negative determination.
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of LIU’s constraint handling and population updating with XU’s method of generating hardware architectures. The motivation for doing so would have been to obtain highly optimized feasible design with his efficiency because LIU teaches that “…using a global optimization algorithm to obtain highly optimized design solutions and using surrogate models to obtain a high efficiency…”. (Pg. 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10678973 B2 teaches using a machine learning process until one or more electronic architectural models from among the one or more electronic architectural models satisfy one or more electronic design targets.
US 10678971 B2 teaches a method for physically fabricating an electronic circuit using design space exploration as part of a design process.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NARCISO EDUARDO MONTES whose telephone number is (571)272-5773. The examiner can normally be reached Mon-Fri 8-5.
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, REHANA PERVEEN can be reached at (571) 272-3676. 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.
/N.E.M./Examiner, Art Unit 2189
/REHANA PERVEEN/Supervisory Patent Examiner, Art Unit 2189
Prosecution Insights