DETAILED ACTION
This action is in response to an amendment to application 18/384023, filed on 12/30/2025. Claims 1-4, 6-13, and 15-19 are pending; claims 5, 14, and 20 are cancelled. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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.
Claims 1-4, 6-13, and 15-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by USPGPUB 2021/0103433, hereinafter “Kerr.”
Regarding claim 1, Kerr anticipates “A method, comprising:
receiving artificial intelligence (AI) model code containing a specialized function for a first one or more types of hardware platforms; (see, e.g., Kerr, fig. 4 & associated text; para. 53; “a programmer has written an implementation of a basic convolution with hooks in place, as represented by static kernels 402 to be compiled by a language-appropriate compiler 404.”; fig. 5 sec. 502; “Receive . . . one or more function objects”)
“training a transformer model defined in the Al model code using only the first one or more types of hardware platforms; (see, e.g., Kerr, fig. 6B & associated text; para. 64; “inference and/or training logic 615 illustrated in FIG. 6B may be used in conjunction with central processing unit (CPU) hardware, graphics processing unit (GPU) hardware or other hardware, such as field programmable gate arrays (FPGAs).”)
converting, by a compiler, the specialized function into executable code for a second type of hardware platform; and (see, e.g., Kerr, fig. 4 & associated text; para. 53; “a transformation and optimization module 412 can be used as discussed herein, along with an code generator module 414 to generate the final complied binary or lowered machine code for execution.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”)
performing inference only on the second type of hardware platform using the trained transformer model and the executable code.” (see, e.g., Kerr, fig. 6B & associated text; para. 64; “inference and/or training logic 615 illustrated in FIG. 6B may be used in conjunction with an application-specific integrated circuit (ASIC), such as Tensorflow® Processing Unit from Google, an inference processing unit (IPU) from Graphcore™, or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”).
Regarding claim 2, Kerr anticipates “The method of claim 1, wherein the first one or more types of hardware platforms are capable of executing different types of Al models, (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”) and the second type of hardware platform is optimized for only one type of Al model.” (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow® Processing Unit from Google, an inference processing unit (IPU) from Graphcore™, or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”).
Regarding claim 3, Kerr anticipates “The method of claim 2, wherein the first one or more types of hardware platforms comprise at least one of a central processing unit (CPU) or a graphics processing unit (GPU).” (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”).
Regarding claim 4, Kerr anticipates “The method of claim 2, wherein the second type of hardware platform comprises a model-specific chipset optimized to execute only transformer models.” (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow® Processing Unit from Google1 . . . or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”).2
Regarding claim 6, Kerr anticipates “The method of claim 1, wherein the specialized function, when compiled, results in a fused kernel in the first and second type of hardware platforms.” (see, e.g., Kerr, para. 42-43, 46-47; fig. 4 sec. 408, 416; para. 53; “a procedural code generator 408 or other application interface can compile user-supplied functionality to be fused with the kernels. In at least one embodiment, a compilation manager 416 can assist with the compilation, which may include various instances of compiled code 406 to be fused.”; para. 54; “one or more application-supplied functions can be fused with a coded implementation of one or more compute-limited workloads”).
Regarding claim 7, Kerr anticipates “The method of claim 6, wherein the specialized function comprises a plurality of lower-level functions defined by a machine learning (ML) or Al framework that are executed sequentially by the fused kernel.” (see, e.g., Kerr, para. 47, 53-54; “one or more application-supplied functions can be fused with a coded implementation of one or more compute-limited workloads . . . such fusion can provide for a performance and energy improvement with respect to separate execution . . . an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality . . . such fusion can also reduce overall code size for the functionality.”).
Regarding claim 8, Kerr anticipates “The method of claim 7, wherein converting the specialized function into the executable code further comprises: translating, by the compiler, the specialized function into an intermediate representation (IR); (see, e.g., Kerr, fig. 4 & associated text; para. 53; fig. 5 sec. 505-506; “each function object is compiled 504 to obtain an intermediate representation. In at least one embodiment, an intermediate, or partially-compiled, representation of a compute-limited operation, such as a convolution kernel, is obtained 506.”) and
converting the IR into the executable code, wherein the IR comprises values of arguments that configure the second type of hardware platform to perform the plurality of lower-level functions defined in the specialized function.” (see, e.g., Kerr, fig. 4 & associated text; para. 53-54; “an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”).
Regarding claim 9, Kerr anticipates “The method of claim 1, wherein converting the specialized function into the executable code further comprises: translating, by the compiler, the specialized function into an intermediate representation (IR); (see, e.g., Kerr, fig. 4 & associated text; para. 53; fig. 5 sec. 505-506; “each function object is compiled 504 to obtain an intermediate representation. In at least one embodiment, an intermediate, or partially-compiled, representation of a compute-limited operation, such as a convolution kernel, is obtained 506.”) and
converting the IR into the executable code, wherein the IR comprises values of arguments for performing at least one of matrix multiplication or attention operations on the second type of hardware platform.” (see, e.g., Kerr, fig. 4 & associated text; para. 52-54; “a matrix multiply”; “an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”).
Regarding claim 10, Kerr anticipates “The method of claim 1, wherein the compiler supports a plurality of specialized functions for the first one or more types of hardware platforms but supports only a limited number of lower-level functions of an ML or Al framework.” (see, e.g., Kerr, fig. 4 & associated text; para. 53-54; “an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”).
Regarding claim 11, Kerr discloses “A non-transitory computer readable medium having program instructions embodied therewith, the program instructions executable by a processor to perform an operation, the operation comprising:
receiving an artificial intelligence (Al) model code containing a specialized function for one or more types of hardware platforms; (see, e.g., Kerr, fig. 4 & associated text; para. 53; “a programmer has written an implementation of a basic convolution with hooks in place, as represented by static kernels 402 to be compiled by a language-appropriate compiler 404.”; fig. 5 sec. 502; “Receive . . . one or more function objects”)
translating, by a compiler, the specialized function into an intermediate representation (IR); (see, e.g., Kerr, fig. 4 & associated text; para. 53; fig. 5 sec. 505-506; “each function object is compiled 504 to obtain an intermediate representation. In at least one embodiment, an intermediate, or partially-compiled, representation of a compute-limited operation, such as a convolution kernel, is obtained 506.”) and
converting, by the compiler, the IR into executable code for a second type of hardware platform, (see, e.g., Kerr, fig. 4 & associated text; para. 53-54; “an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”)
wherein the one or more types of hardware platforms are used only for training a transformer model defined in the AI model code (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow®3 Processing Unit from Google . . . or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”)4 and the second type of hardware platform is used only for performing inference using the trained transformer model and the executable code.” (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as . . . an inference processing unit (IPU) from Graphcore™).5
Regarding claim 12, Kerr anticipates “The non-transitory computer readable medium of claim 11, wherein the first one or more types of hardware platforms are capable of executing different types of Al models, (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”) and the second type of hardware platform is optimized for only one type of Al model, (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow® Processing Unit from Google, an inference processing unit (IPU) from Graphcore™, or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”) wherein the first one or more types of hardware platforms comprise at least one of a central processing unit (CPU) or a graphics processing unit (GPU).” (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”).
Regarding claim 13, Kerr anticipates “The non-transitory computer readable medium of claim 11, wherein the first one or more types of hardware platforms are capable of executing different types of Al models (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”) and wherein the second type of hardware platform comprises a model-specific chipset that is optimized to execute only transformer models, (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow® Processing Unit from Google6 . . . or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”).7
Regarding claim 15, Kerr anticipates “The non-transitory computer readable medium of claim 11, wherein the specialized function, when compiled, results in a fused kernel in the first and second type of hardware platforms, (see, e.g., Kerr, para. 42-43, 46-47; fig. 4 sec. 408, 416; para. 53; “a procedural code generator 408 or other application interface can compile user-supplied functionality to be fused with the kernels. In at least one embodiment, a compilation manager 416 can assist with the compilation, which may include various instances of compiled code 406 to be fused.”; para. 54; “one or more application-supplied functions can be fused with a coded implementation of one or more compute-limited workloads”) wherein the specialized function comprises a plurality of lower-level functions defined by a machine learning (ML) or Al framework that are executed sequentially by the fused kernel.” (see, e.g., Kerr, para. 47, para. 54; “one or more application-supplied functions can be fused with a coded implementation of one or more compute-limited workloads . . . such fusion can provide for a performance and energy improvement with respect to separate execution . . . an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality . . . such fusion can also reduce overall code size for the functionality.”).
Regarding claim 16, Kerr anticipates “The non-transitory computer readable medium of claim 15, wherein the IR comprises values of arguments that configure the second type of hardware platform to perform the plurality of lower-level functions defined in the specialized function.” (see, e.g., Kerr, fig. 4 & associated text; para. 53-54; “an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”).
Regarding claim 17, Kerr anticipates “A system, comprising: one or more processors; and memory storing a compiler (see, e.g., Kerr, fig. 4 sec. 410) which, when executed by the one or more processors, performs an operation comprising:
receiving artificial intelligence (Al) model code containing a specialized function for a first one or more types of hardware platforms; (see, e.g., Kerr, fig. 4 & associated text; para. 53; “a programmer has written an implementation of a basic convolution with hooks in place, as represented by static kernels 402 to be compiled by a language-appropriate compiler 404.”; fig. 5 sec. 502; “Receive . . . one or more function objects”)
translating the specialized function into an intermediate representation (IR); (see, e.g., Kerr, fig. 4 & associated text; para. 53; fig. 5 sec. 505-506; “each function object is compiled 504 to obtain an intermediate representation. In at least one embodiment, an intermediate, or partially-compiled, representation of a compute-limited operation, such as a convolution kernel, is obtained 506.”) and
converting the IR into executable code for a second type of hardware platform, (see, e.g., Kerr, fig. 4 & associated text; para. 53-54; “an architecture can take advantage of specialized compiler behavior that would not be feasible to disclose to compile an entire application . . . such architecture can enable a hardware vendor to combine sensitive IP, or proprietary functionality, with user-supplied functionality without disclosing the proprietary functionality.”; fig. 5 sec. 508-510; “an in-lining pass is performed 508 in order to insert compiled function(s) at one or more call locations corresponding to hooks in the partially compiled kernel. In at least one embodiment, one or more optimizations are performed.”)
wherein the memory further stores a transformer model defined in the AI model code that is trained using only the first one or more types of hardware platforms (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow®8 Processing Unit from Google . . . or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”)9 and the trained transformer model and the executable code are used to perform inference only on the second type of hardware platform.” (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as . . . an inference processing unit (IPU) from Graphcore™).10
Regarding claim 18, Kerr anticipates “The system of claim 17, wherein the first one or more types of hardware platforms are capable of executing different types of Al models, (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”) and the second type of hardware platform is optimized for only one type of Al model, (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”) wherein the first one or more types of hardware platforms comprise at least one of a central processing unit (CPU) or a graphics processing unit (GPU).” (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”).
Regarding claim 19, Kerr discloses “The system of claim 17, wherein the first one or more types of hardware platforms are capable of executing different types of Al models, (see, e.g., Kerr, para. 63; “may be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware”) and wherein the second type of hardware platform comprises a model-specific chipset that is optimized to execute only transformer models.” (see, e.g., Kerr, para. 63; “an application-specific integrated circuit (“ASIC”), such as Tensorflow®11 Processing Unit from Google . . . or a Nervana® (e.g., “Lake Crest”) processor from Intel Corp.”)12
Response to Arguments
Applicant’s amendments have overcome all standing objections and those objections are withdrawn. Applicant’s amendments have necessitated new grounds of rejection, set forth above. Applicants remarks in traversal of the standing rejections are (1) moot insofar as they address the Salvator reference, which is no longer cited in the rejections, and (2) not persuasive insofar as they address the Kerr reference, for at least the reasons set forth above in the new grounds of rejection.
Conclusion
Applicant's amendments necessitated any new grounds of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN D COYER whose telephone number is 571-270-5306. The examiner can normally be reached Monday-Friday 12pm-10pm Eastern Time. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui, can be reached at 571-272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/ docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Ryan D. Coyer/Primary Examiner, Art Unit 2191
1 https://en.wikipedia.org/wiki/Tensor_Processing_Unit
2 https://simplecore.intel.com/ai/wp-content/uploads/sites/69/16433-1_NNP-announce_NNP-T_brief_v43.pdf, Nov. 2019; (“The Intel® Nervana™ Neural Network Processor for Training (Intel® Nervana™ NNP-T) enables advanced AI systems for large-scale deep learning training.”).
3 https://en.wikipedia.org/wiki/Tensor_Processing_Unit
4 See footnote 2; (“The Intel® Nervana™ Neural Network Processor for Training (Intel® Nervana™ NNP-T) enables advanced AI systems for large-scale deep learning training.”).
5 https://www.graphcore.ai/products/ipu; https://en.wikipedia.org/wiki/Graphcore
6 https://en.wikipedia.org/wiki/Tensor_Processing_Unit
7 https://simplecore.intel.com/ai/wp-content/uploads/sites/69/16433-1_NNP-announce_NNP-T_brief_v43.pdf, Nov. 2019; (“The Intel® Nervana™ Neural Network Processor for Training (Intel® Nervana™ NNP-T) enables advanced AI systems for large-scale deep learning training.”).
8 https://en.wikipedia.org/wiki/Tensor_Processing_Unit
9 See footnote 2; (“The Intel® Nervana™ Neural Network Processor for Training (Intel® Nervana™ NNP-T) enables advanced AI systems for large-scale deep learning training.”).
10 https://www.graphcore.ai/products/ipu; https://en.wikipedia.org/wiki/Graphcore
11 https://en.wikipedia.org/wiki/Tensor_Processing_Unit
12 See footnote 2; (“The Intel® Nervana™ Neural Network Processor for Training (Intel® Nervana™ NNP-T) enables advanced AI systems for large-scale deep learning training.”).
Prosecution Insights