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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 - 36 are rejected under 35 U.S.C. 103(a) as being unpatentable over Munshi in view of Li et al. (hereinafter Li, US 2014/0208331).
Regarding claim 1, Munshi discloses:
one or more processor comprising:
circuitry to, in response to a call to an application programming interface (API), influence the scheduling policy information of one or more groups of blocks of one or more threads (at least ph. [0062] and for API calls that execute compute kernels with numbers of threads that may be in groups/blocks, and as this may be performed for any number of such groups/blocks and the kernels (therefore with their corresponding group/blocks of threads) may include priority values that affect scheduling order/policy as well as comprised event objects that indicate execution order relationships with execution instances associated with compute kernels).
Munshi does not expressly disclose, however, Li discloses:
circuitry to, in response to a call to an application programming interface (API), return to a caller of the API, scheduling policy information of one or more groups of blocks of one or more threads (see at least ph. [0069] for the calling of select_cores to select logical cores for thread groups (may be done for any number of these, including two or more) and returning a number of cores to be used (so returns information about the number of cores) to the scheduler that called select_cores provided, which then indicates, at least the policy of the scheduler to utilize that many cores as that then, based on system information, is apparently optimal).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Munshi by the teachings of Li in order to implement a way to allow a scheduling manager to invoke already available functions (as through an API) to allow them to perform its relative scheduling tasks (thereby avoiding the need to compose new functions that the existing functions already provide).
Regarding claims 2, 11, 20 and 29 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi discloses:
a scheduling policy is to apply to a group of multiple groups of one or more groups of blocks of one or more threads, the multiple groups being of a software kernel to be performed (at least ph. [0062] discloses that the API itself may specify for the number of thread groups/blocks that are executed as / in the kernel).
Regarding claims 3, 12, 21 and 30 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi discloses:
a scheduling policy is to apply to multiple partitions of multiple groups of one or more blocks of one or more threads (at least ph. [0062] discloses that different numbers of groups/blocks may be specified by the API, which indicates that the groups are distinct from one another (i.e. each is partitioned/separate from the other groups) and that the groups are to be schedule for execution according to the scheduling related to the scheduling of the execution queue).
Regarding claims 4, 13, 22 and 31 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi discloses:
a scheduling policy is to prioritize scheduling of one or more first groups of blocks of one or more threads over one or second groups of blocks of one or more threads (at least ph. [0062] discloses priority for kernel execution (which then applies to the API calls and their associated thread groups/blocks) and that the compute kernel execution instance involved in such execution, through an event object that indicated an execution order relationship between the execution instance and other execution instances (which then is a prioritizing schedule).
Regarding claims 5, 14, 23 and 32 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi does not expressly disclose, however Li discloses:
the scheduling policy information indicates a scheduling policy that is a spread policy (see at least ph. [0069] for the calling of select_cores to select logical cores for thread groups (may be done for any number of these, including two or more) and returning a number of cores to be used (so returns information about the number of cores) to the scheduler that called select_cores provided, which then indicates, at least the policy of the scheduler to utilize that many cores as that then, based on system information, is apparently optimal and as it is selecting cores (emphasis on plural form) it indicates that multiple cores are intended for use, thereby spreading the processing of the threads and their groups, which results in a spread policy implementation).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Munshi by the teachings of Li in order to implement a way to allow a scheduling manager to invoke already available functions (as through an API) to allow them to perform its relative scheduling tasks (thereby avoiding the need to compose new functions that the existing functions already provide).
Regarding claims 6, 15, 24 and 33 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi does not expressly disclose, however Li discloses:
the scheduling policy information indicates a scheduling policy that is a load balancing policy (see at least ph. [0069] for the calling of select_cores to select logical cores for thread groups (may be done for any number of these, including two or more) and returning a number of cores to be used (so returns information about the number of cores) to the scheduler that called select_cores provided, which then indicates, at least the policy of the scheduler to utilize that many cores as that then, based on system information, is apparently optimal and as it is selecting cores (emphasis on plural form) it indicates that multiple cores are intended for use, thereby spreading the processing of the threads and their groups where this then lends itself to attaining other features discloses in at least ph. [0023] that allows coscheduled threads through cores that improves load balancing, resulting in the selected cores resulting in a policy that facilitates said balancing).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Munshi by the teachings of Li in order to implement a way to allow a scheduling manager to invoke already available functions (as through an API) to allow them to perform its relative scheduling tasks (thereby avoiding the need to compose new functions that the existing functions already provide).
Regarding claims 7, 16, 25 and 34 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi discloses:
in response to the call to the API is to cause a scheduling policy to be applied when the one or more groups of blocks of the one or more threads are to be performed (at least ph. [0062] discloses that API calls result in thread group(s)/blocks as part of a kernel to be executed and that these have priority values associated with them, which then results in a different order of execution (a scheduling policy result)).
Regarding claims 8, 17, 26 and 35 the rejections of claims 1, 10, 19 and 28 are incorporated and Munshi discloses:
the scheduling policy is to affect scheduling of one or more groups of blocks of one or more threads on multiprocessors of a graphics processing unit (CPU) (at least ph. [0062] discloses the scheduling of different groups of threads (as a group of threads is properly considered as a block of threads, then different groups of threads represents groups of blocks of threads) and at least ph. [0039] discloses that the processing of such calls handled by groups of threads are performed by different physical computing devices, including multiple CPUs and GPUs, where at least ph. [0030] discloses that the multiple CPUs may be multi-core CPUs, and thus such multi-core CPUs will then handling the processing for the groups of threads).
Regarding claim 9, the rejection of claim 1 is incorporated and Munshi discloses:
a block to be performed according to a scheduling policy is a member of the one or more groups of blocks associated with the scheduling policy information (at least ph. [0062] discloses that API calls result in thread group(s)/blocks as part of a kernel to be executed and this may be for any number of thread groups/blocks, further these have priority values associated with them, which then results in a different order of execution (a scheduling policy result)).
Regarding claim 10, Munshi discloses:
in response to a call to an application programming interface (API), scheduling policy information is established for one or more groups of blocks of one or more threads (at least ph. [0062] and for API calls that execute compute kernels with numbers of threads that may be in groups/blocks, and as this may be performed for any number of such groups/blocks and the kernels (therefore with their corresponding group/blocks of threads) may include priority values that affect scheduling order/policy as well as comprised event objects that indicate execution order relationships with execution instances associated with compute kernels).
Munshi does not expressly disclose, however, Li discloses:
returning, in response to a function call to an application programming interface (API), scheduling policy information of one or more groups of blocks of one or more threads (see at least ph. [0069] for the calling of select_cores to select logical cores for thread groups (may be done for any number of these, including two or more) and returning a number of cores to be used (so returns information about the number of cores) to the scheduler that called select_cores provided, which then indicates, at least the policy of the scheduler to utilize that many cores as that then, based on system information, is apparently optimal).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Munshi by the teachings of Li in order to implement a way to allow a scheduling manager to invoke already available functions (as through an API) to allow them to perform its relative scheduling tasks (thereby avoiding the need to compose new functions that the existing functions already provide).
Regarding claim 18 the rejection of claim10 is incorporated and Munshi discloses:
scheduling policy information corresponds to an identifier of the one or more groups of blocks included in the call to the API (see at least ph. [0062] where the number of thread groups and total number of threads may be specified (i.e. identifies) in the API calls and this then corresponds to the kernel and its respective priority (and therefore scheduling) which then includes the priority of its respective groups of threads).
Claim 19, is a computer system version of claim 1 and is similarly rejected as claim 1, where it is noted that Munshi discloses the use of processors, memory storing instructions to perform the features claimed in at least Fig. 1 and this figure’s related descriptions in ph. [0030] – [0034].
Regarding claim 27 the rejection of claim 19 is incorporated and Munshi discloses:
use the scheduling policy information to control performance of the one or more groups of blocks (see at least ph. [0062] where the priority scheduling of the kernel then controls the scheduling of that kernels respective groups / blocks of threads).
Claim 28, is a non-transitory machine-readable medium version of claim 1 and is similarly rejected as claim 1, where it is noted that Munshi discloses the use of a medium storing instructions to be performed by one or more processors as per the features claimed in claim 28 in at least Fig. 1 and this figure’s related descriptions in ph. [0030] – [0034].
Regarding claim 36 the rejection of claim 28 is incorporated and Munshi discloses:
the scheduling policy information indicates scheduling policy to control performance of the one or more clusters, wherein each cluster comprises one or more groups of blocks of threads (see at least ph. [0035] discloses a plurality of thread groups across multiple computer processors may execute a computer program executable in parallel (acting then as a cluster of groups of blocks of threads) and then this corresponds to the kernel to execute program executables that then have a priority and that kernels priority then affects the priority and scheduling of its comprised groups/blocks of threads).
Other References Cited Not Relied Upon
Pechanec et al. (US 2015/0199787) discloses a scheduler to make API calls to schedule concurrent execution of a plurality of threads.
Biggerstaff (US 2011/0314448) discloses parts of a computation for candidates for parallel threads while using a thread APIs limits on parameters and how to work around errors in threads APIs.
Chetlur et al. (US 2021/0133583) discloses cooperative launch APIs that support synchronization amongst thread blocks for execution of parallel algorithms.
Response to Arguments
Applicant’s arguments have been fully considered but are moot in light of new groups of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CRAIG C DORAIS whose telephone number is (571)270-3371. The examiner can normally be reached M-F 9:00 am - 6:00pm.
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, Pierre Vital can be reached at 5712724215. 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.
/CRAIG C DORAIS/Primary Examiner, Art Unit 2198
Prosecution Insights