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 .
DETAILED ACTION
This action is in response to the communication filed on 04/18/2024.
Claims 1-24 are pending.
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.
Claims 1-24 are rejected under 35 U.S.C. 103 as being unpatentable over
Murphy et al., “Improving GPU Application Performance with NVIDIA CUDA 11.2
Device Link Time Optimization”, 2021, Nvidia Developer Technical Blog, 10 pages, and in view of CUDA, “NVIDIA CUDA compiler Driver, Release 12.3”, 2023, NVIDIA Corp., pp. i-iv, 1-64 (hereinafter: Cuda)
As per Claim 1: Murphy discloses limitation in bold below,
1. A processor, comprising: one or more circuits to perform a compiler to select one or more optimizations to one or more [first versions] of a program
(p.3, Figure 1 , selecting: a.o compile optimize either in middle chart or right chart of the Figure reads on “optimization” of a.cu. The whole program X.cu is device code from a.cu and b.cu: X.cu reads on “a program” , and a.cu reads on “first version”)
Murphy does not explicitly address limitation of “first version” of a program
based, at least in part, on a result of performing the one or more optimizations on one or more [second versions] of the program (Figure 1, “a.out” is from ‘a.o’, and a.out is required with the link/merge with compile optimize ‘b.o’ of b.cu which is device code in x.cu --“b.cu” reads on “second version” of the program X.cu, and the resulting a.out is also based on results of ‘b.o’ by link/merge – ‘b.o’ reads on “optimization” and because the resulting a.out is linked/merged with b.o, it reads on “based … on” ).
Murphy does not explicitly address the limitation of “second version” of the program .
Thus, with the selections of a.o and merged with b.o,
Murphy does not explicitly address “first version” and “second version” of the program x.cu.
Cuda discloses the limitations “first version” and “second version” of the program.
(Cuda: See in p. 45, second para in sec. 6.2, “In the CUDA naming scheme, GPUs are named sm_xy, where x denotes the GPU generation number, and y the version in that generation. Additionally, to facilitate comparing GPU capabilities, CUDA attempts to choose its GPU names such that if x1y1 <= x2y2 then all non-ISA related capabilities of sm_x1y1 are included in those of sm_x2y2.”,
See in p. 50, sec. 6.7.1 “while option --gpu-code takes a list of values which must all be the names of actual GPUs. nvcc performs a stage 2 translation for each of these GPUs, and will embed the result in the result of compilation (which usually is a host object file or executable).
Example
nvcc x.cu --gpu-architecture=compute_50 --gpu-code=sm_50, sm_52”.
Thus, x.cu is the program and sm_50: is first version with version #0, and sm_52 is second version with version #2 of the program x.cu.
where sm_50 and sm_52 are corresponding to a.cu and b.cu from x.cu according to in p. 58, sec. 7.6.4
“Then if a.cu and b.cu both include a.h and instantiate getptr for the same type, and b.cu expects a
non-NULL address, and compile with:
nvcc --gpu-architecture=compute_50 --device-c a.cu
nvcc --gpu-architecture=compute_52 --device-c b.cu
nvcc --gpu-architecture=sm_52 a.o b.o
”
Thus, with the above indications, the CUDA compiler processes a.cu, a version in gpu-architecture=compute_50 to a.o : optimization of “first version” of program x.cu, and it processes b.cu in gpu-architecture=compute_52 to b.o : optimization of “second version” of program x.cu.)
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to further combine the teaching of Murphy with compiling a.cu and b.cu of x.cu with the indication of the versions in the CUDA compiler of Cuda. The combination would yield predictable results because CUDA is compiling various versions of a program and is for conforming to naming convention used in CUDA compiler.
As per Claim 2: Murphy in combining Cuda, where
Murphy further discloses,
2. The processor of claim 1, wherein the compiler performs the one or more optimizations on the one or more first versions of the program .
(Murphy: p. 3, Figure 1, in the middle chart or right chart, referred to the performance in the path a.o )
As per Claim 3: Murphy in combining Cuda, where Murphy discloses limitation in bold,
3. The processor of claim 1, wherein the one or more optimizations [change at least one representation of at least one of the one or more second versions ] of the program.
(Murphy: See in p. 3, Figure 1, in the middle chart or right chart, referred to the performance in path b.o .
And see in p. 2: first partial paragraph,
“Separate compilation mode enabled developers to better design and organize device
kernel code and to GPU-accelerate many more existing applications without significant code refactoring effort to move all the device kernel code to a single source file. It also improved developer productivity for large parallel application development by only requiring re-compilations of device source files with incremental changes.”).
Murphy does not explicitly address optimization change on “change at least one representation of at least one of the one or more second versions”, rather merging the optimization of b.cu to form a.out .
Cuda discloses the limitations of “change at least one representation of at least one of the one or more second versions” (Cuda: in p. 45: third para in sec. 6.1
“Binary compatibility within one GPU generation can be guaranteed under certain conditions because
they share the basic instruction set. This is the case when two GPU versions do not show functional
differences (for instance when one version is a scaled down version of the other), or when one version
is functionally included in the other. An example of the latter is the base Maxwell version sm_50 whose
functionality is a subset of all other Maxwell versions: any code compiled for sm_50 will run on all other
Maxwell GPUs.”
And second para. in sec. 6.2,
“In the CUDA naming scheme, GPUs are named sm_xy, where x denotes the GPU generation number,
and y the version in that generation. Additionally, to facilitate comparing GPU capabilities, CUDA attempts
to choose its GPU names such that if x1y1 <= x2y2 then all non-ISA related capabilities of
sm_x1y1 are included in those of sm_x2y2.”
And
See in p. 53, sec. 7.1, “The code changes required for separate compilation of device code are the same as what you already do for host code,”.
Above discussions imply that b.cu is a second version (i.e. y2 in x1y1 <= x2y2) and it implements the changes from a.cu., and the compiling separation is for the purpose to merge the optimizations change in higher version compiled in b.cu, and the discussions read on “change at least one representation of at least one of the one or more second versions”
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to further combine the teaching for using separated compiling for code change as a second version in Cuda and the teaching using separated compiling in large program of Murphy. The combination would yield predictable results for conforming to the compiling requirement of separated compiling to large program code or version change in CUDA compiler for better compilation performance.
As per Claim 4: Murphy in combining Cuda, where
Murphy discloses limitation in bold,
4. The processor of claim 1, wherein performing the one or more optimizations on the one or more [ second versions] of the program comprises performing the one or more optimizations using one or more optimization passes,
(Murphy: with bold limitations, See Figure 1 or in p. 5, Figure 2, referred to the path b.o , the optimization passes is :the link or merge Optimize to result optimized executable a.out . )
wherein the one or more optimization passes change one or more intermediate representations of the program.
(As per above, Murphy, Figure 1 or Figure 2, referred to Compiled IR in the path b.o , the optimization passes is the link or merge Optimize to result optimized executable a.out.
Murphy does not explicitly address the limitation of “second versions”
Cuda discloses the limitation of “second version” as the b.cu provided with the same rationales in claim 1 for the reason to combine.
As per Claim 5: Murphy in combining Cuda, where
Murphy discloses limitations,
5. The processor of claim 1, wherein the compiler selects the one or more optimizations from a plurality of second optimizations (as in Figure 1 or Figure 2 with the b.o path)
But Murphy does not disclose the followed limitations a below.
Cuda discloses the limitations below:
performed on the one or more second versions of the program, wherein one or more of the second optimizations that do not change at least one representation of at least one of the second versions of the program are not included in the one or more optimizations.
(Cuda: See in p. 45, third para. in sec. 6.1
“Binary compatibility within one GPU generation can be guaranteed under certain conditions because
they share the basic instruction set. This is the case when two GPU versions do not show functional
differences (for instance when one version is a scaled down version of the other), or when one version
is functionally included in the other. An example of the latter is the base Maxwell version sm_50 whose
functionality is a subset of all other Maxwell versions: any code compiled for sm_50 will run on all other
Maxwell GPUs.” (emphasis added). – Thus, for the code that has not change/or the same in both versions, then the code will be run on its own version)
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to further combine the teaching for using separated compiling in the case that the code is not change, i.e. the code that is the same with other versions will not be included in the optimization in Cuda and the teaching using separated compiling in large program of Murphy. The combination would yield predictable results because it would save time in compilation, and thus for better compilation performance.
As per Claim 6: Murphy in combining Cuda, where
Murphy discloses limitations,
6. The processor of claim 1, wherein the result of performing the one or more optimizations (as in Figure 1 or Figure 2 with the b.o path)
But Murphy does not disclose the followed limitations a below.
Cuda discloses the limitations below:
on the one or more second versions of the program comprises an optimization profile specifying the one or more optimizations, and the compiler selects the one or more optimizations from the optimization profile.
(Cuda: See Fig. 1 in p. 54, y.cu as a second version, y.o / y.obj as one or more of the second optimizations, as the first select.
And see in p. 20 and p. 21 sec. 5.2.3, that includes profiling for debug purpose.)
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to further combine the teaching for using profiling optimization for debugging in Cuda, and the teaching using separate compiling in a large program by Murphy. The combination would yield predictable results because profiling is part of debugging in compilation, and it would obviously be included for conforming to debug requirements.
As per Claim 7: Murphy in combining Cuda, where
Murphy discloses limitation in bold,
7. The processor of claim 1, wherein the one or more circuits are further to perform the compiler to perform a plurality of second optimizations on the one or more [second versions] of the program,
(Murphy: with bold limitations, See Figure 1 or in p. 5, Figure 2, referred to the path b.o , the b.o is indicated as compile optimize or compiled IR, where this optimizations is selected in linker)
wherein the one or more optimizations are selected from the plurality of second optimizations based on one or more changes made by the plurality of second optimizations to one or more intermediate representations of the program.
(As per above, Murphy, Figure 1 or Figure 2, referred to Compiled IR in the path b.o , the optimization passes is the link or merge Optimize to result optimized executable a.out. I.e. see in the last 2 lines in p. 7: “Separate compilation mode also reduces the overall incremental build times when incremental changes are isolated to a few source files. When device link time optimization is enabled the compiler optimization phase is eliminated”)
Murphy does not explicitly address the limitation of “second versions”
Cuda discloses the limitation of “second version” as the b.cu provided with the same rationales in claim 1 for the reason to combine.
As per Claim 8: Murphy in combining Cuda, where Murphy does not explicitly the limitations below:
Cuda further discloses,
8. The processor of claim 1, wherein at least one of the one or more second versions of the program is the same as at least one of the one or more first versions of the program..
(Cuda: See in p. 45, third para. in sec. 6.1
“Binary compatibility within one GPU generation can be guaranteed under certain conditions because
they share the basic instruction set. This is the case when two GPU versions do not show functional
differences (for instance when one version is a scaled down version of the other), or when one version
is functionally included in the other. An example of the latter is the base Maxwell version sm_50 whose
functionality is a subset of all other Maxwell versions: any code compiled for sm_50 will run on all other
Maxwell GPUs.” (emphasis added). – Thus, for the code that has not change, i.e. the same in both versions, then the code will be run on its own version)
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to further combine the teaching of using separated compiling for various versions in separate compilation with the second version, including the code in the first version of Cuda, and the teaching using separated compiling in large program by Murphy. The combination would yield predictable results because, in higher versions, the code would be updated and included in the same code as the first version; it is only for conforming to code versioning.
As per claims 9-16: The claims are directed to a system and recite the limitations having functionality corresponding to the processor of claims 1-8 above. The claims are rejected with the same rationales addressed in claims 1-8.
As per claims 17-24: The claims are directed to a method and recite the limitations having functionality corresponding to the processor of claims 1-8 above. The claims are rejected with the same rationales addressed in claims 1-8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ted T Vo whose telephone number is (571)272-3706. The examiner can normally be reached 8am-4:30pm ET.
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 Y 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.
TTV
April 1, 2026
/Ted T. Vo/
Primary Examiner, Art Unit 2191
Prosecution Insights