DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Applicant Amendment and Arguments filed on 03 April, 2026.
Claims 1-2, 4-12 and 14-21 are pending in this application. Claims 3 and 13 were canceled.
Response to Amendment
The amendment to the claims filed on 03 April, 2026 does not comply with the requirements of 37 CFR 1.121(c) because in claim 20, the text of deleted matter fails to show by strike-through (i.e., the limitation of “launch a first task on a first subset of a plurality of multiprocessors based on a first task descriptor included in the plurality of task descriptors” has been deleted, but the claim filed on 03 April, 2026 does not show by strike-through). Amendments to the claims filed on or after July 30, 2003 must comply with 37 CFR 1.121(c) which states:
(c) Claims. Amendments to a claim must be made by rewriting the entire claim with all changes (e.g., additions and deletions) as indicated in this subsection, except when the claim is being canceled. Each amendment document that includes a change to an existing claim, cancellation of an existing claim or addition of a new claim, must include a complete listing of all claims ever presented, including the text of all pending and withdrawn claims, in the application. The claim listing, including the text of the claims, in the amendment document will serve to replace all prior versions of the claims, in the application. In the claim listing, the status of every claim must be indicated after its claim number by using one of the following identifiers in a parenthetical expression: (Original), (Currently amended), (Canceled), (Withdrawn), (Previously presented), (New), and (Not entered).
(2) When claim text with markings is required. All claims being currently amended in an amendment paper shall be presented in the claim listing, indicate a status of “currently amended,” and be submitted with markings to indicate the changes that have been made relative to the immediate prior version of the claims. The text of any added subject matter must be shown by underlining the added text. The text of any deleted matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show deletion of five or fewer consecutive characters. The text of any deleted subject matter must be shown by being placed within double brackets if strike-through cannot be easily perceived. Only claims having the status of “currently amended,” or “withdrawn” if also being amended, shall include markings. If a withdrawn claim is currently amended, its status in the claim listing may be identified as “withdrawn—currently amended.”
For purpose of examination, examiner will treated the limitation of “based on a first task descriptor included in the plurality of task descriptors” has been deleted.
Claim Rejections - 35 USC § 112(b)
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.
Claim 21 is rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
As per claim 21:
In line 4, it recites the phrase “a first data dependency”. However, prior to this phrase, in claim 11, at line 21, it recites “a first data dependency”. Thus, it is unclear whether the second recitation of “a first data dependency” is the same or different from the first recitation of “a first data dependency”. If they are the same, the or said should be used. For examining purpose, examiner will interpret it as the same one.
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-2, 5, 7-12 and 17-21 are rejected under 35 U.S.C. 103 as being unpatentable over Alt et al. (US Patent. 11,677,681 B1) in view of Terechko et al. (US Pub. 2011/0004881 A1) and further in view of Agarwal et al. (US Pub. 2019/0171497 A1), Raman et al. (US Pub. 2016/0196162 A1) and HIROTA et al. (US Pub. 2020/0401444 A1).
Alt, Terechko, Agarwal, Raman and HIROTA were cited in the previous Office Action.
As per claim 1, Alt teaches the invention substantially as claimed including A parallel computing system (Alt, Fig.2) comprising:
a plurality of multiprocessors (Alt, Fig. 2, 230A-230H GPUs; Col 1, lines 31-34, many smaller tasks that are distributed to large numbers of processors such as central processing units (CPUs) or graphics processing units (GPUs) that work in parallel to complete them more quickly); and
one or more circuits coupled to the plurality of multiprocessors (Alt, Col 3, lines 14-18, The system may include a management node that is connected via one or more networks a group of non-uniformly interconnected computing resources (e.g., CPUs, GPUs, memory, storage); Col 3, lines 10-13, a management application that is stored on computer-readable storage medium (e.g., hard drives, solid state drives or “SSDs”) and run on a management server/node (as including circuit, see Fig. 1, 140, server computer) in the computing system) that:
launch a first task on a first subset of the plurality of multiprocessors, launch the second task on a second subset of the plurality of multiprocessors, the second task are executed by the second subset of the plurality of multiprocessors (Alt, Col 13, line 40 to Col 14, line 14, a management node interacting with the plurality of interconnected computing processors, wherein the management node comprises…a scheduler configured to receive at least a first computing job and a second computing job and schedule the first and second computing jobs for execution, wherein the first and second computing jobs respectively comprise one or more processes, wherein the scheduler is further configured to i) allocate and bind the processes associated with the first computing job to a first subset of the plurality of interconnected computing processors and ii) allocate and bind the processes associated with the second computing job to a second subset of the plurality of interconnected computing processors (as launch the first/second tasks on the first/second subset of the plurality of multiprocessors)).
Alt fails to specifically teach the parallel computing system is parallel processor, prior to launching a second task, determines that a first scheduling dependency associated with the second task is unresolved, wherein the first scheduling dependency specifies that the second task is dependent on the first task; before the completion of the first task, resolve the first scheduling dependency based on the pre-exit trigger; and in response to the resolution of the first scheduling dependency and before the completion of the first task, launches the second task.
However, Terechko teaches the parallel computing system is parallel processor (Terechko, [0002] lines 1-4, The current trend in computer architecture is to use more and more microprocessors, a.k.a. cores, within one chip for processing tasks in parallel to increase application performance; also see Fig. 6, 32 (as work scheduler) that coupled to processors 10-16)),
prior to launching a second task, determines that a first scheduling dependency associated with the second task is unresolved, wherein the first scheduling dependency specifies that the second task is dependent on the first task (Terechko, Fig. 4, 2a first task, 2b second task; [0010] lines 5-18, While a task is being executed, it may be possible to find out what dependencies will be solved by the currently executed task by assuming that the currently executed task is finished. This allows for verifying, whether a next task is ready or not, prior to finishing the processing of the currently processed task. If there are tasks that only depend (as first scheduling dependency) on the currently executed task, they will be ready for execution, once the currently executed task is finished. In order to provide for immediate starting the ready tasks, these could be prepared for execution by a task management unit, such that once the current processor (core) finishes the current execution, the next task can start (as prior to launching a second task). Dependencies can be updated in parallel with the execution of the task, thus decreasing task execution time; [0020] lines 11-14, A dependency pointer may hold the address to a memory location that stores the number of dependencies that still have to be resolved before the task can be executed (as determines that a first scheduling dependency is unresolved prior to launching a second task and to resolve later));
before the completion of the first task, resolve the first scheduling dependency based on a pre-exit trigger (Terechko, [0020] lines 7-20, The look-ahead pointer may comprise information about a look-ahead function (as pre-exit trigger) to be executed if the task will be executed by the core. This function may allow for calculating and determining, which dependencies are resolved, when the currently processed task is executed. A dependency pointer may hold the address to a memory location that stores the number of dependencies that still have to be resolved (i.e., dependency resolving is necessary before the task can start it) before the task can be executed…The flag may allow for calculating and determining, which dependencies are resolved, when the currently processed task is executed; [0020] lines 32-35, The look-ahead function (as pre-exit trigger) may check, which tasks may be necessary in the future. If these tasks are dependent on the currently processed task, their dependency can be updated (as resolves the first scheduling dependency based on a pre-exit trigger); also see Fig. 4, task 2a with 20 a readiness verifying stage; [0043] lines 5-13, For each task 2, 4, 6, 8, within the verifying stage 20, in parallel to processing the tasks, a look-ahead code is being executed for verifying, whether these tasks provide for readiness of a consecutive task. In the illustrated example, in the verifying stage 20, for the first task 2a, executed on processor 10, a candidate task 2b was found with its dependencies fulfilled (as first scheduling dependency). This second task 2b can be started immediately, once processor 10 finishes the current execution of task 2a); and
in response to the resolution of the first scheduling dependency, launches the second task (Terechko, [0043] lines 5-13, For each task 2, 4, 6, 8, within the verifying stage 20, in parallel to processing the tasks, a look-ahead code is being executed for verifying, whether these tasks provide for readiness of a consecutive task. In the illustrated example, in the verifying stage 20, for the first task 2a, executed on processor 10, a candidate task 2b was found with its dependencies fulfilled (as first scheduling dependency). This second task 2b can be started immediately, once processor 10 finishes the current execution of task 2a).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt with Terechko because Terechko’s teaching of resolving the dependency prior the completion of the current task and before starting subsequence task would have provided Alt’s system with the advantage and capability to allow the system to immediately executing the subsequence/dependent tasks upon the current task finished which improving the system performance and efficiency (see Terechko, [0008])
Although Alt and Terechko teach resolution of the first scheduling dependency based on the pre-exit trigger, Alt and Terechko fail to specifically teach wherein the first task includes a pre-exit trigger following a first set of producer instructions included in the first task and preceding a second set of producer instructions included in the first task, wherein the first set of producer instructions, the pre-exit trigger, and the second set of producer instructions are executed sequentially; wherein the execution of at least the second set of the producer instructions produces data consumed by the second task, during execution of the first task, resolve the first scheduling dependency based on execution of the pre-exit trigger included in the first task, wherein the pre-exit trigger included in the first task identifies the second task as a consumer task, and wherein resolve the first scheduling dependency based on the pre-exit trigger indicates that a data-independent set of instructions associated with the second task can proceed and a first data dependency associated with the second task remains until a data dependency instruction of the second task are reached, and wherein, before the completion of the first task, at least a portion of the data-independent set of instructions associated with the second task are executed.
However, Agarwal teaches wherein the first task includes a pre-exit trigger following a first set of producer instructions included in the first task and preceding a second set of producer instructions included in the first task, wherein the first set of producer instructions, the pre-exit trigger, and the second set of producer instructions are executed sequentially (Agarwal, Fig. 14, 1430 set of instruction a producer thread (as first task), instruction inserted by compiler (score card incremented when dependency resolved) (as pre-exit trigger), the instructions before the trigger as first set of producer instructions, instructions after the trigger (as second set of producer instructions) that send the data (in the middle of the producer thread, send to the consumer thread 1440 set of instructions of a consumer thread; (i.e., they are executed sequentially); [0044] lines 5-12, That is, for at least some embodiments, the compiler of the plurality of streams inserts instructions into the producer threads and the consumer threads, wherein the inserted instructions cause the producer threads to indicate when a dependency has been resolved, and cause the consumer threads to check for resolution of the dependency when the consumer thread has progressed far enough along to need the resolution of the dependency; [0092] lines 1-7, if the dependency resolution of the producer thread is earlier in the set of instructions of the thread as for the producer thread 1430, and the dependency of the consumer thread occurs later in the set of instructions of the consumer thread 1440, then efficiency is gained by dispatching the consumer thread before resolution of the dependency as in the mode 1 of operation);
wherein the execution of at least the second set of the producer instructions produces data consumed by the second task (Agarwal, Fig. 14, producer thread 1430, the data was send by at least second set of producer instructions (after dependency resolved) to the consumer thread during the execution of producer thread; [0069] lines 1-7, the producer thread provides an indication of satisfaction of dependency resolution upon satisfying the resolution, not necessarily when the producer thread has completed execution. That is, dependency can be resolved in the middle of the producer thread's execution, and the dependent thread need not wait for the producer thread to completely finish, provided that the amount of data needed is ready);
during execution of the first task, resolve the first scheduling dependency based on execution of the pre-exit trigger included in the first task during execution of the first task (Agarwal, Fig. 14, 1430 set of instructions of a producer thread, instruction inserted by compiler (score card incremented when dependency resolved), (as pre-exit trigger); [0069] lines 1-7, the producer thread provides an indication of satisfaction of dependency resolution upon satisfying the resolution, not necessarily when the producer thread has completed execution. That is, dependency can be resolved in the middle of the producer thread's execution, and the dependent thread need not wait for the producer thread to completely finish, provided that the amount of data needed is ready. also see [0091] instruction inserted by the compiler (wherein the inserted instruction causes the thread to update the thread manager of resolution of the dependency (as resolve the first scheduling dependency based on execution of the pre-exit trigger included in the first task));
wherein resolve the first scheduling dependency based on pre-exit trigger indicates that a data-independent set of instructions associated with the second task can proceed and a first data dependency associated with the second task remains until a data dependency instruction of the second task are reached, and wherein, before the completion of the first task, at least a portion of the data-independent set of instructions associated with the second task are executed (Agarwal, Fig. 14, 1430 set of instruction of a producer thread (as first task), 1440 set of instruction of a consumer thread (as second task), instruction inserted by compiler (check for resolution of dependency) (as a first data dependency associated with the second task remains until a data dependency instruction of the second task are reached (i.e., reached for check the dependency resolution); the instruction before the check for resolution of dependency as data-independent set of instructions associated with the second task can proceed; [0035] lines 1-8, the dependency is resolved post-dispatching of the child thread if the dependency is not at the beginning of the child thread-since there is overlap possible in the execution of the child and twin thread, and resources in the processor are not unnecessarily locked down. If the top of consumer thread is not dependent on the producer thread, then the dependency is resolved post-dispatch; [Examiner notes: the top portion of the consumer thread is not dependent on the producer thread, so this portion is executed at same time with the producer thread (i.e., overlap possible execution), that is, data-independent set of instructions associated with the second task can proceed and a first data dependency associated with the second task remains (i.e., the later portion of the consumer task that need the data from producer remains until a data dependency instruction of the second task are reached (i.e., check for resolution of dependency), and the top portion of second task is executed before completion of the producer task); see Fig. 14]; also see [0055] lines 5-11, wherein processing of at least one of the threads is dependent upon processing of another of the plurality of threads, wherein the plurality of threads include producer threads and dependent threads, and wherein producer threads produces data for dependent threads and dependent threads consume data produced by producer threads).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt and Terechko with Agarwal because Agarwal’s teaching of processing the top portion of the consumer task/thread (i.e., data independent portion) in parallel with the top portion of the producer task/thread would have provided Alt and Terechko’s system with the advantage and capability to allow the system to reducing the execution time which improving the system performance and efficiency (see Agarwal, [0047] “the execution time reduces considerably which results in higher performance”).
Although Alt, Terechko and Agarwal teach parallel processing that launch the second task and at least a portion of the data-independent set of instructions associated with the second task are executed before the completion of the first task, Alt, Terechko and Agarwal fail to explicitly teach that when launch the second task and at least a portion of the data-independent set of instructions associated with the second task are executed, it is in response to the resolution of the first scheduling dependency and before the completion of the first task.
However, Raman teaches when launch the second task and at least a portion of the data-independent set of instructions associated with the second task are executed, it is in response to the resolution of the first scheduling dependency and before the completion of the first task (Raman, [0072] lines 1-10, In the example illustrated in FIG. 9B, the enforcement condition represented by the parameter ‘user_select_more_results’ returned true, indicating that Task D may ignore the inter-task dependency on Task B. Task C has already finished execution at block 910, thus all of Task D's dependencies are resolved. In block 918 Task D becomes ready (since its dependencies on Task C and Task B have been resolved). In block 920 Task D begins execution, and in block 922 Task D finishes execution without waiting for Task B to finish execution; [0069] lines 12-13, Task D may be allowed to execute in parallel with or prior to Task C finishing; (as in response to the resolution of the first scheduling dependency (i.e., dependencies on Task C and Task B have been resolved) and before the completion of the first task (i.e., Task C or B finishing), the second task is launched (i.e., Task D begins execution); [0042] lines 1-4, A task may include any procedure, unit of work, or sequence of operations (as including at least a portion of a data-independent set of instructions, since it is executed prior to Task B or C completion and after resolving of the dependencies, i.e., enforcement of electively dependent, so no more dependency of prior tasks); also see [0009] lines 1-3, identifying whether any additional operations of the second task are either dependent or selectively dependent on any additional tasks) that may be executed in a processing unit via a thread).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko and Agarwal with Raman because Raman’s teaching of selective enforcement of inter-task execution dependencies for resolving of the dependencies would have provided Alt, Terechko and Agarwal’s system with the advantage and capability to allow the system to resolving the dependency and launching at least selectively dependent portion of tasks (i.e., portion of a data-independent set of instructions) before the prior tasks are finished which improving the system processing time and efficiency.
Alt, Terechko, Agarwal and Raman fail to specifically teach wherein the pre-exit trigger included in the first task identifies the second task as a consumer task.
However, HIROTA teaches wherein the pre-exit trigger included in the first task identifies the second task as a consumer task (HIROTA, Fig. 5, 510(1) Dependency resolution latency, 522 Task descriptor prefetch “task C” (As pre-exit trigger identifies the second task as a consumer task); [0076] lines 8-13, the task descriptor prefetch for a consumer task completes before the completion of the task execution of the producer task. As a result, the memory load associated with the task descriptor prefetch does not contribute to the dependency resolution latency between the producer task and the consumer task; [0077] lines 2-6, issue a “task descriptor prefetch command” for a specified task. The task descriptor prefetch command causes the dependency/prefetch unit 410 to execute a task descriptor prefetch for the specified task (as identifies the second task as a consumer task); [0129] A true value for the descriptor prefetch flag associated with consumer task Y triggers the task management unit to automatically prefetch the consumer task descriptor of consumer task Y when launching task X)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal and Raman with HIROTA because HIROTA’s teaching of prefetching the task descriptor that indicating consumer task for resolving the dependency would have provided Alt, Terechko, Agarwal and Raman’s system with the advantage and capability to allow the system to reduce the overall time required to execute the workload which improving the system performance and efficiency (see HIROTA, [0060]).
As per claim 2, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. Terechko teaches wherein the pre-exit trigger comprises execution of a scheduling dependency instruction (Terechko, [0020] lines 7-20, The look-ahead pointer may comprise information about a look-ahead function (as pre-exit trigger, a scheduling dependency instruction) to be executed if the task will be executed by the core. This function may allow for calculating and determining, which dependencies are resolved, when the currently processed task is executed. A dependency pointer may hold the address to a memory location that stores the number of dependencies that still have to be resolved (i.e., dependency resolving is necessary before the task can start it) before the task can be executed…The flag may allow for calculating and determining, which dependencies are resolved, when the currently processed task is executed; [0020] lines 32-35, The look-ahead function (as pre-exit trigger) may check, which tasks may be necessary in the future. If these tasks are dependent on the currently processed task, their dependency can be updated).
In addition, Agarwal teaches the scheduling dependency instruction included in the first task (Agarwal, Fig. 9, instruction inserted by compiler (as scheduling dependency instruction included in the first task); [0053] lines 2-9, the producer thread includes a set of instructions, wherein each instruction is represented by a horizontal line. For an embodiment, the instructions of the producer thread include an instruction that was inserted by the compiler of the thread that causes a scorecard within a thread manager of the graph streaming processor to be incremented when the dependency has been satisfied; [0054] lines 5-14, the compiler inserts (in the consumer thread block of code) a dependency check instruction right before the instruction/s that consume the data from the producer thread. When the producer thread reaches the point in the thread that the dependency has been resolved, the thread provides the indication of the dependency resolution to the thread manager. When the consumer thread reaches the point in the thread in which the dependency is needed, the thread checks thread manager for resolution of the dependency).
As per claim 5, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. Agarwal further teaches wherein subsequent to execution of the first task, the one or more circuits further: indicate a release of the first data dependency associated with the second task, wherein the first data dependency specifies that the second task is dependent on data produced by the execution of the first task, and wherein the release of the first data dependency enables an execution of the second task to proceed past the data dependency instruction that blocks the execution of the second task until the release of the first data dependency (Agarwal, Fig. 9, instruction inserted by compiler (check for resolution of dependency) in the consumer thread (as second task) (as to data dependency instruction that blocks the execution of the second task until the release of the first data dependency); [0053] lines 5-9, the instructions of the producer thread include an instruction that was inserted by the compiler of the thread that causes a scorecard within a thread manager of the graph streaming processor to be incremented when the dependency has been satisfied; [0055] lines 5-11, wherein processing of at least one of the threads is dependent upon processing of another of the plurality of threads, wherein the plurality of threads include producer threads and dependent threads, and wherein producer threads produces data for dependent threads and dependent threads consume data produced by producer threads; [0054] lines 1-14, a compiler that generates the blocks of code that form the threads of each stage and inserts (in the producer thread block of code) an instruction right after the instruction/s that produce the data for the consumer thread to increment a counter. Further, the compiler inserts (in the consumer thread block of code) a dependency check instruction right before the instruction/s that consume the data from the producer thread (as a release of first data dependency associated with the second task). When the producer thread reaches the point in the thread that the dependency has been resolved, the thread provides the indication of the dependency resolution to the thread manager. When the consumer thread reaches the point in the thread in which the dependency is needed, the thread checks thread manager for resolution of the dependency (as the release of the first data dependency enables an execution of the second task to proceed past a data dependency instruction that blocks the execution of the second task until the release of the first data dependency (see Fig. 9, after the instruction of check for resolution in the consumer task, the consumer thread consume the data produced by the producer thread)).
In addition, HIROTA further teaches wherein subsequent to execution of the first task, the one or more circuits further: determine that each multiprocessor included in the first subset of the plurality of multiprocessors has completed a memory flush (HIROTA, Fig. 5, task execution 560(1) “task A” (as first task), Memory flush 510(1) “task A”, count update 518(1); [0063] lines 1-4, The task configuration 450 includes, without limitation, any amount and type of data used to configure components of the PPU 202 (e.g., the processing cluster array 230, the GPCs 208, the SMs 310, etc.) to perform the associated task; [0098] lines 1-6, after the completion of the task execution 560(1) of task A, the SMs 310 that participated in the task execution 530(1) perform a memory flush 510(1) for task A. After the completion of the memory flush 510(1) for task A, the dependency/prefetch unit 410 executes a count update 518(1) for task A. As part of the count update 518(1) for task A, the dependency/prefetch unit 410 decrements the current count 444 associated with task B. (as determines that memory flush is finished, therefore for executing the task B; please note: first subset of the plurality of multiprocessors was taught by Alt)).
As per claim 7, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. HIROTA further teaches wherein prior to launching the second task, the one or more circuits further initiates a retrieval of one or more instructions associated with the second task from a memory (HIROTA, [0134] lines 1-3, prior to launching the second task, initiating a retrieval of one or more instructions associated with the second task from the memory).
As per claim 8, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. In addition, HIROTA further teaches wherein prior to launching the second task, the one or more circuits further initiates a retrieval of one or more constants associated with the second task from a memory (HIROTA, Fig. 7A, 720 constants cached? No 722 execute constant fetch, 724 initiate task execution of task; [0060] lines 1-17, To reduce the overall time required to execute the workload specified via the task graph 128, a dependency/prefetch unit 410 included in the task management unit 234 implements prefetch and self-reset functionality. The prefetch functionality caches any number of the task descriptor 430, instructions, and constants of a consumer task at a time when the associated memory load is likely to be subsumed by activities associated with a producer task. For each consumer task of a producer task, the task descriptor 430 of the producer task specifies whether prefetch functionality is enabled for each of the task descriptor 430, instructions, and constants of the consumer task. When the dependency/prefetch unit 410 reads the task descriptor 430, the enabled prefetch functionality is triggered. When triggered, the prefetch functionality reduces the resolution dependency latency between the producer task and the consumer task; [0135] lines 1-3, retrieval of one or more constants associated with the second task from the memory).
As per claim 9, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. Terechko teaches wherein the pre-exit trigger comprises a scheduling dependency instruction (Terechko, [0020] lines 7-20, The look-ahead pointer may comprise information about a look-ahead function (as pre-exit trigger, a scheduling dependency instruction) to be executed if the task will be executed by the core. This function may allow for calculating and determining, which dependencies are resolved, when the currently processed task is executed. A dependency pointer may hold the address to a memory location that stores the number of dependencies that still have to be resolved (i.e., dependency resolving is necessary before the task can start it) before the task can be executed…The flag may allow for calculating and determining, which dependencies are resolved, when the currently processed task is executed).
In addition, Agarwal teaches the first task comprises a first plurality of instructions that includes the scheduling dependency instruction, and a second plurality of instructions that follow the scheduling dependency instruction (Agarwal, Fig. 9, instruction inserted by compiler (as scheduling dependency instruction included in the first task), the after that inserted instruction is followed by second plurality of instructions; [0053] lines 2-9, the producer thread includes a set of instructions, wherein each instruction is represented by a horizontal line. For an embodiment, the instructions of the producer thread include an instruction that was inserted by the compiler of the thread that causes a scorecard within a thread manager of the graph streaming processor to be incremented when the dependency has been satisfied).
As per claim 10, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. Agarwal further teaches wherein the data- independent set of instructions precede the data dependency instruction included in the second task, wherein the data dependency instruction is associated with the first data dependency of the second task on the first task, and wherein a data-dependent set of instructions included in the second task follow the data dependency instruction (Agarwal, Fig. 9, consumer thread (as second task), bottom of the consumer thread is data- independent set of instructions precede a data dependency instruction included in the second task, instruction inserted by Compiler (check for resolution of dependency) (as data dependency instruction) which is associated with instruction of producer thread (as first task); [0053] lines 5-9, the instructions of the producer thread include an instruction that was inserted by the compiler of the thread that causes a scorecard within a thread manager of the graph streaming processor to be incremented when the dependency has been satisfied; [0055] lines 5-11, wherein processing of at least one of the threads is dependent upon processing of another of the plurality of threads, wherein the plurality of threads include producer threads and dependent threads, and wherein producer threads produces data for dependent threads and dependent threads consume data produced by producer threads; [0054] lines 1-14, a compiler that generates the blocks of code that form the threads of each stage and inserts (in the producer thread block of code) an instruction right after the instruction/s that produce the data for the consumer thread to increment a counter. Further, the compiler inserts (in the consumer thread block of code) a dependency check instruction right before the instruction/s that consume the data from the producer thread. When the producer thread reaches the point in the thread that the dependency has been resolved, the thread provides the indication of the dependency resolution to the thread manager. When the consumer thread reaches the point in the thread in which the dependency is needed, the thread checks thread manager for resolution of the dependency (as a data-dependent set of instructions included in the second task follow the data dependency instruction, as data-dependent set of instructions of second task can keep executing)).
As per claim 11, it is a computer-implemented method claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 12, it is a computer-implemented method claim of claim 2 above. Therefore, it is rejected for the same reason as claim 2 above.
As per claim 17, it is a computer-implemented method claim of claim 7 above. Therefore, it is rejected for the same reason as claim 7 above.
As per claim 18, it is a computer-implemented method claim of claim 8 above. Therefore, it is rejected for the same reason as claim 8 above.
As per claim 19, it is a computer-implemented method claim of claim 9 above. Therefore, it is rejected for the same reason as claim 9 above.
As per claim 20, it is a system claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, HIROTA further teaches a memory that stores a plurality of task descriptors (HIROTA, [0005] lines 5-6, initiating a retrieval of a task descriptor…from a memory; [0033] lines 2-23, the work distribution unit 236 receives pointers to processing tasks that are encoded as task descriptors (not shown in FIG. 2) and stored in memory…the task descriptor could specify the number and configuration of the set of CTAs. Generally, each task descriptor corresponds to one task. The task management unit 234 receives tasks from the host interface unit 232 and ensures that the GPCs 208 are configured to a valid state before the processing task specified by each one of the task descriptors is initiated. A priority may be specified for each task descriptor that is used to schedule the execution of the processing task; also see [0062] any number of the task descriptors 430. Each of the task descriptors 430 is a data record that describes a different task that is to be performed by one or more threads executing on the SMs 310).
As per claim 21, it is a method claim of claim 10 above. Therefore, it is rejected for the same reason as claim 10 above.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Alt, Terechko, Agarwal, Raman and HIROTA, as applied to claims 1 and 11 respectively above, and further in view of Natu et al. (US Pub. 2020/0192798 A1).
Natu was cited in the previous Office Action.
As per claim 4, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 1 above. Alt, Terechko, Agarwal, Raman and HIROTA fail to specifically teach wherein during execution of the first task, the one or more circuits further broadcasts a memory flush request to the first subset of the plurality of multiprocessors.
However, Natu teaches wherein during execution of the first task, the one or more circuits further broadcasts a memory flush request to the first subset of the plurality of multiprocessors (Natu, [0083] lines 3-8, a host processor connected to a set of devices (e.g., including switch devices or other devices, which themselves, may be connected to further devices downstream from the host processor) (please note: first subset of the plurality of multiprocessors was taught by Alt) may detect 1302 a flush-triggering event (e.g., an abnormal shutdown, power failure, fatal system error, etc.) and initiate a persistent memory flush flow; [0171] lines 3-7, send instances of a cache flush request to a set of devices connected to the host processor device, where the cache flush request corresponds to a start of a first phase of a persistent memory flush flow and requests that data in cache memory in the set of devices be flushed).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal, Raman and HIROTA with Natu because Natu’s teaching of initiate/broadcasts the memory flush request to the set of devices for memory flushing would have provided Alt, Terechko, Agarwal, Raman and HIROTA’s system with the advantage and capability to performing the memory flush based on detecting an abnormal status which improving the system reliability and performance.
As per claim 14, it is a computer-implemented method claim of claim 4 above. Therefore, it is rejected for the same reason as claim 4 above.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Alt, Terechko, Agarwal, Raman and HIROTA, as applied to claim 5 above, and further in view of Raman et al. (US Pub. 2016/0217016 A1; hereafter Raman‘016’) and KAMO et al. (US Pub. 2021/0103400 A1).
Raman‘016’ was cited in the previous Office Action.
As per claim 6, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 5 above. Alt, Terechko, Agarwal, Raman and HIROTA fail to specifically teach wherein the data dependency instruction determines that the first data dependency has been released based on an entry associated with the first data dependency being removed from the task dependency table.
However, Raman‘016’ teaches wherein the data dependency instruction determines that the first data dependency based on the task dependency table (Raman, Fig. 8, 804, traverse the table to determine whether one or more of the tasks have multiple predecessors or multiple successors; [0098] lines 3-3-14, a task dependency controller of the computing device may generate, add, and/or allocate a record of the table to identify a dependency relationship between two tasks. The record may identify a predecessor task, a successor task, and a program counter of the successor task. In block 804, the task dependency controller may traverse the table to determine whether one or more of the tasks have multiple predecessors or multiple successors. In block 806, the task dependency controller may delete the record from the table in response to determining that the tasks have multiple predecessors or multiple successors).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal, Raman and HIROTA with Raman’016’ because Raman’016’’s teaching of determining the dependencies and releasing the dependencies based on the table would have provided Alt, Terechko, Agarwal, Raman and HIROTA’s system with the advantage and capability to allow the system to easily determining the dependencies for the different tasks which improving the scheduling efficiency and system performance.
Alt, Terechko, Agarwal, Raman, HIROTA and Raman’016’ fail to specifically teach determine the first data dependency has been released based on an entry associated with the first data dependency being removed from the task dependency table.
However, KAMO teaches determine the first data dependency has been released based on an entry associated with the first data dependency being removed from the task dependency table (KAMO, Fig. 17, page release process, S1701 does page able to be released exist, YES to instruct to release page S1702, No to End; [0160] lines 1-12, The distributed FS migration section 111 references the migration source volume release region management table 563 and determines whether an entry that indicates “deleted” in all cells of the entry in the file usage status 1307 exists (or whether a releasable physical page exists) (in step S1701). When the distributed FS migration section 111 determines that the releasable physical page exists, the distributed FS migration section 111 causes the process to proceed to step S1702 (i.e., need to release). When the distributed FS migration section 111 determines that the releasable physical page does not exist, the distributed FS migration section 111 terminates the page release process (as determine that [first data dependency] has been released based on an entry associated with the [first data dependency] being removed from the [task dependency] table; please note: first data dependency and task dependency table were taught by Alt, Terechko, Agarwal, Raman, HIROTA and Raman’016’)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal, Raman, HIROTA and Raman’016’ with KAMO because KAMO’s teaching of determining releasing status based on the entry status within the table (i.e., whether exist or not) would have provided Alt, Terechko, Agarwal, Raman, HIROTA and Raman’016’’s system with the advantage and capability to allow the system to easily tracking the releasing status which improving the system performance and efficiency.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Alt, Terechko, Agarwal, Raman and HIROTA, as applied to claim 11 above, and further in view of Vaidya et al. (US Patent. 8,732,714 B2).
Vaidya was cited in the previous Office Action.
As per claim 15, Alt, Terechko, Agarwal, Raman and HIROTA teach the invention according to claim 11 above. HIROTA further teaches subsequent to execution of the first task: determining that each multiprocessor included in the first subset of the plurality of multiprocessors has completed a memory flush (HIROTA, Fig. 5, task execution 560(1) “task A” (as first task), Memory flush 510(1) “task A”, count update 518(1); [0063] lines 1-4, The task configuration 450 includes, without limitation, any amount and type of data used to configure components of the PPU 202 (e.g., the processing cluster array 230, the GPCs 208, the SMs 310, etc.) to perform the associated task; [0098] lines 1-6, after the completion of the task execution 560(1) of task A, the SMs 310 that participated in the task execution 530(1) perform a memory flush 510(1) for task A. After the completion of the memory flush 510(1) for task A, the dependency/prefetch unit 410 executes a count update 518(1) for task A. As part of the count update 518(1) for task A, the dependency/prefetch unit 410 decrements the current count 444 associated with task B. (as determines that memory flush is finished, therefore for executing the task B; please note: first subset of the plurality of multiprocessors was taught by Alt)).
Alt, Terechko, Agarwal, Raman and HIROTA fail to specifically teach indicating a release of the first data dependency associated with a third task, wherein the first data dependency specifies that the third task is dependent on data produced by the execution of the first task, and wherein the release of the first data dependency enables an execution of the third task to proceed past the data dependency instruction that blocks the execution of the third task until the release of the first data dependency.
However, Vaidya teaches indicating a release of the first data dependency associated with a third task, wherein the first data dependency specifies that the third task is dependent on data produced by the execution of the first task, (Vaidya, Col 10, lines 41-55, Number of data dependencies: Number of data dependencies to be resolved before starting execution of the task. The API mentioned above (which will be inserted in the task program code) will essentially decrement this number implying that data dependency is resolved. Thus, initially this number represents number of data dependencies of this task. If the field is zero, it represent that all the data dependencies are resolved and the task is ready to run. (as indicating a release of a first data dependency associated with the third task) Number of tasks that becomes available due to execution of this task: This field tells how many other tasks (as include third task) are dependent on this task. This serves as priority of the task. If more tasks are dependent on this task, then it should be executed first among all available tasks. Data pointer: Pointer to data which is required for running the task); and wherein the release of the first data dependency enables an execution of the third task to proceed past the data dependency instruction that blocks the execution of the third task until the release of the first data dependency (Vaidya, Col 6, lines 7-12, Along the columns we have tasks becoming ready for execution. Each element in the i.sup.th row is equal to the time of releasing the task j in the jth column. Thus, Tij implies that the i.sup.th task will release the j.sup.th task after Tij time. Once released, the task j is ready for execution; Col 11, lines 32-33, LDT is the list of task IDs which get released during execution of the corresponding task; Also see Col 16, lines 31-42, claim 1, each of the plurality of tasks to determine data indicative of dependencies for each task, wherein the data indicative of the dependencies for each respective task of the plurality of tasks comprises an identification of any releasing tasks from which the respective task depends, wherein the respective task must wait until after the releasing task begins execution before the respective task can begin execution, and wherein the data indicative of the dependencies for each respective task further includes, for each releasing task from which the respective task depends, an offset time (as data dependency instruction that blocks the execution of third task) that must elapse after the releasing task begins execution before the respective task may begin execution).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal, Raman and HIROTA with Vaidya because Vaidya’s teaching of data dependency between different tasks and executing the dependent tasks once the first data dependency is released (i.e., release the previous task with offset time) would have provided Alt, Terechko, Agarwal, Raman and HIROTA’s system with the advantage and capability to allow the system to easily controlling the execution time for executing the dependent tasks which improving the scheduling efficiency and system performance.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Alt, Terechko, Agarwal, Raman, HIROTA and Vaidya, as applied to claim 15 above, and further in view of Raman et al. (US Pub. 2016/0217016 A1; hereafter Raman‘016’) and Figge et al. (US Patent. 7,739,234 B1).
Raman‘016’ was cited in the previous Office Action.
As per claim 16, Alt, Terechko, Agarwal, Raman, HIROTA and Vaidya teach the invention according to claim 15 above. Alt, Terechko, Agarwal, Raman, HIROTA and Vaidya fail to specifically teach wherein indicating the release of the first data dependency comprises updating a task dependency table to remove one or more entries associated with the first task.
However, Raman’016’ teaches updating a task dependency table to remove one or more entries associated with the first task (Raman, Fig. 8, 804, traverse the table to determine whether one or more of the tasks have multiple predecessors or multiple successors, 806, delete the record from the table (as update table); [0098] lines 3-3-14, a task dependency controller of the computing device may generate, add, and/or allocate a record of the table to identify a dependency relationship between two tasks. The record may identify a predecessor task, a successor task, and a program counter of the successor task. In block 804, the task dependency controller may traverse the table to determine whether one or more of the tasks have multiple predecessors or multiple successors. In block 806, the task dependency controller may delete the record from the table in response to determining that the tasks have multiple predecessors or multiple successors (as updating a task dependency table to remove one or more entries associated with the first task)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal, Raman, HIROTA and Vaidya with Raman’016’ because Raman’016’’s teaching of updating and removing the entries from the table based on the determination would have provided Alt, Terechko, Agarwal, Raman, HIROTA and Vaidya’s system with the advantage and capability to allow the system to easily determining the dependencies for the different tasks which improving the scheduling efficiency and system performance.
Although Alt, Terechko, Agarwal, Raman, HIROTA, Vaidya and Raman’016’ teach updating a task dependency table to remove one or more entries, Alt, Terechko, Agarwal, Raman, HIROTA, Vaidya and Raman’016’ fail to specifically teach wherein indicating the release of the first data dependency comprises updating a task dependency table to remove one or more entries.
However, Figge teaches wherein indicating the release of the first data dependency comprises updating a task dependency table to remove one or more entries (Figge, Col 4, lines 62-67, the original entry that was modified or changed may no longer have any dependencies, meaning that no other entries reference that entry for external tables or from other chains (e.g., object networks). Under such circumstances, a policy may permit the entry in the table to be removed entirely from the table to which it relates; Claim 5, removing, by the computer, the entry from the first original table if the entry is free of dependencies; (please notes: first data dependency and task dependency table were taught by Alt, Terechko, Agarwal, Raman, HIROTA, Vaidya and Raman’016’)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Alt, Terechko, Agarwal, Raman, HIROTA, Vaidya and Raman’016’ with Figge because Figge’s teaching of removing the entry when the dependency is released (i.e., associated with that entry) would have provided Alt, Terechko, Agarwal, Raman, HIROTA, Vaidya and Raman’016’’s system with the advantage and capability to allow the system to freeing the resources when the entry is released which improving the resource utilization and system performance.
Response to Arguments
In the remark applicant’s argue in substance:
(a), The Examiner rejected Claim 21 under 35 U.S.C. § 112(b), 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 pre-AIA the applicant regards as the invention. In this response, claim 21 has been amended to address the § 112(b) rejections. Withdrawal of thee rejection is therefore requested.
(b), In this response, amended claims 1, 11, and 20 make clear that the pre-exit
trigger is included in the producer task following a first set of producer instructions and preceding a second set of producer instructions. Agarwal expressly teaches the opposite. In particular, the instruction inserted into the producer thread, which the Examiner equates to the pre-exit trigger, is inserted "right after the instruction/s that produce the data" in Agarwal. See Agarwal at paragraph [0054]. Agarwal, therefore, cannot teach or suggest the amended claim 1, 11, and 20.
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), Examiner noted that applicant fails to address the § 112(b) rejection regarding to claim limitation of “a first data dependency” in claim 21, line 4. (see 112(b) rejection above, i.e., it is unclear whether the second recitation of “a first data dependency” (in claim 21) is the same or different from the first recitation of “a first data dependency” (in claim 11). If they are the same, the or said should be used). Therefore the rejections are maintained.
As to point (b), in response to applicant’s argument that “Agarwal expressly teaches the opposite. In particular, the instruction inserted into the producer thread, which the Examiner equates to the pre-exit trigger, is inserted "right after the instruction/s that produce the data" in Agarwal”. Examiner would like to point out that the “instruction inserted into the producer thread, "right after the instruction/s that produce the data" in Agarwal” which is one of the embodiment that taught by Agarwal (i.e., refers to Fig. 9). However, in another embodiment of Agarwal, it teaches the newly added claimed limitation of “wherein the first task includes a pre-exit trigger following a first set of producer instructions included in the first task and preceding a second set of producer instructions included in the first task, wherein the first set of producer instructions, the pre-exit trigger, and the second set of producer instructions are executed sequentially; wherein the execution of at least the second set of the producer instructions produces data consumed by the second task, during execution of the first task”. See Agarwal Fig. 14, right side, it has a producer thread 1430, which is executed, has first set of instructions before the instruction inserted by compiler that indicated when dependency resolved, and after that, it has second set of instructions that produce the data for the consumer thread 1440 for execution (also see [0044] lines 5-12, That is, for at least some embodiments, the compiler of the plurality of streams inserts instructions into the producer threads and the consumer threads, wherein the inserted instructions cause the producer threads to indicate when a dependency has been resolved, and cause the consumer threads to check for resolution of the dependency when the consumer thread has progressed far enough along to need the resolution of the dependency; [0092] lines 1-7, if the dependency resolution of the producer thread is earlier in the set of instructions of the thread as for the producer thread 1430, and the dependency of the consumer thread occurs later in the set of instructions of the consumer thread 1440, then efficiency is gained by dispatching the consumer thread before resolution of the dependency as in the mode 1 of operation). Please refers to 103 rejection above.
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
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 ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
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, Aimee J Li can be reached at (571) 272-4169. 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.
/ZUJIA XU/Examiner, Art Unit 2195
Prosecution Insights