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 .
This action is in response to the application filed 3/22/2023. Claims 1-30 are pending and have been examined. Claims 1-30 are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/6/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings are objected to because
Fig. 1 has overlapping lines and numerical values, specifically, the ‘Height(H)’ value has a line through it rendering the number difficult to distinguish between the numbers 3 and 8.
Fig. 3 recites: “Memory read forNCHW format” [sic] “Memory read for NCHW format” and “Memory read forNCO4 HWC 4 format” [sic] “Memory read for NCO4HWC4 format”.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0039] recites: “to select a software kernel from the plurality of software kernel based on an optimization criterion” [sic] “to select a software kernel from the plurality of software kernels based on an optimization criterion”.
Appropriate correction is required.
Claim Objections
Claim 2, 3, 16 and 26 are objected to because of the following informalities:
Claims 2, 16 and 26 recite the phrase: “an attribute of a data”. The phrase is grammatically improper, the word “data” is a plural. Examiner suggests revising the phrase to “a data attribute” or “an attribute of a data point” for grammatical correctness.
Claim 3 recites: “to generate a ML-selected software kernel” [sic] “to generate an ML-selected software kernel”.
Also claims 4-7 which depend directly or indirectly on claim 3 are objected to under the same rationale as claim 3.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
validation rules engine configured to accept one or more input parameters and a plurality of software kernels, and configured to generate a plurality of valid software kernels in claim 1.
the trained ML model engine configured to generate a first trained machine learning (ML) model in claim 1.
the trained ML model engine is further configured to generate a ML-selected software kernel in claim 3.
a training data repository configured to accept an optimal software kernel in claim 4.
a machine learning (ML) model selection engine configured to accept the one or more input parameters and the optimal software kernel in claim 5.
the ML model selection engine is further configured to generate a second trained machine learning (ML) model in claim 6.
the ML model selection engine is further configured to tune the second trained ML model in claim 7.
a performance evaluation engine configured to receive the plurality of valid software kernels and further configured to generate a plurality of performance metrics in claim 8.
a kernel selection engine configured to receive the plurality of performance metrics in claim 9.
the kernel selection engine is further configured to implement a selection function in claim 10.
Regarding claim 1 and the above-noted three-prong test, the recited validation rules engine is a generic placeholder, accept one or more input parameters and a plurality of software kernels, and… generate a plurality of valid software kernels … is functional language, and there is no recitation of sufficient structure in claim 1 to perform the acceptance of input parameters and software kernels and generation of valid software kernels.
Regarding claims 1, 3 and 24 and the above-noted three-prong test, the recited machine learning (ML) model engine is a generic placeholder, “generate a first trained machine learning (ML) model”, “generate a ML-selected software kernel” and “generate a machine learning (ML)- selected software kernel” are functional language, and there is no recitation of sufficient structure in claims 1, 3 and 24 to perform the generation of an ML model or ML-selected software kernel.
Regarding claim 4 and the above-noted three-prong test, the recited machine learning (ML) model selection engine is a generic placeholder, data repository is a generic placeholder, “accept an optimal software kernel”, is functional language and there is no recitation of sufficient structure in claim 4 to perform the acceptance of an optimal software kernel.
Regarding claims 5, 6 and 7 and the above-noted three-prong test, the recited machine learning (ML) model selection engine is a generic placeholder, “accept the one or more input parameters and the optimal software kernel”, “generate a second trained machine learning (ML) model” and “tune the second trained ML model” are functional language, and there is no recitation of sufficient structure in claims 5-7 to perform the accepting, generation, or tuning.
Regarding claim 8 and the above-noted three-prong test, the recited performance evaluation engine is a generic placeholder, “receive the plurality of valid software kernels” and “generate a plurality of performance metrics” are functional language, and there is no recitation of sufficient structure in claim 8 to perform the receiving of valid software kernels, or generation or performance metrics.
Regarding claims 9 and 10 and the above-noted three-prong test, the recited kernel selection engine is a generic placeholder “receive the plurality of performance metrics” and “implement a selection function” are functional language, and there is no recitation of sufficient structure in claims 9 and 10 to perform the claimed receiving of performance metrics and implementation of a selection function.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the corresponding structure is not described in the specification for the validation rules engine recited in claim 1.
Regarding the validation rules engine recited in claim 1, the specification describes the component at a high-level of generality in paragraphs 52, 68 and 82-85. For example, paragraph [0068] states: “a validation rules engine which produces a plurality of valid software kernels based on a plurality of validation rules and determines valid software kernels of the plurality of software kernels which are capable of implementing the desired application. In one example, the plurality of validation rules determines all software kernels which may support a desired mathematical operation”. There does not appear to be sufficient disclosure for linking an explicit algorithm that explains how the claimed function of generating valid software kernels is performed. Furthermore, the accompanying drawings of the validation rules engine in Figs. 7 and 11 merely display black box diagrams at a high level of generality that do not suggest the appropriate circuitry or structure. The disclosure provides a blanket statement for suggested hardware/circuitry for the steps illustrated in the flow diagrams of FIGs. 14-16 in paragraph [0098]: “In one aspect, one or more of the steps in FIGs. 14, 15 and/or 16 may be executed by one or more processors which may include hardware, software, firmware, etc. The one or more processors, for example, may be used to execute software or firmware needed to perform the steps in the flow diagram(s) of FIGs. 14, 15 and/or 16. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise”. While, this statement may disclose circuitry/processing components structure at a high level of generality to perform the claimed functionality of FIGs. 14-16, the disclosure lacks a detailed algorithm for performing the claimed function of the validation rules engine for producing “a plurality of valid software kernels”. Accordingly, for the claim limitations regarding the “validation rules engine” in claim 1, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is not described in the specification for the trained machine learning (ML) model engine recited in claims 1, 2 and 24.
Regarding the trained machine learning (ML) model engine recited in claims 1, 2 and 24, the specification describes the trained machine learning model engine, merely repeating the claim language in paragraphs [0004-0016] and describes the component in paragraphs at a high level of generality in paragraphs [0071-0072], [0080], [0086-0087] and [0096]. However, the described trained machine learning model engine does not appear to have an algorithm to perform the described functionality. The disclosure merely asserts what the model engine does at a high level of generality, without any specific step-by-step procedural mapping that produces how “a first trained machine learning (ML) model”, “a ML-selected software kernel” or a “(ML)- selected software kernel” is generated by the claimed trained machine learning (ML) model engine. Furthermore, there doesn’t appear to be any accompanying drawings of the trained machine learning (ML) model engine that suggest the appropriate circuitry or structure to perform the claimed functionality. Accordingly, for these claim limitations, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is described in the specification for the data repository recited in claim 4.
Regarding the data repository recited in claim 4, the disclosure describes the data repository accepting an optimal software kernel. For example, paragraph [0093- 0094]: “In block 1610, a plurality of input parameters is supplied to a training data repository; that is the plurality of input parameters is inputted to the training data repository… In block 1620, an optimal software kernel Kopt is supplied to the training data repository; that is, the optimal software kernel Kopt is inputted to the training data repository”. The disclosure further provides a statement for suggested hardware/circuitry for the steps illustrated in the flow diagrams of FIGs. 14-16 in paragraph [0098]. Although the input of an optimal software kernel into the training data repository is recited at a high level of generality, it is a known conventional operation and there is circuitry/hardware described in paragraph 98 that is sufficient to perform the claimed acceptance of “an optimal software kernel”.
A review of the specification shows that the corresponding structure is not described in the specification for the machine learning (ML) model selection engine recited in claims 5-7.
Regarding the machine learning (ML) model selection engine recited in claims 5-7, the disclosure provides a high level of steps to perform the claimed functions without going into the specific algorithmic details of how the claimed functionality is performed. For example, the disclosure states what parameters a training algorithm may use for generating an ML model in paragraphs [0076-0077]: “the training algorithm uses a plurality of input parameters and the selected software kernel Kmax 1240 as the training set. In one example, the training set and the training algorithm are used to generate the trained ML model. In one example, the training algorithm may employ supervised learning… The training algorithm may use machine intelligence to discover data patterns and functional relationships between input data and output data of the training set to produce the trained ML model. In one example, the trained ML model may be used to estimate or predict output data for any arbitrary input data, particularly input data not in the training set… In one example, the training algorithm is a multiclass classification algorithm. For example, the training algorithm may employ one of a plurality of candidate ML models such as decision tree, random forest, K nearest neighbor, linear regression, etc.”, and the ML model selection engine is said to use a training algorithm in paragraph [0096]: “In one example, the ML model selection engine uses a training algorithm”. While an algorithm is disclosed, it merely identifies possible input parameters and candidate ML models that produces particular outputs, at a high level of generality, without describing the steps of how the ML model selection performs the generation of ML models and tunes them sufficiently to transform a general-purpose microprocessor to a ‘special purpose computer programmed to perform the disclosed algorithm’ [see, e.g., MPEP § 2181]. Furthermore, the accompanying drawings do not appear to display any ML model selection engine and merely displays black box diagrams at a high level of generality that do not suggest the appropriate circuitry or structure. Accordingly, for these claim limitations, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is not described in the specification for the performance evaluation engine recited in claim 8.
Regarding the performance evaluation engine recited in claims 8, the disclosure merely describes the metrics corresponding to each kernel in paragraph [0073] and what is generated by the performance evaluation engine in paragraphs [0089-0090] at a high level of generality. For example, paragraphs [0089-0090] recite: “In block 1510, a plurality of valid software kernels Ki is delivered to a performance evaluation engine (e.g., performance evaluation engine 1220 of FIG. 12). In one example, the plurality of valid software kernels Ki is part of the training set used to generate a trained ML model. For example, the plurality of valid software kernels Ki may be indexed by integer i… In block 1520, a plurality of performance metrics Pi (e.g., P1, P2, P3, Pj, etc.) is generated using the plurality of valid software kernels Ki. In one example, the plurality of performance metrics Pi is generated by the performance evaluation engine (e.g., performance evaluation engine 1220 of FIG. 12). For example, the plurality of performance metrics Pi may be associated with the plurality of valid software kernels Ki. In one example, a performance metric P 1 is associated with Kernel 1, a performance metric P2 is associated with Kernel 2, a performance metric P3 is associated with Kernel 3, and a performance metric Pj”. This recitation merely repeats the basic function of what the performance evaluation engine receives as input and produces, without explaining the step-by-step procedure of how the performance metrics are evaluated and generated by the engine. Furthermore, the accompanying drawings of the validation rules engine in Figs. 12 and merely display black box diagrams at a high level of generality that do not suggest the appropriate circuitry or structure that can perform the claimed functions. Accordingly, for these claim limitations, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is described in the specification for the kernel selection engine recited in claims 9 and 10.
Regarding the kernel selection engine recited in claims 8, the specific algorithm for performing the claimed reception of performance metrics and implementation of a selection function is described in paragraph [0075]: “In one example, the plurality of performance metrics is supplied to a kernel selection engine 1230 to provide a selected software kernel Kmax 1240. For example, the kernel selection engine 1230 may implement a selection function F(Ki, Pi) for all valid software kernels Ki, indexed by integer i, and for all performance metrics Pi, indexed by integer i, to provide the selected software kernel Kmax 1240. In one example, the selected software kernel Kmax 1240 has the maximum performance Pmax = MAX{Pi}, where MAX denotes a maximum operator (i.e., MAX{Pi} is the maximum of the set {Pi}). In one example, the selected software kernel Kmax 1240 is part of the training set used to generate the trained ML model according to the training algorithm”. A disclosure for the suggested hardware/circuitry for the steps illustrated in the flow diagrams of FIGs. 14-16 in paragraph [0098] is provided, of which step 1540 in FIG. 15 performs the algorithm for implementing a selection function by the kernel selection engine. Therefore, there is a sufficiently disclosed algorithm plus structure to perform the functions of claims 9 and 10.
If applicant does not intend to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim limitations that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Such claim limitations are:
means for inputting a plurality of valid software kernels to a trained machine learning (ML) model engine; in claim 24.
the apparatus comprising… means for configuring the trained ML model engine to generate a machine learning (ML)- selected software kernel based on the plurality of valid software kernels in claim 24.
the apparatus comprising… means for using the first trained ML model to generate a machine learning (ML)- selected software kernel in claim 24.
The apparatus of claim 24, further comprising means for generating the plurality of valid software kernels in claim 25.
The apparatus of claim 24, further comprising means for generating a second trained machine learning (ML) model in claim 27.
The apparatus of claim 27, further comprising means for tuning the second trained ML model in claim 28.
Regarding claims 24-25, 27 and 28 and the above-noted three-prong test, the claims recite the term “means” and “for inputting a plurality of valid software kernels to a trained machine learning (ML) model engine”, “for configuring the trained ML model engine to generate a machine learning (ML)- selected software kernel”, “for using the first trained ML model to generate a machine learning (ML)- selected software kernel”, “for generating the plurality of valid software kernels”, “for generating a second trained machine learning (ML) model” and “for tuning the second trained ML model”, are functional language, and there is no recitation of sufficient structure in claims 24-25, 27 and 28 to perform the claimed inputting of software kernels, configuring a trained ML model engine, using the trained ML model, generating an ML selected software kernel, valid software kernels and tuning a second trained ML model.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the corresponding structure is described in the specification for the recited “means for inputting a plurality of valid software kernels to a trained machine learning (ML) model engine” recited in claim 24.
Regarding the “inputting a plurality of valid software kernels to a trained machine learning (ML) model engine”, the specified structure for performing the inputting is described as being performed by circuitry/hardware in paragraph [0098]. The step of inputting valid software kernels is performed in to a trained ML model engine is performed in step 1440 of FIG. 4, which has surrounding structure as provided in paragraph 98. Although the input of optimal software kernels into a trained machine learning (ML) model engine is recited at a high level of generality in paragraph [0086], it is a known conventional operation and there is described circuitry/hardware described in paragraph 98 that is sufficient to perform the claimed “inputting a plurality of valid software kernels to a trained machine learning (ML) model engine”.
A review of the specification shows that the corresponding structure is not described in the specification for the recited “means for configuring the trained ML model engine to generate a first trained machine learning (ML) model based on the plurality of valid software kernels” and “means for using the first trained ML model to generate a machine learning (ML)- selected software kernel based on the plurality of valid software kernels” recited in claim 24.
Regarding the “configuring the trained ML model engine to generate a first trained machine learning (ML) model based on the plurality of valid software kernels”, the specification states in paragraph [0087]: “In block 1450, a first trained ML model is generated by the trained ML model engine based on the plurality of valid software kernels and the input parameters. In one example, the trained ML model engine is configured to generate the first trained ML model. For example, the first trained ML model is generated according to a training algorithm”. While there is a step involving configuring the trained ML model engine to generate a trained ML model according to an algorithm, as discussed above, in the review of the specification for the interpretation of claim 1, the specification lacks the specific steps for an algorithm that performs such “generating of a trained ML model”, let alone the “configuring the trained ML model engine” to perform the generating of another trained ML model.
Regarding the “using the first trained ML model to generate a machine learning (ML)- selected software kernel”, the specification describes this functionality at a high level of generality in paragraph [0067]: “In one example, a machine learning process may be used to provide a trained ML model, evolved from a training set, to select a ML-selected software kernel from a plurality of software kernels, based on a different criterion than using static optimization parameters (e.g., static bid values). In one example, the ML-selected software kernel may have better performance (e.g., better timing performance) than the selected software kernel from the software kernel selection process 700 with static optimization parameters”. While this describes the claimed outcome of generating producing an ML-selected software kernel, there is not an explicit algorithm or step-by-step explanation of this generation.
Accordingly, for these claim limitations, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is not described in the specification for the recited “means for generating the plurality of valid software kernels”
recited in claim 25.
Regarding the “means for generating the plurality of valid software kernels”, as discussed above, in the review of the specification for the interpretation of claim 1, there does not appear to be sufficient disclosure for linking an explicit algorithm that explains how the claimed function of generating valid software kernels is performed. Furthermore, the accompanying drawings of the validation rules engine in Figs. 7 and 11 merely display black box diagrams at a high level of generality that do not suggest the appropriate circuitry or structure. Accordingly, for this claim limitation, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is not described in the specification for the recited “means for generating a second trained machine learning (ML) model” recited in claim 27.
Regarding the recited “means for generating a second trained machine learning (ML) model”, as discussed above, in the review of the specification for the interpretation of claim 6, the disclosure merely provides a high level of steps to perform the claimed functions without going into the specific algorithmic details of how the claimed functionality of generating a second trained machine learning model is performed. Furthermore, the accompanying drawings merely displays black box diagrams at a high level of generality that do not suggest the appropriate circuitry or structure to generate second trained machine learning (ML) model. Accordingly, for this claim limitation, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
A review of the specification shows that the corresponding structure is not described in the specification for the recited “means for tuning the second trained ML model by using a training data from the training data repository” recited in claim 28.
Regarding the recited “means for tuning the second trained ML model by using a training data from the training data repository”, as discussed above, in the review of the specification for the interpretation of claim 7, while an algorithm for tuning an ML model is disclosed at a high level of generality, it merely identifies possible input parameters and candidate ML models that produces particular outputs, without going into a concrete method that describes how tuning is performed on a second trained ML model. Furthermore, the accompanying drawings do not appear to display any “means for tuning a trained ML model” and merely displays black box diagrams at a high level of generality that do not suggest the appropriate circuitry or structure. Accordingly, for this claim limitation, the written description fails to disclose both an algorithm(s) and special-purpose computer hardware to perform the algorithm(s). For more information, see MPEP § 2181.
If applicant does not intend to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-10 and 24-28 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
In particular, and as previously noted, the following claim limitations invoke 35 U.S.C. 112(f):
validation rules engine configured to accept one or more input parameters and a plurality of software kernels, and configured to generate a plurality of valid software kernels in claim 1.
the trained ML model engine configured to generate a first trained machine learning (ML) model in claim 1.
the trained ML model engine is further configured to generate a ML-selected software kernel in claim 3.
a machine learning (ML) model selection engine configured to accept the one or more input parameters and the optimal software kernel in claim 5.
the ML model selection engine is further configured to generate a second trained machine learning (ML) model in claim 6.
the ML model selection engine is further configured to tune the second trained ML model in claim 7.
a performance evaluation engine configured to receive the plurality of valid software kernels and further configured to generate a plurality of performance metrics in claim 8.
the apparatus comprising… means for configuring the trained ML model engine to generate a machine learning (ML)- selected software kernel based on the plurality of valid software kernels in claim 24.
the apparatus comprising… means for using the first trained ML model to generate a machine learning (ML)- selected software kernel in claim 24.
The apparatus of claim 24, further comprising means for generating the plurality of valid software kernels in claim 25.
The apparatus of claim 24, further comprising means for generating a second trained machine learning (ML) model in claim 27.
The apparatus of claim 27, further comprising means for tuning the second trained ML model in claim 28.
However, as noted above the written description of the current application fails to disclose the corresponding structure, material, or acts for performing each of the above identified claimed functions and to clearly link the structure, material or acts to the function. In particular, for each of the claimed functions, the written description fails to disclose both an algorithm and special-purpose computer hardware to perform the algorithm. For more information, see MPEP § 2181.
Accordingly, claims 1, 3, 5-8, 24-25 and 27-28 are rejected under 35 U.S.C 112(a) as failing to comply with the written description requirement.
Also claims 2-10 and 25-28, which each depend directly or indirectly from claims 1 and 24, are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement under the same rationale as independent claims 1 and 24.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-10 and 24-28 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
In particular, and as previously noted, the following claim limitations invoke 35 U.S.C. 112(f):
validation rules engine configured to accept one or more input parameters and a plurality of software kernels, and configured to generate a plurality of valid software kernels in claim 1.
the trained ML model engine configured to generate a first trained machine learning (ML) model in claim 1.
the trained ML model engine is further configured to generate a ML-selected software kernel in claim 3.
a machine learning (ML) model selection engine configured to accept the one or more input parameters and the optimal software kernel in claim 5.
the ML model selection engine is further configured to generate a second trained machine learning (ML) model in claim 6.
the ML model selection engine is further configured to tune the second trained ML model in claim 7.
a performance evaluation engine configured to receive the plurality of valid software kernels and further configured to generate a plurality of performance metrics in claim 8.
the apparatus comprising… means for configuring the trained ML model engine to generate a machine learning (ML)- selected software kernel based on the plurality of valid software kernels in claim 24.
the apparatus comprising… means for using the first trained ML model to generate a machine learning (ML)- selected software kernel in claim 24.
The apparatus of claim 24, further comprising means for generating the plurality of valid software kernels in claim 25.
The apparatus of claim 24, further comprising means for generating a second trained machine learning (ML) model in claim 27.
The apparatus of claim 27, further comprising means for tuning the second trained ML model in claim 28.
However, as also discussed above with regard to the rejection of claims 1, 3, 5-8, 24-25 and 27-28 under 35 U.S.C 112(a), the written description of the current application fails to disclose the corresponding structure, material, or acts for performing each of the above-identified claimed functions and to clearly link the structure, material or acts to the function. In particular, for each of the claimed functions, the written description fails to disclose both an algorithm and special-purpose computer hardware to perform the algorithm. As noted above, there is insufficient disclosure in the specification of algorithms and specific computer hardware for implementing the claimed classifier. As such, the above-noted limitations recited in 1, 3, 5-8, 24-25 and 27-28 are indefinite. Therefore claims 1, 3, 5-8, 24-25 and 27-28 are indefinite and are rejected under 35 U.S.C 112(b).
Also claims 2-10 and 25-28, which each depend directly or indirectly from claims 1 and 24, are rejected under U.S.C 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention, under the same rationale as independent claims 1 and 24.
The term “valid software kernels” in claims 1, 3, 8, 10-11, 14-15, 22-24 and 29 is a relative term which renders the claim indefinite. The term “valid” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
In particular, the specification describes, at a high level of generality, what makes a kernel “valid” within the described selection framework (see, e.g. paragraph [0052-0054]: “the validation rules engine 730 produces a plurality of valid software kernels 740 (labeled k 1, k2, k3 in FIG. 7)… In one example, the plurality of valid software kernels 740 is produced based on a plurality of validation rules which determines which software kernels of the plurality of software kernels 720 are capable of implementing the desired application. For example, the plurality of validation rules determines all software kernels which can support a desired mathematical operation” and paragraph [0068]: “In one example, the machine learning process may employ a validation rules engine which produces a plurality of valid software kernels based on a plurality of validation rules and determines valid software kernels of the plurality of software kernels which are capable of implementing the desired application. In one example, the plurality of validation rules determines all software kernels which may support a desired mathematical operation. For example, the machine learning process may select the ML-selected software kernel based on the trained ML model instead of the static optimization parameters (e.g., static bid values)”). The described “mathematical operation” and “validation rules” that “determine valid software kernels” are vague and do not provide any concrete statistical measure or quantitative standard that one of ordinary skill could use to identify or verify kernel validity independently of the described system. Thus, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. For examination purposes, the term valid software kernels, is being interpreted as any plurality of software kernels that are functionally viable/practically executable for a given task or purpose.
Additionally, claims 2-10, 12-23, 25-28 and 30 which depend either directly or indirectly from independent claims 1, 11, 24 and 29 respectively, are also rejected under 35 U.S.C. 112(b) as being indefinite under the same rationales as independent claims 1, 11, 24 and 29.
Claim Rejections - 35 USC § 102
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 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-4, 8-16, 24-26, and 29 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Barker (US 20210192334 A1; hereinafter Barker).
Regarding Independent Claim 1, Barker discloses An apparatus for kernel selection, the apparatus comprising: a validation rules engine1 configured to accept one or more input parameters and a plurality of software kernels, and configured to generate a plurality of valid software kernels2 based on the input parameters and the plurality of software kernels (see, e.g., paragraph [0016]: “FIG. 1 is an illustration of an example environment… The environment includes a kernel selection system 100” [i.e., the example environment in FIG. 1 is an apparatus for kernel selection] and paragraph [0019]: “The candidate kernel generator 106 determines one or more candidate kernels that may be utilized by the kernel processor 104 to determine a result computation. The candidate kernel generator 106 identifies the kernels in database 102 that are available to execute the operation that has been received in a request as well as characteristics of the input data. For example, one or more kernels may be constrained in the size of the matrices that may be used as input to calculate a result and/or one or more of the kernels may be specific to a particular computation. Thus, candidate kernel generator 106 can determine a list of the kernels stored in the database 102 that may be utilized to provide the application 130 with a result” [i.e., the kernel selection system functions as a validation rules engine that accepts both input data (input parameters) and software kernels from the database]);
and a trained machine learning (ML) model engine coupled to the validation rules engine (see, e.g., paragraph [0016]: “FIG. 1 is an illustration of an example environment where embodiments described herein may be implemented. The environment includes… neural network training system 120” and paragraph [0026]: “FIG. 3 is an example environment that may be utilized to train a neural network to rank kernels to perform a computation. The training system 300 can be the same system as illustrated in FIG. 1 as training system 120… the characteristics of the processor may be provided as training data to the neural network 304 along with input data, computation results information, and/or other neural network input. The neural network 304 may be the same and/or share similar characteristics with the neural network 110 of FIG. 1” [i.e., the neural network training system (ML model engine) is coupled to the components within the kernel selection apparatus (validation rules engine) and functions as an ML model engine training ML models]),
the trained ML model engine3 configured to generate a first trained machine learning (ML) model based on the plurality of valid software kernels (see, e.g., paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data. The neural network may be trained by a training system 120” [i.e., the trained neural network (trained ML model) is generated via training by the training system 120 (trained ML model engine)]).
Regarding claim 2, as discussed above, Barker discloses the apparatus of claim 1. Barker further discloses wherein the one or more input parameters include one of the following: a plurality of tensors, an attribute of a mathematical operation or function, an attribute of a data or an attribute of a tensor descriptor (see, e.g., paragraph [0017]: “Each kernel may be associated with a particular computation and may be utilized with provided input data to produce a result. For example, a kernel stored in database 105 may be associated with a general matrix multiplication (GeMM) computation. The GeMM kernel may then be utilized by an execution component, such as kernel processor 104, which can perform the computation utilizing the GeMM kernel” [i.e., the input parameters used in the candidate kernel generator includes a mathematical operation /function (GeMM)] and paragraph [0069]: In at least one embodiment, an untrained neural network is trained using a training dataset. In at least one embodiment, a training framework is a PyTorch framework, Tensorflow, Boost, Caffe, Microsoft Cognitive Toolkit/CNTK, MXNet, Chainer, Keras, Deeplearning4j, or other training framework” [i.e., the training frameworks inherently include tensor operations, mathematical functions and tensor attributes (such as shape/dimension, data type, and/or memory layout)]).
Regarding claim 3, as discussed above, Barker discloses the apparatus of claim 1. Barker further discloses wherein the trained ML model engine is further configured to generate a ML-selected software kernel based on the plurality of valid software kernels by using the first trained ML model (see, e.g., paragraph [0038]: “The neural network is trained to generate a ranked list of candidate kernels that may be utilized to perform a matrix computation. In some embodiments, the neural network may be trained using one or more embodiments described herein. For example, the neural network can be trained using a training system 300, as illustrated in FIG. 3” and paragraph [0039]: “At step 415, the neural network generates a ranked list of kernels to perform the requested computation. For example, the neural network can determine a relevancy score for each of the kernels in a list of kernels. A relevancy score can be indicative of how likely a kernel is an optimal kernel for performing the computation. At step 420, the optimal kernel is selected” [i.e., a ranked list candidate kernels are (ML-selected software kernels) based on a relevancy score (validation) of software kernels, is produced by the neural network generated by the training system (trained ML model engine)]).
Regarding claim 4, as discussed above, Barker discloses the apparatus of claim 3. Barker further discloses further comprising a training data repository4 configured to accept an optimal software kernel (see, e.g., paragraph [0028]: “Kernel database 308 includes a plurality of kernels, each of which can perform a computation on a set of input matrices. For each training input, each of the plurality of kernels stored in kernel database 308 may be provided to the kernel processor 302 to perform a computation… The result set may include, for example, for each kernel executed on a processor, processor information, run-time for the kernel, and/or a class for the training input” [i.e., kernel database 308 depicted in Fig. 3 with bi-directional arrows meaning it accepts/receives and sends/outputs software kernels to/from training system 300], paragraph [0030]: “Relevancy calculator 310 determines a relevancy score for each of the kernels in the result set based on the run-time of the kernel while executing the matrix computation… The result set may then be ranked according to relevancy scores for further processing” and paragraph [0031]: “The result set and the training input can be provided to the neural network as training data. The neural network may then process the input to determine a predicted relevancy score for each of the kernels, which then can be ranked into a predicted ranking of the kernels” [i.e., the kernels in the training system communicated with database 308 are ranked for relevancy which is a form of optimization]).
Regarding claim 8, as discussed above, Barker discloses the apparatus of claim 1. Barker further discloses further comprising a performance evaluation engine5 configured to receive the plurality of valid software kernels and further configured to generate a plurality of performance metrics based on the plurality of valid software kernels (see, e.g., paragraph [0020]: “Filter 108 removes any kernels from the list of candidate kernels that are not practical and/or impossible to execute given particular restraints of the system” [i.e., the kernels are validated by the Filter 108] and paragraph [0028]: “For each training input, each of the plurality of kernels stored in kernel database 308 may be provided to the kernel processor 302 to perform a computation. For example, kernel database may include kernels K1 . . . Kn, each of which can be provided to kernel processor 302 (or provided to a plurality of kernel processors) to generate a result set. The result set may include information regarding the execution of the training input on the kernel processor 302. The result set may include, for example, for each kernel executed on a processor, processor information, run-time for the kernel” [i.e., the kernel processer component in the training system produces a result set of performance metrics for the valid input kernels, functioning as a performance evaluation engine]).
Regarding claim 9, as discussed above, Barker discloses the apparatus of claim 8. Barker further discloses further comprising a kernel selection engine6 configured to receive the plurality of performance metrics (see, e.g., Barker paragraph [0030]: “Relevancy calculator 310 determines a relevancy score for each of the kernels in the result set based on the run-time of the kernel while executing the matrix computation… Thus, a kernel with a relevancy score of 0.25 may have performed worse (e.g., taken longer to run) than a kernel that is assigned a relevancy score of 0.75. The result set may then be ranked according to relevancy scores for further processing” [i.e., the relevancy calculator component in the training system receives the result set of performance metrics from the kernel processor component for scoring and ranking the kernels]).
Regarding claim 10, as discussed above, Barker discloses the apparatus of claim 9. Barker further discloses wherein the kernel selection engine is further configured to implement a selection function for each of the plurality of valid software kernels to determine an optimal software kernel (see, e.g., paragraph [0030]: “Relevancy calculator 310 determines a relevancy score for each of the kernels in the result set based on the run-time of the kernel while executing the matrix computation… The result set may then be ranked according to relevancy scores for further processing” [i.e., the relevancy calculator determines a relevancy score for the kernels and ranks the kernels (determining optimal software kernels), which is functionally a selection function performed on each of the valid kernels]).
Regarding Independent claim 11, Barker discloses A method for kernel selection, the method comprising: inputting a plurality of valid software kernels7 to a trained machine learning (ML) model engine (see, e.g., paragraph [0020]: “Filter 108 removes any kernels from the list of candidate kernels that are not practical and/or impossible to execute given particular restraints of the system” [i.e., the kernels are validated by the Filter 108], paragraph [0026]: “FIG. 3 is an example environment that may be utilized to train a neural network to rank kernels to perform a computation. The training system 300 can be the same system as illustrated in FIG. 1 as training system 120. The training system includes a kernel processor 302, which may be the same, or share characteristics with kernel processor 104 of FIG. 1” and paragraph [0028]: “For each training input, each of the plurality of kernels stored in kernel database 308 may be provided to the kernel processor 302 to perform a computation. For example, kernel database may include kernels K1 . . . Kn, each of which can be provided to kernel processor 302 (or provided to a plurality of kernel processors) to generate a result set.” [i.e., the training system (trained ML model engine) includes a kernel processor 302, which receives a plurality of valid software kernels]);
configuring the trained ML model engine to generate a first trained machine learning (ML) model based on the plurality of valid software kernels (see, e.g., paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data. The neural network may be trained by a training system 120” [i.e., the trained neural network (trained ML model) is generated via training by the training system 120 (trained ML model engine)]);
and using the first trained ML model to generate a machine learning (ML)-selected software kernel based on the plurality of valid software kernels (see, e.g., paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data” and paragraph [0022]: “Sorter 112 sorts the candidate kernels by relevancy based on the output of the neural network. For example, for a given list of kernels with relevancy scores, sorter 112 can sort the list so that the first kernel in the list is the most relevant kernel for performing a computation on the input data. Selection engine 114 then chooses a kernel from the sorted list, such as the kernel with the highest relevancy score” [i.e., under the broadest reasonable interpretation, the neural network (trained ML Model) generates a (ML)-selected software kernel by determining ML relevancy score data that results in a selected kernel from the coupled selection engine]).
Regarding claim 12, as discussed above, Barker discloses the method of claim 11. Barker further discloses further comprising inputting one or more input parameters to a validation rules engine (see, e.g., paragraph [0019]: “The candidate kernel generator 106 determines one or more candidate kernels that may be utilized by the kernel processor 104 to determine a result computation. The candidate kernel generator 106 identifies the kernels in database 102 that are available to execute the operation that has been received in a request as well as characteristics of the input data.” [i.e., the components in the kernel selection system receive both input data (input parameters) and software kernels from the database]).
Regarding claim 13, as discussed above, Barker discloses the method of claim 12. Barker further discloses further comprising inputting a plurality of software kernels to the validation rules engine (see, e.g., paragraph [0019]: “The candidate kernel generator 106 determines one or more candidate kernels that may be utilized by the kernel processor 104 to determine a result computation. The candidate kernel generator 106 identifies the kernels in database 102 that are available to execute the operation that has been received in a request as well as characteristics of the input data.” [i.e., the components in the kernel selection system receive both input data (input parameters) and software kernels from the database] ).
Regarding claim 14, as discussed above, Barker discloses the method of claim 13. Barker further discloses further comprising generating the plurality of valid software kernels based on the one or more input parameters and the plurality of software kernels (see, e.g., paragraph [0019]: “The candidate kernel generator 106 identifies the kernels in database 102 that are available to execute the operation that has been received in a request as well as characteristics of the input data. For example, one or more kernels may be constrained in the size of the matrices that may be used as input to calculate a result and/or one or more of the kernels may be specific to a particular computation. Thus, candidate kernel generator 106 can determine a list of the kernels stored in the database 102 that may be utilized to provide the application 130 with a result” and paragraph [0020]: “Filter 108 removes any kernels from the list of candidate kernels that are not practical and/or impossible to execute given particular restraints of the system. For example, filter 108 may identify the hardware constraints of kernel processor 104 and determine that, for a given kernel, the kernel processor 104 does not have (or is unlikely to have) the resources to process the given inputs with that kernel. Thus, filter 108 can remove the kernel from the candidate kernel list so that the neural network does not process that kernel as a potentially optimal kernel” [i.e., a filter generates a plurality of valid software kernels based on the list of kernels and input data from the candidate kernel generator]).
Regarding claim 15, as discussed above, Barker discloses the method of claim 14. Barker further discloses wherein the generating the plurality of valid software kernels is implemented by the validation rules engine (see, e.g., paragraph [0019]: “The candidate kernel generator 106 determines one or more candidate kernels that may be utilized by the kernel processor 104 to determine a result computation. The candidate kernel generator 106 identifies the kernels in database 102 that are available to execute the operation that has been received in a request as well as characteristics of the input data. For example, one or more kernels may be constrained in the size of the matrices that may be used as input to calculate a result and/or one or more of the kernels may be specific to a particular computation. Thus, candidate kernel generator 106 can determine a list of the kernels stored in the database 102 that may be utilized to provide the application 130 with a result” and paragraph [0020]: “Thus, filter 108 can remove the kernel from the candidate kernel list so that the neural network does not process that kernel as a potentially optimal kernel” [i.e., the kernel selection system functions as a validation rules engine that uses a filter 108 to determine one or more candidate kernels that may be utilized by the kernel processor 104 to determine a result computation (valid software kernels)]).
Regarding claim 16, as discussed above, Barker discloses the method of claim 14. Barker further discloses wherein the one or more input parameters include one of the following: a plurality of tensors, an attribute of a mathematical operation or function, an attribute of a data or an attribute of a tensor descriptor (see, e.g., paragraph [0017]: “Each kernel may be associated with a particular computation and may be utilized with provided input data to produce a result. For example, a kernel stored in database 105 may be associated with a general matrix multiplication (GeMM) computation. The GeMM kernel may then be utilized by an execution component, such as kernel processor 104, which can perform the computation utilizing the GeMM kernel” [i.e., the input parameters used in the candidate kernel generator includes a mathematical operation /function (GeMM)] and paragraph [0069]: In at least one embodiment, an untrained neural network is trained using a training dataset. In at least one embodiment, a training framework is a PyTorch framework, Tensorflow, Boost, Caffe, Microsoft Cognitive Toolkit/CNTK, MXNet, Chainer, Keras, Deeplearning4j, or other training framework” [i.e., the training frameworks inherently include tensor operations, mathematical functions and tensor attributes (such as shape/dimension, data type, and/or memory layout)]).
Regarding Independent Claim 24, Barker discloses An apparatus for kernel selection, the apparatus comprising: means for inputting a plurality of valid software kernels8 to a trained machine learning (ML) model engine (see, e.g. paragraph [0020]: “Filter 108 removes any kernels from the list of candidate kernels that are not practical and/or impossible to execute given particular restraints of the system” [i.e., the kernels are validated by the Filter 108], paragraph [0026]: “FIG. 3 is an example environment that may be utilized to train a neural network to rank kernels to perform a computation. The training system 300 can be the same system as illustrated in FIG. 1 as training system 120. The training system includes a kernel processor 302, which may be the same, or share characteristics with kernel processor 104 of FIG. 1”, paragraph [0028]: “For each training input, each of the plurality of kernels stored in kernel database 308 may be provided to the kernel processor 302 to perform a computation. For example, kernel database may include kernels K1 . . . Kn, each of which can be provided to kernel processor 302 (or provided to a plurality of kernel processors) to generate a result set” and paragraph [0039]: “A relevancy score can be indicative of how likely a kernel is an optimal kernel for performing the computation. At step 420, the optimal kernel is selected” [i.e., the training system (trained ML model engine) includes a kernel processor 302, which receives a plurality of valid software kernels in a kernel selection process]);
means for configuring the trained ML model engine to generate a first trained machine learning (ML) model based on the plurality of valid software kernels (see, e.g. paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data. The neural network may be trained by a training system 120” [i.e., the trained neural network (trained ML model) is generated via training by the training system 120 (trained ML model engine)]);
and means for using the first trained ML model to generate a machine learning (ML)- selected software kernel based on the plurality of valid software kernels (see, e.g. paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data” and paragraph [0022]: “Sorter 112 sorts the candidate kernels by relevancy based on the output of the neural network. For example, for a given list of kernels with relevancy scores, sorter 112 can sort the list so that the first kernel in the list is the most relevant kernel for performing a computation on the input data. Selection engine 114 then chooses a kernel from the sorted list, such as the kernel with the highest relevancy score” [i.e., under the broadest reasonable interpretation (BRI), the neural network (trained ML Model) generates a (ML)-selected software kernel by determining ML relevancy score data that results in a selected kernel from the coupled selection engine]).
Regarding claim 25, as discussed above, Barker discloses the method of claim 24. Barker further discloses further comprising means for generating the plurality of valid software kernels based on one or more input parameters and a plurality of software kernels (see, e.g. paragraph [0019]: “The candidate kernel generator 106 determines one or more candidate kernels that may be utilized by the kernel processor 104 to determine a result computation. The candidate kernel generator 106 identifies the kernels in database 102 that are available to execute the operation that has been received in a request as well as characteristics of the input data.” [i.e., the components in the kernel selection system receive both input data (input parameters) and software kernels from the database]).
Regarding claim 26, as discussed above, Barker discloses the method of claim 25. Barker further discloses wherein the one or more input parameters include one of the following: a plurality of tensors, an attribute of a mathematical operation or function, an attribute of a data or an attribute of a tensor descriptor (see, e.g., paragraph [0017]: “Each kernel may be associated with a particular computation and may be utilized with provided input data to produce a result. For example, a kernel stored in database 105 may be associated with a general matrix multiplication (GeMM) computation. The GeMM kernel may then be utilized by an execution component, such as kernel processor 104, which can perform the computation utilizing the GeMM kernel” [i.e., the input parameters used in the candidate kernel generator includes a mathematical operation /function (GeMM)] and paragraph [0069]: In at least one embodiment, an untrained neural network is trained using a training dataset. In at least one embodiment, a training framework is a PyTorch framework, Tensorflow, Boost, Caffe, Microsoft Cognitive Toolkit/CNTK, MXNet, Chainer, Keras, Deeplearning4j, or other training framework” [i.e., the training frameworks inherently include tensor operations, mathematical functions and tensor attributes (such as shape/dimension, data type, and/or memory layout)]).
Regarding Independent Claim 29, Barker discloses A non-transitory computer-readable medium storing computer executable code, operable on a device comprising at least one processor and at least one memory coupled to the at least one processor, wherein the at least one processor is configured to implement kernel selection (see, e.g., paragraph [0086]: “In at least one embodiment, code is stored on a computer-readable storage medium, for example, in form of a computer program comprising a plurality of instructions executable by one or more processors. In at least one embodiment, a computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transitory signals (e.g., a propagating transient electric or electromagnetic transmission) but includes non-transitory data storage circuitry (e.g., buffers, cache, and queues) within transceivers of transitory signals”, paragraph [0026]: “FIG. 3 is an example environment that may be utilized to train a neural network to rank kernels to perform a computation. The training system 300 can be the same system as illustrated in FIG. 1 as training system 120. The training system includes a kernel processor 302, which may be the same, or share characteristics with kernel processor 104 of FIG. 1”, paragraph [0028]: “For each training input, each of the plurality of kernels stored in kernel database 308 may be provided to the kernel processor 302 to perform a computation. For example, kernel database may include kernels K1 . . . Kn, each of which can be provided to kernel processor 302 (or provided to a plurality of kernel processors) to generate a result set” and paragraph [0039]: “A relevancy score can be indicative of how likely a kernel is an optimal kernel for performing the computation. At step 420, the optimal kernel is selected” [i.e., the training system (trained ML model engine) includes a kernel processor 302, which receives a plurality of valid software kernels in a kernel selection process]),
the computer executable code comprising: instructions for causing a computer to input a plurality of valid software kernels to a trained machine learning (ML) model engine (see, e.g., paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data. The neural network may be trained by a training system 120” [i.e., the trained neural network (trained ML model) is generated via training by the training system 120 (trained ML model engine)]);
and instructions for causing the computer to use the first trained ML model to generate a machine learning (ML)-selected software kernel based on the plurality of valid software kernels (see, e.g., paragraph [0021]: “Once a candidate list of kernels has been determined, the neural network 110 is provided the list along with the input data. The neural network is trained to determine, based on the list of candidate kernels, a relevancy score for each of the kernels that is predictive of how a given kernel will perform a computation on the input data” and paragraph [0022]: “Sorter 112 sorts the candidate kernels by relevancy based on the output of the neural network. For example, for a given list of kernels with relevancy scores, sorter 112 can sort the list so that the first kernel in the list is the most relevant kernel for performing a computation on the input data. Selection engine 114 then chooses a kernel from the sorted list, such as the kernel with the highest relevancy score” [i.e., under the broadest reasonable interpretation, the neural network (trained ML Model) generates a (ML)-selected software kernel by determining ML relevancy score data that results in a selected kernel from the coupled selection engine]).
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 nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 5-7, 17-23, 27-28 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Barker in view of Jakubiuk (US 20210295158 A1; hereinafter Jakubiuk).
Regarding claim 5, as discussed above, Barker discloses the apparatus of claim 4. However, Barker fails to explicitly teach further comprising a machine learning (ML) model selection engine configured to accept the one or more input parameters
and the optimal software kernel from the training data repository
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising a machine learning (ML) model selection engine9 configured to accept the one or more input parameters (see, e.g., Jakubiuk paragraph [0033]: “As shown in FIG. 2, In various embodiments, the Optimization Engine receives as input a plurality of characteristics 202 of target AI network (such as a neural network) and generates output 210… The Optimization Engine executes according to a training phase and an optimization phase. During the training phase, the Optimization Engine trains a heuristic AI network according to various types of heuristic training data, as shown in FIG. 6. In the optimization phase, the Optimization Engine receives the plurality of characteristics 202 of the target AI network”, paragraph [0035]: “Upon selection of the heuristic artificial intelligence network model during the optimization phase…” and paragraph [0051]: “The heuristic training data 124 may also include various types of operation hyper-parameters 604-6” [i.e., the optimization engine functions as an ML model selection engine that accepts the input parameters from heuristic training data])
and the optimal software kernel from the training data repository (see, e.g., paragraph [0035]: “Upon selection of the heuristic artificial intelligence network model during the optimization phase, the heuristic AI network model module 206 may utilize the dynamic auto-tune module 208 to identify the run times of various operation combinations and kernel implementations” [i.e., the optimization engine accepts the optimized kernel implementations from the dynamic auto-tune module 208], paragraph [0051]: “The heuristic training data 124 may also include various types of operation hyper-parameters 604-6” and paragraph [0052]: “A non-limiting exemplary list of operation hyper-parameters includes: kernel width/height, input depth, one or more input/output features” [i.e., the heuristic training data 124 functions as the training data repository that includes kernel run times of various kernel implementations (optimal software kernel)]).
Barker and Jakubiuk are analogous art because they are both directed to kernel optimization using machine learning techniques (see, e.g., Barker, paragraphs [0001-0002], Jakubiuk, paragraph [0007]).
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 Barker to incorporate the teachings of Jakubiuk to utilize a machine learning model selection engine that accepts one or more input parameters and an optimal software kernel from a training data repository. Doing so would have allowed Barker to use Jakubiuk’s method in order to “create a new and useful system and method for providing optimized software implementations of artificial intelligence networks”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0006]).
Regarding claim 6, as discussed above, Barker in view of Jakubiuk teaches the apparatus of claim 5.
Although Barker substantially teaches the claimed invention, Barker fails to explicitly teach wherein the ML model selection engine is further configured to generate a second trained machine learning (ML) model
In the same field, analogous art Jakubiuk teaches wherein the ML model selection engine is further configured to generate a second trained machine learning (ML) model (see, e.g., Jakubiuk paragraph [0051]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6” [i.e., the heuristic AI network training module 110 (first ML model), which is a component of the Optimization engine (model selection engine), generates (via training) a heuristic AI network 130 (second ML model)]).
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 Barker to incorporate the teachings of Jakubiuk to generate a second trained machine learning model. Doing so would have allowed Barker to use Jakubiuk’s method in order to “result in efficient AI networks which are deployable across many different hardware components and platforms”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0006]).
Regarding claim 7, as discussed above, Barker in view of Jakubiuk teaches the apparatus of claim 6.
Although Barker substantially teaches the claimed invention, Barker fails to explicitly teach wherein the ML model selection engine is further configured to tune the second trained ML model to generate a tuned machine learning (ML) model
In the same field, analogous art Jakubiuk teaches wherein the ML model selection engine is further configured to tune the second trained ML model to generate a tuned machine learning (ML) model (see, e.g., Jakubiuk paragraphs [0051-0052]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6. The heuristic training data 124 may include… various types of operation hyper-parameters 604-6… A non-limiting exemplary list of operation hyper-parameters includes: kernel width/height, input depth, one or more input/output features, padding type, padding dimensions, strides, dilations, epsilons and thresholds… A non-limiting exemplary list of workload types, i.e., varieties of optimization functions, includes: latency-optimized inference, throughput-optimized inference, latency-bound throughput” [i.e., the heuristic AI network 130 (second ML model) is generated using hyperparameters and optimized inference algorithms which is tuning the model to produce a tuned ML model]).
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 Barker to incorporate the teachings of Jakubiuk to tune a second trained ML model to generate a tuned machine learning model using a model selection engine. Doing so would have allowed Barker to use Jakubiuk’s method in order to “simulate[s] the execution of various combinations of operations and kernels and other algorithms and components over the entire structure of the artificial intelligence network to identify operation, kernel, algorithm and component combinations that optimize the performance of the entire artificial intelligence network”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0007]).
Regarding claim 17, as discussed above, Barker discloses the method of claim 11. However, Barker fails to explicitly teach further comprising providing one or more input parameters and an optimal software kernel to a machine learning (ML) model selection engine from a training data repository.
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising providing one or more input parameters and an optimal software kernel to a machine learning (ML) model selection engine from a training data repository (see, e.g., Jakubiuk paragraph [0033]: “As shown in FIG. 2, In various embodiments, the Optimization Engine receives as input a plurality of characteristics 202 of target AI network (such as a neural network) and generates output 210… The Optimization Engine executes according to a training phase and an optimization phase. During the training phase, the Optimization Engine trains a heuristic AI network according to various types of heuristic training data, as shown in FIG. 6. In the optimization phase, the Optimization Engine receives the plurality of characteristics 202 of the target AI network”, paragraph [0035]: “Upon selection of the heuristic artificial intelligence network model during the optimization phase…”, paragraph [0051]: “The heuristic training data 124 may also include various types of operation hyper-parameters 604-6” [i.e., the optimization engine functions as an ML model selection engine that accepts the input parameters from heuristic training data] and paragraph [0052]: “A non-limiting exemplary list of operation hyper-parameters includes: kernel width/height, input depth, one or more input/output features” [i.e., the heuristic training data 124 functions as the training data repository that includes kernel run times of various kernel implementations (optimal software kernel)]).
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 Barker to incorporate the teachings of Jakubiuk to utilize a machine learning model selection engine that accepts one or more input parameters and an optimal software kernel from a training data repository. Doing so would have allowed Barker to use Jakubiuk’s method in order to “create a new and useful system and method for providing optimized software implementations of artificial intelligence networks”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0006]).
Regarding claim 18, as discussed above, Barker in view of Jakubiuk teaches the method of claim 17.
Although Barker substantially teaches the claimed invention, Barker fails to explicitly teach further comprising configuring the machine learning (ML) model selection engine to generate a second trained machine learning (ML) model.
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising configuring the machine learning (ML) model selection engine to generate a second trained machine learning (ML) model (see, e.g., Jakubiuk paragraph [0051]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6” [i.e., the heuristic AI network training module 110 (first ML model), which is a component of the Optimization engine (model selection engine), generates (via training) a heuristic AI network 130 (second ML model)]).
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 Barker to incorporate the teachings of Jakubiuk to generate a second trained machine learning model. Doing so would have allowed Barker to use Jakubiuk’s method in order to “result in efficient AI networks which are deployable across many different hardware components and platforms”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0006]).
Regarding claim 19, as discussed above, Barker in view of Jakubiuk teaches the method of claim 18.
Although Barker substantially teaches the claimed invention, Barker fails to explicitly teach further comprising tuning the second trained ML model by using a training data from the training data repository to generate a tuned machine learning (ML) model.
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising tuning the second trained ML model by using a training data from the training data repository to generate a tuned machine learning (ML) model (see, e.g., Jakubiuk paragraphs [0051-0052]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6. The heuristic training data 124 may include… various types of operation hyper-parameters 604-6… A non-limiting exemplary list of operation hyper-parameters includes: kernel width/height, input depth, one or more input/output features, padding type, padding dimensions, strides, dilations, epsilons and thresholds… A non-limiting exemplary list of workload types, i.e., varieties of optimization functions, includes: latency-optimized inference, throughput-optimized inference, latency-bound throughput” [i.e., the heuristic AI network 130 (second ML model) is generated using hyperparameters and optimized inference algorithms from training data 124 (training data repository), which is tuning the model to produce a tuned ML model]).
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 Barker to incorporate the teachings of Jakubiuk to tune a second trained ML model using data from a training data repository to generate a tuned machine learning model using a model selection engine. Doing so would have allowed Barker to use Jakubiuk’s method in order to “simulate[s] the execution of various combinations of operations and kernels and other algorithms and components over the entire structure of the artificial intelligence network to identify operation, kernel, algorithm and component combinations that optimize the performance of the entire artificial intelligence network”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0007]).
Regarding claim 20, as discussed above, Barker in view of Jakubiuk teaches the method of claim 19. Barker further teaches further comprising using the tuned ML model in a kernel selection process in a kernel selection engine based on machine learning (ML) (see, e.g., Barker paragraph [0030]: “Relevancy calculator 310 determines a relevancy score for each of the kernels in the result set based on the run-time of the kernel while executing the matrix computation… The result set may then be ranked according to relevancy scores for further processing” and paragraph [0031]: “The result set and the training input can be provided to the neural network as training data. The neural network may then process the input to determine a predicted relevancy score for each of the kernels” [i.e., the relevancy calculator and neural network determine a relevancy score for the kernels and ranks the kernels (outputting optimal software kernels), which functions as a kernel selection engine]).
It would have been obvious to a person of ordinary skill in the art (PHOSITA) to incorporate the hyperparameter tuning methods taught by analogous art Jakubiuk, into Barker’s system to generate a more accurate and tuned ML model for kernel rating, as both references are directed to the identical problem of optimizing kernel selection using a trained machine learning model based on performance data.
Regarding claim 21, as discussed above, Barker in view of Jakubiuk teaches the method of claim 20. Barker further teaches further comprising supplying a plurality of performance metrics to the kernel selection engine (see, e.g., Barker paragraph [0030]: “Relevancy calculator 310 determines a relevancy score for each of the kernels in the result set based on the run-time of the kernel while executing the matrix computation… Thus, a kernel with a relevancy score of 0.25 may have performed worse (e.g., taken longer to run) than a kernel that is assigned a relevancy score of 0.75. The result set may then be ranked according to relevancy scores for further processing” [i.e., the relevancy calculator component in the training system receives the result set of performance metrics from the kernel processor component for scoring and ranking the kernels]).
Regarding claim 22, as discussed above, Barker in view of Jakubiuk teaches the method of claim 21. Barker further teaches further comprising configuring the kernel selection engine to implement a selection function for each of the plurality of valid software kernels to determine the optimal software kernel (see, e.g., Barker paragraph [0020]: “Filter 108 removes any kernels from the list of candidate kernels that are not practical and/or impossible to execute given particular restraints of the system” [i.e., valid kernels are produced by the Filter 108 and transmitted to adjacent components for further computation] and paragraph [0030]: “Relevancy calculator 310 determines a relevancy score for each of the kernels in the result set based on the run-time of the kernel while executing the matrix computation… The result set may then be ranked according to relevancy scores for further processing” [i.e., the relevancy calculator determines a relevancy score for the kernels and ranks the kernels (determining optimal software kernels), which is functionally a selection function performed on each of the valid kernels by the combined neural network and relevancy calculator components (kernel selection engine)]).
Regarding claim 23, as discussed above, Barker in view of Jakubiuk teaches the method of claim 21. Barker further teaches further comprising generating the plurality of performance metrics based on the plurality of valid software kernels (see, e.g., Barker paragraph [0043]: “At step 510, a result set is generated for the training input. The result set includes one or more kernels that can be utilized to perform a computation on the result set… At step 515, a relevancy score is assigned to each kernel in the result set that is indicative of the quality of performance of that kernel in performing the computation. Thus, kernels with faster run-times may be assigned a higher score than kernels that performed slower. At step 520, the kernels can be ranked based on run-times and/or assigned relevancy scores” [i.e., kernels that can be utilized to perform a computation on a result set are valid software kernels, the relevancy scores (performance metrics) are then generated based on the plurality of valid software kernels]).
Regarding claim 27, as discussed above, Barker discloses the apparatus of claim 24. However, Barker fails to explicitly teach further comprising means for generating a second trained machine learning (ML) model.
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising means for generating10 a second trained machine learning (ML) model (see, e.g., Jakubiuk paragraph [0051]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6” [i.e., the heuristic AI network training module 110 (first ML model), which is a component of the Optimization engine (model selection engine), generates (via training) a heuristic AI network 130 (second ML model)]).
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 Barker to incorporate the teachings of Jakubiuk to generate a second trained machine learning model. Doing so would have allowed Barker to use Jakubiuk’s method in order to “result in efficient AI networks which are deployable across many different hardware components and platforms”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0006]).
Regarding claim 28, as discussed above, Barker in view of Jakubiuk teaches the apparatus of claim 27.
Although Barker substantially teaches the claimed invention, Barker fails to explicitly teach further comprising means for tuning the second trained ML model by using a training data from the training data repository to generate a tuned machine learning (ML) model.
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising means for tuning11 the second trained ML model by using a training data from the training data repository to generate a tuned machine learning (ML) model (see, e.g., Jakubiuk paragraphs [0051-0052]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6. The heuristic training data 124 may include… various types of operation hyper-parameters 604-6… A non-limiting exemplary list of operation hyper-parameters includes: kernel width/height, input depth, one or more input/output features, padding type, padding dimensions, strides, dilations, epsilons and thresholds… A non-limiting exemplary list of workload types, i.e., varieties of optimization functions, includes: latency-optimized inference, throughput-optimized inference, latency-bound throughput” [i.e., the heuristic AI network 130 (second ML model) is generated using hyperparameters and optimized inference algorithms from training data 124 (training data repository), which is tuning the model to produce a tuned ML model]).
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 Barker to incorporate the teachings of Jakubiuk to tune a second trained ML model using training data from a training data repository to generate a tuned machine learning model using a model selection engine. Doing so would have allowed Barker to use Jakubiuk’s method in order to “simulate[s] the execution of various combinations of operations and kernels and other algorithms and components over the entire structure of the artificial intelligence network to identify operation, kernel, algorithm and component combinations that optimize the performance of the entire artificial intelligence network”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraph [0007]).
Regarding claim 30, as discussed above, Barker discloses the non-transitory computer-readable medium of claim 29. However, Barker fails to explicitly teach further comprising instructions for causing the computer to generate a second trained machine learning (ML) model
and to tune the second trained ML model by using a training data to generate a tuned machine learning (ML) model.
Nevertheless, in the same field, analogous art Jakubiuk teaches further comprising instructions for causing the computer to generate a second trained machine learning (ML) model (see, e.g., Jakubiuk paragraph [0051]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6” [i.e., the heuristic AI network training module 110 (first ML model), which is a component of the Optimization engine (model selection engine), generates (via training) a heuristic AI network 130 (second ML model)]).
and to tune the second trained ML model by using a training data to generate a tuned machine learning (ML) model (see, e.g. Jakubiuk paragraphs [0051-0052]: “During a training phase, the heuristic AI network training module 110 trains a heuristic AI network 130 according to various types of heuristic training data 124, as shown in FIG. 6. The heuristic training data 124 may include… various types of operation hyper-parameters 604-6… A non-limiting exemplary list of operation hyper-parameters includes: kernel width/height, input depth, one or more input/output features, padding type, padding dimensions, strides, dilations, epsilons and thresholds… A non-limiting exemplary list of workload types, i.e., varieties of optimization functions, includes: latency-optimized inference, throughput-optimized inference, latency-bound throughput” [i.e., the heuristic AI network 130 (second ML model) is generated using hyperparameters and optimized inference algorithms from training data 124 (training data repository), which is corresponding to tuning the model to produce a tuned ML model]).
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 Barker to incorporate the teachings of Jakubiuk to generate a second trained machine learning model and tune the second trained ML model using data from a training data repository to generate a tuned machine learning model using a model selection engine. Doing so would have allowed Barker to use Jakubiuk’s method in order to “result in efficient AI networks which are deployable across many different hardware components and platforms” and “simulate[s] the execution of various combinations of operations and kernels and other algorithms and components over the entire structure of the artificial intelligence network to identify operation, kernel, algorithm and component combinations that optimize the performance of the entire artificial intelligence network”, as suggested by Jakubiuk (see, e.g., Jakubiuk, paragraphs [0006-0007]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY A HALZEL whose telephone number is (571)272-5290. The examiner can normally be reached Mon-Fri 7:30-5: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, Kamran Afshar can be reached at (571) 272-7796. 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.
/JEREMY HALZEL/Examiner, Art Unit 2125
/KAMRAN AFSHAR/Supervisory Patent Examiner, Art Unit 2125
1 As discussed above in the 112(f) interpretation of this claim, the term “validation rules engine” has been interpreted as covering the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
2 As discussed above in the section 112(b) rejection of this claim, for examination purposes the term “valid software kernels” is interpreted as any plurality of software kernels that are functionally viable/practically executable for a given task or purpose.
3 As discussed above in the 112(f) interpretation of this claim, the term “trained ML model engine” has been interpreted as covering the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
4 As discussed above in the 112(f) interpretation of this claim, the term “data repository” has been interpreted as covering the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
5 As discussed above in the 112(f) interpretation of this claim, the term “performance evaluation engine” has been interpreted as covering the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
6 As discussed above in the 112(f) interpretation of this claim, the term “kernel selection engine” has been interpreted as covering the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
7 As discussed above in the section 112(b) rejection of this claim, for examination purposes the term “valid software kernels” is interpreted as any plurality of software kernels that are functionally viable/practically executable for a given task or purpose.
8 As discussed above in the section 112(b) rejection of this claim, for examination purposes the term “valid software kernels” is interpreted as any plurality of software kernels that are functionally viable/practically executable for a given task or purpose.
9 as discussed above in the 112(f) interpretation of this claim, the term “model selection engine” has been interpreted as covering the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
10 Because this claim limitation is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
11 Because this claim limitation is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
Prosecution Insights