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 et al. (hereinafter Munshi, US 2011/0285729) 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 for a block cluster comprising two or more groups of blocks of threads to perform a software kernel on one or more accelerators (at least Fig. 9 and ph. [0060] - [0062] and for API calls that execute compute kernels with numbers of threads that may be in various numbers of groups/blocks and group dimensions (where the dimension of a thread group dimension (at least in ph. [0060]) indicates a variable axis of related threads, i.e. equivalent to a related cluster of blocks of groups of threads), including two or more, 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 kernel objects where these kernels are placed in the execution queue as per at least ph. [0061] and at least ph. [0060] discloses that these kernels through their respective compute program executables are performed on GPUs when appropriate).
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 the block cluster (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 and at least ph. [0060] establishes thread group dimensions that establish block clusters).
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 the two or more groups of blocks of 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 and at least ph. [0060] establishes different dimensions of groups of threads which some of these dimensions then may establish partions of these groups).
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 a first group of the block cluster over a second groups of block cluster (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) and at least ph. [0060] establishes dimensions of groups of threads that form different logical relations of groups of the blocks of threads and there are multiples of these dimensions of groups of threads (i.e. multiple groups of block clusters, including first and second groups) and then the respective kernels would be subject to the prioritization established in the prioritization process of at least ph. [0062], which in instances will prioritize a first group of block clusters over a second group of block clusters).
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 two or more groups of blocks of 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) and the prioritization of the threads then will be applied to the respective groups and dimensions of groups of the threads as established in at least ph. [0060] and this includes two or more such groups and this occurs when the blocks of threads are being processed including, respectively, by the appropriate scheduling logic).
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 two or more groups of blocks of 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 and at least ph. [0060] establishes multiple dimensions of groups of blocks of threads which then includes two or more to which these scheduling of [0062] will then be applied).
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 two 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) and at least ph. [0060] establishes multiple dimensions of groups of blocks of threads which then includes two or more such groups and their component member threads, to which these scheduling of [0062] will then be applied).
Regarding claim 10, Munshi discloses:
in response to a call to an application programming interface (API), scheduling policy information is established for a block cluster comprising two or more groups of blocks of threads to perform a software kernel on one or more accelerators (at least ph. [0062] and for API calls that execute compute kernels with numbers of threads that may be in various numbers of groups/blocks and group dimensions (where the dimension of a thread group dimension (at least in ph. [0060]) indicates a variable axis of related threads, i.e. equivalent to a related cluster of blocks of groups of threads), including two or more, 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 kernel objects where these kernels are placed in the execution queue as per at least ph. [0061] and at least ph. [0060] discloses that these kernels through their respective compute program executables are performed on GPUs when appropriate).
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).
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 kernel’s 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).
Claims 1 – 17 and 19 - 36 are rejected under 35 U.S.C. 103(a) as being unpatentable over Munshi in view of Li and further in view of et al. (hereinafter Li, US 2014/0208331).
Regarding claim 18 the rejection of claim 10 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 and [0062] discloses that this number of compute processor).
Munshi does not expressly disclose, however, Kelly discloses:
a scheduling policy identifier is included in a call (see at least ph. [0151] for a parameter allows for a configurable GPU scheduling policy).
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, as modified by Li, by the teachings of Kelly in order to implement a means to invoke computing device control architecture to execute instructions in proper order to obtain intended / desirable results.
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 API’s 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 asserts that “neither [the references] teach ‘return, to the caller of the API, scheduling policy information for a block cluster comprising two or more groups of blocks of threads.” However, as the Munshi reference in at least ph. [0060] discloses multiple dimensions of groups of threads, the amended language, that Applicant appears to rely upon, is disclosed by Munshi. This is so as each dimension for these groups represents another logical layer of logical association of these groups of threads. As such, each dimension then may form its own logical grouping for a group of threads. Which is to say a cluster of groups of threads. As this may then apply to any number of dimensions, it then will result in instances of two or more such dimensions / two or more groups of blocks of threads.
As Applicant’s amendments and arguments fail to overcome the art of record, the previous rejections to claims 1 - 17 and 19 – 36 stand. A new ground of rejection has been provided for claim 18 in response to amendments to said claim.
Conclusion
Applicant's amendment necessitated the new ground(s) 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 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
