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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-4, 14 and 17-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Specifically, claim 1 recites, compile the processing block to machine code, however, claims 3 and 4 further define the claimed compilation of claim 1 in a manner that is inconsistent with their parent claim 1. The new compilation as required by claims 3 and 4 adds an additional conditional circular decision step based on whether the code has been previously compiled or not.
Claim 14 is a medium claim reciting limitations similar to claims 3 and 4 and is rejected under the same rationale.
Claims 17-18 are method claims reciting limitations similar to claims 3-4 and are rejected under the same rationale.
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.
Claim(s) 1, 2, 5, 8, 9, 10, 13, 15, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Persson et al. (US20120272223A1)
Regarding Claim 1, Persson teaches a computing device comprising: a memory storing a script comprising computer-executable instructions; a communications interface; a processor interconnected with the memory and the communications interface, the processor configured to: initiate execution of the script ([0041-0042] "Upon execution of the host program 40 in bytecode format on the CPU 20, one or more non-executable code portions corresponding to the one or more source code kernels 48 will in an initial step 202 be determined as being embedded in the host program. This determination may, for example, be based on detecting the function clCreateProgram-FromSource for each source code kernel 48 in the host program 40 (see the above source code snippet of the host program 40). Conventionally, this function is implemented to invoke a local OpenCL run-time compiler. In the present embodiment, the function is instead implemented to request executable code for the source code kernel 48 from the network server 14. To this end, an executable code request is generated for the detected source code kernel 48. Then, in step 204, this request is sent via the interface 32 to the network server 14. In one variant, the embedded source code kernel 48 is extracted as a source code string from the host program 40, and the request includes the extracted source code kernel 48 for which executable code is requested. In another variant, only an identifier of the source code kernel 48 is transmitted together with the request to the network server 14 as, in certain scenarios, the transmission of the source code kernel 48 can be omitted. As an example, the source code kernel 48 may have already been transmitted earlier (e.g., upon an earlier detection of the source code kernel 48 in the host program 40), or the network server 14 may have access to the source code kernel 48 via a local database. The identifier of the source code kernel 48 may be derived from an URL string embedded in the host program 40." Also [0029]. [0037] shows the [script] host program code 40.
PNG
media_image1.png
407
612
media_image1.png
Greyscale
)
during the execution of the script: identify, within the script, a processing block to be executed on a target device ([0037] embedded_code in the host program 40 is the processing block to executed on the target device. [0041] “Upon execution of the host program 40 in bytecode format on the CPU 20, one or more non-executable code portions corresponding to the one or more source code kernels 48 will in an initial step 202 be determined as being embedded in the host program. This determination may, for example, be based on detecting the function clCreateProgram-FromSource for each source code kernel 48 in the host program 40 (see the above source code snippet of the host program 40). Conventionally, this function is implemented to invoke a local OpenCL run-time compiler. In the present embodiment, the function is instead implemented to request executable code for the source code kernel 48 from the network server 14. To this end, an executable code request is generated for the detected source code kernel 48. Then, in step 204, this request is sent via the interface 32 to the network server 14." [0011] "The non-executable code portion may be embedded in the host program in various ways. For example, the non-executable code portion may itself be embedded in the host program or may be embedded in the host program in the form of a link, reference or identifier pointing to a location of the non-executable code portion. This location may be on the client device itself or in the network. According to one variant, the non-executable code portion is embedded in the host program in the form a character string. The character string may comprise the non-executable code portion in the form of a source code. Alternatively, the character string may take the form of a Universal Resource Locator (URL) string pointing to the non-executable code portion. The URL may, for example, point to the remote network server and, in one scenario, to the specific executable code to be requested.")
compile the processing block to machine code for execution on the target device ([0037] the clCreateProgram-FromSource function compiles the code for the target device as per [0041] “Upon execution of the host program 40 in bytecode format on the CPU 20, one or more non-executable code portions corresponding to the one or more source code kernels 48 will in an initial step 202 be determined as being embedded in the host program. This determination may, for example, be based on detecting the function clCreateProgram-FromSource for each source code kernel 48 in the host program 40 (see the above source code snippet of the host program 40). Conventionally, this function is implemented to invoke a local OpenCL run-time compiler. In the present embodiment, the function is instead implemented to request executable code for the source code kernel 48 from the network server 14. To this end, an executable code request is generated for the detected source code kernel 48. Then, in step 204, this request is sent via the interface 32 to the network server 14.” and [0043-0044] "In addition to the source code kernel 48 or an identifier thereof, further information may be sent to the network server 14. This additional information may relate to the specific hardware and software environment of the client device 10 to make sure that the compiled code returned by the network server 14 conforms to the hardware and software environment deployed on the client device 10. Additionally, or as an alternative, mode setting information pertaining to the client device 10 may be transmitted to the network server 14. This additional information may be used by the network server 14 when obtaining the requested executable code as will be described below. In step 206, the executable code request is received by the network server 14 via the interface 50. The request is accompanied by the source code kernel 48 or its identifier (and, optionally, by hardware/software information and/or mode setting information pertaining to the device). In a next step 208, the network server 14 obtains the requested executable code pertaining to the source code kernel 48. In one embodiment, the component 52 of the network server compiles the source code kernel 48 received via the request (or retrieved from a local database) to generate the requested executable code (i.e., binary or machine code). In an alternative embodiment, the requested executable code is readily available in the server cache 54 (e.g., because a similar compilation task has already been requested by the client device 10 or another client device earlier).")
deploy the machine code to the target device for execution ([0047] "Once the executable code has been obtained by compilation or any other means, the network server 14 returns the executable code via the interface 50 and the communication network 12 to the client device 10 in step 210. The executable code is then received by the client device 10 via interface 32 in step 212. Moreover, in step 214, the host program 40 stores the received code in the local cache 34 and triggers execution of the received executable code by the associated processing element 42, 44 or 46. In the case of tasks which are to be performed in parallel (such as certain graphical tasks), the host program 40 may trigger execution of the received executable code by two or more PEs (such as PE 42 and PE 44 of GPU core 28) in parallel.")
Persson teaches the usage of a host program to coordinate the identification, compilation and deployment of the kernel on the target device as shown in the code snippet in [0037]. The instant application’s spec [0005, 0030] describe the script as comprising a series of computer-executable instructions. It would have been obvious to a person of ordinary skill in the art to understand that the code snippet in [0037] performs the functions corresponding to the script claimed in claim 1.
Regarding Claim 2, Persson teaches the computing device of claim 1, wherein the processor is configured to, during execution of the script: define configuration parameters for the target device ([0012] "The method may further comprise the steps of determining a mode setting of the device, and sending information indicative of the mode setting to the network server. The network server may then obtain the executable code taking into account the mode setting information. In a further variation, a mode setting change of the device may be determined. In response to determining the mode setting change, a new request for the executable code may be triggered. The executable code received in response to this new request may have been obtained by the network server taking into account the new mode setting. The mode setting may generally relate to one or more operating modes of the device. These operating modes may, for example, comprise at least one of a performance mode (e.g., high performance/low performance) and a power mode (e.g., regular power mode/power saving mode). It should be noted that the mode setting-related features could also be applied in single-core scenarios (e.g., in scenarios in which no differentiation between the host core on the one hand and the processing element on the other is made)." [0045] "When compiling the source code kernel 48 or retrieving the compiled executable code from the cache 54 or the local database, the additional information received from the client device 10 may be taken into account. For example, the compilation process may be controlled such that the compiled code conforms to the specific hardware and software environment of the client device 10. As an additional or alternative measure, the compilation may be controlled such that the specific mode setting information received from the client device 10 is considered. As an example, the mode setting information may relate to at least one of a performance mode (such as high performance/low performance) and a power mode (such as regular power mode/power saving mode) currently activated in the client device 10. In other words, the compilation may be controlled such that the resulting executable code assists, for example, power saving or high performance (e.g., gaming) settings of the client device 10.")
deploy the machine code to the target device according to the configuration parameters ([0043-0045)
Regarding Claim 5, Persson teaches the computing device of claim 1, wherein, to deploy the machine code, the processor is configured to: load the machine code to the target device ([0034-0035] "Generally, an OpenCL application can be regarded as a combination of programs running on a host (“host program”) on the one hand and on one or more OpenCL devices (“kernels”) on the other. In the present embodiment, a host program 40 will be executed on the core 26 (“host core”) of the CPU 20, while OpenCL devices are realized by the GPU 22 and the DSP 24. Each OpenCL device is defined as a collection of compute units, and each compute unit is composed of one or more Processing Elements (PEs). In the embodiment illustrated in FIG. 1, the GPU core 28 comprises two such PEs 42, 44, and the DSP core 30 comprises a single PE 46. The host program 40 executed on the host core 26 is configured to submit commands to the GPU 22 and DSP 24 to realize computation tasks on the PEs 42, 44, 46. The computation tasks are defined by one or more kernels 48 declared in the host program 40 and embedded in the host program in the form of non-executable source code portions. The host program 40 itself may be provided in the form of bytecode executable by the virtual machine running on the CPU 20." and [0047] "Once the executable code has been obtained by compilation or any other means, the network server 14 returns the executable code via the interface 50 and the communication network 12 to the client device 10 in step 210. The executable code is then received by the client device 10 via interface 32 in step 212. Moreover, in step 214, the host program 40 stores the received code in the local cache 34 and triggers execution of the received executable code by the associated processing element 42, 44 or 46. In the case of tasks which are to be performed in parallel (such as certain graphical tasks), the host program 40 may trigger execution of the received executable code by two or more PEs (such as PE 42 and PE 44 of GPU core 28) in parallel.")
cause the target device to execute the machine code ([0047])
Claims 8 and 9 are medium claims reciting limitations similar to claims 1 and 2 and are rejected for the same rationale.
Regarding Claim 10, Persson teaches the non-transitory machine-readable storage medium of claim 9, wherein the first instruction block and the second instruction block comprise instructions in a first programming language, and the processing block comprises instructions in a second programming language ([0037] "It will be appreciated that even after translating the host program 40 into bytecode, the kernels 48 will remain embedded in the resulting bytecode in their source code representation (e.g., in the form of character strings). The embedded source code representations will only be compiled at run-time of the host program 40 (typically during application launch) by the network server 14." EN: The code snippet shows the first and second block written in the C language, while the embedded kernel processing block is in bytecode)
Regarding Claim 13, Persson teaches the non-transitory machine-readable storage medium of claim 8, further comprising a compiler comprising computer-executable instructions which when executed cause the host device to compile the processing block to the machine code, wherein the compiler is invoked by the script to act on the processing block to compile the machine code ([0037] EN: specifically the kernel compile/build line of code.
PNG
media_image2.png
164
612
media_image2.png
Greyscale
)
Claims 15-16 are system claims that recite limitations similar to claims 1-2 and are rejected under the same rationale.
Claims 3-4, 14 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Persson et al. (US20120272223A1) in view of VanderSpek et al. (US8347310B1)
Regarding Claim 3, Persson teaches The computing device of claim 1. VanderSpek teaches wherein, to compile the processing block to the machine code, the processor is configured to:
apply a hash function to the processing block to obtain a hash value (Col 6, Ln 46-64, "FIG. 3 illustrates a device code repository 250, according to one embodiment of the present invention. Each function defined in the device source code 214 of FIG. 2 is stored as a multi-architecture function 305 within the device code repository 250. Each multi-architecture function 305 includes a key 310, information 312 and at least one version of virtual assembly 314. The key 310 is a hash function derived from the original source code of the function. Persons skilled in the art will recognize that hash functions may be used to generate relatively small, unique identifier tags, which may be used as the key 310, from arbitrarily large sets of data. In one embodiment, the pre-processed text of the function description code is hashed with a plain text comment describing the function to generate the key 310. Information 312 indicates, on a per-function basis, which architectural features were assumed when the machine code 316 and virtual assembly 314 where generated. Information 312 constitutes one element, of potentially many similar elements, stored in architecture information 248.")
Persson teaches reference the
when the 48 for which executable code is requested may have been cached by the network server 14 when processing the initial request, the transmission of an identifier of the source code kernel 48 together with an indication of the mode setting change might suffice. The network server 14 then recompiles the (cached) source code kernel 48 taking into account the new mode setting of the client device 10." Also see [0014 and 0018] EN: Presson uses a unique identifier. VanderSpek as explained teaches the usage of a hash value as a unique identifier. Also see VanderSpek "The driver for the co-processor inspects information within the application device code repository that defines architectural features of the available code. If appropriate machine code is available for a given function, then the driver invokes the machine code when the function is called to execute. If machine code is not available, then the virtual instruction translator within the driver compiles the best available virtual assembly into a new instance of machine code for the currently targeted co-processor. The new instance of machine code is stored in the device code repository and used for future invocations of the function.")
Persson and VanderSpek are analogous art because they are from the same field of endeavor in multiprocessor application compilation. VanderSpek teaches the use of hash values to create a unique identifier for functions and code in the repository. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Presson and VanderSpek to utilize VanderSpek’s known technique, hash creation for unique identification, as an additional method to the methods Presson uses to uniquely identify functions and code at run time for various functions without the risk of overlapping identifiers. Note MPEP 2143- (B) Simple substitution of one known element for another to obtain predictable results.
Regarding Claim 4. Persson in view of VanderSpek teaches the computing device of claim 3. Persson teaches wherein the processor is further configured to: when the 52 of the network server compiles the source code kernel 48 received via the request (or retrieved from a local database) to generate the requested executable code (i.e., binary or machine code). In an alternative embodiment, the requested executable code is readily available in the server cache 54 (e.g., because a similar compilation task has already been requested by the client device 10 or another client device earlier)." EN: Presson uses a unique identifier. VanderSpek as explained teaches the usage of a hash value as a unique identifier. Also see VanderSpek Col 10, Ln 43-53)
store the 10, Ln 43-53, "The driver for the co-processor inspects information within the application device code repository that defines architectural features of the available code. If appropriate machine code is available for a given function, then the driver invokes the machine code when the function is called to execute. If machine code is not available, then the virtual instruction translator within the driver compiles the best available virtual assembly into a new instance of machine code for the currently targeted co-processor. The new instance of machine code is stored in the device code repository and used for future invocations of the function.")
For motivation to combine see claim 3.
Claim 14 is a medium claim reciting limitations similar to claims 3 and 4 and is rejected under the same rationale.
Claims 17-18 are method claims reciting limitations similar to claims 3-4 and are rejected under the same rationale.
Claims 6-7, 11-12, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Persson et al. (US20120272223A1) in view of Becker et al. (US-20140063027-A1)
Regarding Claim 6, Persson teaches the computing device of claim 1. Becker teaches wherein the processing block comprises a unit test for a target compute unit of the target computing device (Becker, [0064] "This application is titled CUDA™ Cloud and allows a user to enter kernel code in the browser as well as JSON formatted parameters, submit them and see the result. CUDA™ Cloud is not meant as a front end for doing intense computation but could be useful for demonstrating how to write CUDA™ kernels and to quickly test or prototype kernels.")
Persson and Becker are analogous art because they are from the same field of endeavor in multiprocessor application compilation. Becker teaches the testing of code and analysis of performance metrices. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Presson and Beker to utilize Becker’s known technique, in the environment and process of Presson which teaches a compiling and deployment environment in order to better evaluate the performance of the code in the various runtime environments. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Regarding Claim 7, Persson teaches the computing device of claim 6. Becker teaches wherein the processor is further configured to obtain performance metrics for the target compute unit during execution of the unit test on the target device (Becker, [0086] "This implementation of the CUDA™ Web API shows benefits in performance and ability to simplify barriers to entry in using CUDA™. Although the performance tests show a benefit from use, it may be possible to lower the overall runtime associated with using the CUDA™ Web API. This may be done by streamlining data serialization, request processing, using a more intelligent work handler algorithm, or using multiple GPUs on the same worker to process requests in parallel." [0095] "This implementation of the CUDA™ Web API shows benefits in performance and ability to simplify barriers to entry in using CUDA™. Although the performance tests show a benefit from use, it may be possible to lower the overall runtime associated with using the CUDA™ Web API. This may be done by streamlining data serialization, request processing, using a more intelligent work handler algorithm, or using multiple GPUs on the same worker to process requests in parallel." Also see [0087-0091])
For motivation to combine see Claim 6.
Claims 11-12 are medium claims reciting limitations similar to claims 6-7 and are rejected under the same rationale.
Claims 19-20 are system claims reciting limitations similar to claims 6-7 and are rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kestner et al. (US 7721275 B2): discloses post pass optimizations in a dynamic compiling environment.
Grover et al. (US 20160011857 A1): discloses dynamic compiler parallelism techniques.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights