Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Response to Arguments
Applicant’s arguments with respect to claim(s) 8/5/26 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC §103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim/s 1, 4, 5, 7, 10, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Purnomo (Pub. No. US 2023/0140822) in view of Shreve (Pub. No. US 2024/0069962).
Claim 1, 7, 13 Purnomo teaches “One or more processors, comprising: circuitry of one or more Parallel Processor Units (PPUs) to ([0020] As depicted in FIG. 1, GPU 170 may include several components, such as graphics queue 172, which may include computational units tailored for graphics processing, and asynchronous compute 174, which may include computational units tailored for compute tasks. Graphics queue 172 and asynchronous compute 174 may process tasks independently and in parallel. Memory 176 may include high bandwidth, low latency memory suitable for graphics and compute processing. While not specifically depicted, a data bus may also be used to allow communication between components of GPU 170. While the specific example depicted in FIG. 1 is focused on GPU 170, the principles of this application are generally applicable to any configuration of hardware resources. For example, application 140 may be configured to utilize a dedicated machine learning processor instead of, or in addition, to GPU 170.) and/or one or more Central Processing Units (CPUs) ([0017] Computing device 110 includes processor 120) to perform one or more application programming interfaces (API): modify a scheduling priority of a graph task of a graph executed on the one or more PPUs ([0038] For example, referring to FIG. 2B, processor 120 may present instruction 287B in profiler user interface 285B, wherein instruction 287B provides the step of modifying API calls matching “computeFunctionGPU(foo, bar, . . . )” to instead call “computeFunctionASYNC(foo, bar, . . . )” at lines 155 and 300 of the “render.cs” source code file. Since task 210C entirely uses the CS or compute shader pipeline stage, as indicated by legend 286, task 210C may be readily executed on asynchronous compute 174 by simply changing an API call function from one function to another function. If program debug information is unavailable, then the matching source code lines may be unavailable, in which case the user may instead perform a quick find and replace operation to modify the source code of application 140 accordingly. The user can therefore conclude that the implementation cost of the proposed optimization is low, and that a reduction of 1 millisecond in total execution time can be readily achieved. [0021] After using profiler 150 to generate profile data 155, for example by executing a trace or profiling on application 140, the user may view profiler user interface 185 on display 180. Profiler user interface 185 may enable the user to use input device 190, such as a mouse or touch or pen input, to submit proposed optimizations for application 140. When profiler 150 determines that a proposed optimization maintains a validity of dependency graph 157, profiler user interface 185 may be updated to show the projected performance improvement from the proposed optimization, as well as a list of instructions for implementing the proposed optimization in application 140, as described further below in conjunction with FIGS. 2A-2C and FIG. 3. In this manner, the user can simply specify a desired end optimization state using profiler user interface 185, and a list of instructions can be received by the user to determine the effort required for implementation.) execute the graph task on the one or more PPUs based on the modified scheduling priority ([0034] In block 310, processor 120 determines that the proposed modification or optimization from block 308 is projected to improve a performance metric of GPU 170 while maintaining a validity of dependency graph 157. Example performance metrics may include reducing a total execution time of application 140 on GPU 170, including graphics queue 172 and asynchronous compute 174, or reducing a memory usage or memory footprint of application 140 on memory 176, or reducing a latency of API calls using graphics queue 172 or asynchronous compute 174. For the examples depicted in FIGS. 2B and 2C, the performance metric may correspond to reducing a total execution time of application 140 on GPU 170. If the proposed optimization reduces a performance metric of GPU 170, then the proposed optimization may be rejected, and the user may be instructed to try an alternative proposal.)”.
However, Purnomo may not explicitly teach the new limitations.
Shreve teaches “modify a scheduling priority of one or more graph tasks for a graph task of a graph executed on the one or more PPUs based on a combined scheduling priority value, wherein the combined scheduling priority value is based on a first priority value and a second priority value ([0030] Each path determines sets of tasks, called ‘supertasks’. A supertask defines a collection of subtasks, their order of execution, total power estimate, and priority. A supertask's power estimate and priority are the summed values taken from each subtasks' corresponding value. Next, to remove any repeat executions for subtasks that are shared between supertasks, supertasks with overlapping subtasks are merged by taking the union of the set of their subtasks. If necessary, priorities are summed for each shared subtask when updating the supertask priority value. As an option, the combination of supertasks with the highest priority that can run given a current power budget are selected using, for example, a knapsack algorithm.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Shreve with the teachings of Purnomo in order to provide a system that teaches details of priority. The motivation for applying Shreve teaching with Purnomo teaching is to provide a system that allows for design choice of improvements upon parallel scheduling. Purnomo, Shreve are analogous art directed towards graph processing. Together Purnomo, Shreve teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Shreve with the teachings of Purnomo by known methods and gained expected results.
Claim 4, the combination teaches the claim, wherein Shreve teaches “the one or more processors of claim 1, wherein the modified scheduling priority is based, at least in part, on one or more dependencies involving the graph task ([0030] Each path determines sets of tasks, called ‘supertasks’. A supertask defines a collection of subtasks, their order of execution, total power estimate, and priority. A supertask's power estimate and priority are the summed values taken from each subtasks' corresponding value. Next, to remove any repeat executions for subtasks that are shared between supertasks, supertasks with overlapping subtasks are merged by taking the union of the set of their subtasks. If necessary, priorities are summed for each shared subtask when updating the supertask priority value. As an option, the combination of supertasks with the highest priority that can run given a current power budget are selected using, for example, a knapsack algorithm.)”.
Claim 5, 10, the combination teaches the claim, wherein Purnomo teaches “the one or more processors of claim 1, the one or more circuits are further to receive one or more values associated with the graph task to modify the scheduling priority ([0021] After using profiler 150 to generate profile data 155, for example by executing a trace or profiling on application 140, the user may view profiler user interface 185 on display 180. Profiler user interface 185 may enable the user to use input device 190, such as a mouse or touch or pen input, to submit proposed optimizations for application 140. When profiler 150 determines that a proposed optimization maintains a validity of dependency graph 157, profiler user interface 185 may be updated to show the projected performance improvement from the proposed optimization, as well as a list of instructions for implementing the proposed optimization in application 140, as described further below in conjunction with FIGS. 2A-2C and FIG. 3. In this manner, the user can simply specify a desired end optimization state using profiler user interface 185, and a list of instructions can be received by the user to determine the effort required for implementation. Thus, several different optimization routes can be quickly evaluated before modifying code in application 140. Further, implementation of a proposed modification may be presented to the user via an easily understood step-by-step list of instructions, thereby facilitating implementation even when complex hardware is utilized, such as GPU 170.)”.
Claim/s 2, 3, 8, 14, 17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Purnomo, Shreve in further view of Wolfe
Claim 2, 8, 14 the combination may not explicitly teach details regarding the dependency graph.
Wolfe teaches “the graph comprises a first graph node, a second graph node representing the graph task, and a third graph node, wherein the second graph node and the third graph node depend on the first graph node; and the modified scheduling priority causes the second graph node to be scheduled before the third graph node ([0109] Returning to FIG. 4, once the memory has been allocated, in the illustrated embodiment, the method 400 continues to block 430, where the processing system modifies the ordering of the nodes in the topological ordering in order to increase parallel utilization of resources. In various embodiments, this can include, for example, moving load operations (e.g., moving data from storage to memory) to earlier positions in the ordering, rearranging nodes to allow for parallel execution on separate processing units, and the like. [0085] In an embodiment, the final topological ordering is created by reconnecting each subgraph, in the proper order, where the cuts were made (e.g., by adding or reconnecting the edges that were severed, while maintaining the linear sequence of nodes).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Wolfe with the teachings of Purnomo, Shreve in order to provide a system that teaches details of dependency. The motivation for applying Wolfe teaching with Purnomo teaching is to provide a system that allows for design choice of improvements upon parallel scheduling. Purnomo, Shreve, Wolfe are analogous art directed towards graph processing. Together Purnomo, Shreve, Wolfe teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Wolfe with the teachings of Purnomo, Shreve by known methods and gained expected results.
Claim 3, 19 the combination may not explicitly teach details regarding the dependency graph.
Wolfe teaches “the one or more processors of claim 1, wherein the one or more circuits are further to perform one or more application programming interfaces API calls are to change a value associated with a graph node of that represents the graph task ([0109] Returning to FIG. 4, once the memory has been allocated, in the illustrated embodiment, the method 400 continues to block 430, where the processing system modifies the ordering of the nodes in the topological ordering in order to increase parallel utilization of resources. In various embodiments, this can include, for example, moving load operations (e.g., moving data from storage to memory) to earlier positions in the ordering, rearranging nodes to allow for parallel execution on separate processing units, and the like.)”.
Rationale to claim 2 is applied here.
Claim 17, the combination may not explicitly teach the limitation.
Wolfe teaches “the method of claim 13, wherein modifying the priority further comprises modifying a value based, at least in part, on a first value that is associated with the one or more graph portions and a second value that is associated with a steam ([0077] In embodiments, the Ordering Component 110 also sets the weights of each original edge from the producer node to the consumers to zero. In the illustrated embodiment, this includes changing the weights of the edges from Node 210A to 210B (i.e. stream) and from Node 210A to 210C to zero. This is performed because if both edges retained their original weight, the data flowing on those edges would be “double counted” while computing minimum cuts, resulting in inaccuracies and inefficiencies in the final schedule.)”.
Rationale to claim 2 is applied here.
Claim/s 6, 9, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Purnomo, Shreve, in view of Barsness (Pat. No. US 9,971,633)
Claim 6, 18 the combination may not explicitly teach the limitations of the claim.
Barsness teaches “the one or more processors of claim 1, wherein the first priority value is assigned to a stream that includes the graph, and the second priority value is assigned to a graph node that represents the graph task ([Col. 14, Line 1 - 24] The operator graph 500 begins at a source 135 and ends at a sink 504, 506. Compute node 110A includes the processing elements PE1, PE2, and PE3. Source 135 flows into the processing element PE1, which in turn outputs tuples that are received by PE2 and PE3. For example, PE1 may split data attributes received in a tuple and pass some data attributes in a new tuple to PE2, while passing other data attributes in another new tuple to PE3. As a second example, PE1 may pass some received tuples to PE2 while passing other tuples to PE3. Tuples that flow to PE2 are processed by the stream operators contained in PE2, and the resulting tuples are then output to PE4 on compute node 110B Likewise, the tuples output by PE4 flow to operator sink PE6 504. Similarly, tuples flowing from PE3 to PE5 also reach the operators in sink PE6 504. Thus, in addition to being a sink for this example operator graph, PE6 could be configured to perform a join operation, combining tuples received from PE4 and PE5. This example operator graph also shows tuples flowing from PE3 to PE7 on compute node 110C, which itself shows tuples flowing to PE8 and looping back to PE7. Tuples output from PE8 flow to PE9 on compute node 110D, which in turn outputs tuples to be processed by operators in a sink processing element, for example PE10 506. ([Col. 24, Lines 5-23] (100) In embodiments, a structural match may occur at module 1015. A first structure of the first set of processing operations of the first application may be compared with a second structure of the second set of processing operations of the second application. Generally, comparing can include contrasting, analyzing, investigating, correlating, juxtaposing, or otherwise evaluating the first structure of the first set of processing operations of the first application with respect to the second structure of the second set of processing operations of the second application. The first and second structures may include characteristics, traits, or attributes that indicate the arrangement, composition, framework, make-up, format, syntax, design, or infrastructure of the first and second sets of processing operations, respectively. As an example, the first and second structures may include the order or sequence in which particular tasks of the first and second sets of processing operations are performed.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Barsness with the teachings of Purnomo, Shreve in order to provide a system that teaches combining values. The motivation for applying Barsness teaching with Purnomo, Shreve teaching is to provide a system that allows for computation of information carried out during graph processing. Purnomo, Shreve, Barsness are analogous art directed towards graph processing. Together Purnomo, Shreve, Barsness teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Barsness with the teachings of Purnomo, Shreve by known methods and gained expected results.
Claim 9, the combination teaches the claim, wherein Shreve teaches “the system of claim 7, wherein the combined scheduling priority value is based on a difference between the first priority value assigned to a stream that includes the graph and the second priority value assigned to a graph node that represents the graph task ([0030] Each path determines sets of tasks, called ‘supertasks’. A supertask defines a collection of subtasks, their order of execution, total power estimate, and priority. A supertask's power estimate and priority are the summed values taken from each subtasks' corresponding value. Next, to remove any repeat executions for subtasks that are shared between supertasks, supertasks with overlapping subtasks are merged by taking the union of the set of their subtasks. If necessary, priorities are summed for each shared subtask when updating the supertask priority value. As an option, the combination of supertasks with the highest priority that can run given a current power budget are selected using, for example, a knapsack algorithm.)”.
Rationale to claim 8 is applied here.
Claim/s 11, 12, 15, 16, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Purnomo, Shreve, Wolfe in view of Ogrinz (Pub. No. US 2015/0287124)
Claim 11, the combination may not explicitly teach the limitation.
Wolfe teaches “the system of claim 7, wherein the one or more PPUs are further to modify a value in response to one or more API calls ([0109] Returning to FIG. 4, once the memory has been allocated, in the illustrated embodiment, the method 400 continues to block 430, where the processing system modifies the ordering of the nodes in the topological ordering in order to increase parallel utilization of resources. In various embodiments, this can include, for example, moving load operations (e.g., moving data from storage to memory) to earlier positions in the ordering, rearranging nodes to allow for parallel execution on separate processing units, and the like. Examiner notes APIs may be used to change ordering as evidence by Ogrinz [0048] “The APIs are required to perform certain functions such as crawling of the catalog, ordering items”. Therefore, it would be obvious to one ordinarily skilled in the art, an API may make the requested changes of Purnomo, Wolfe)”.
Rationale to claim 2 is applied here.
Claim 12, 15, 16, the combination may not explicitly teach the limitation.
Wolfe teaches “the system of claim 7, wherein the one or more PPUs are further to perform one or more API calls to indicate the modification of the scheduling priority ([0109] Returning to FIG. 4, once the memory has been allocated, in the illustrated embodiment, the method 400 continues to block 430, where the processing system modifies the ordering of the nodes in the topological ordering in order to increase parallel utilization of resources. In various embodiments, this can include, for example, moving load operations (e.g., moving data from storage to memory) to earlier positions in the ordering, rearranging nodes to allow for parallel execution on separate processing units, and the like. Examiner notes APIs may be used to change ordering and as evidence by Ogrinz [0048] “The APIs are required to perform certain functions such as crawling of the catalog, ordering items”. Therefore, it would be obvious to one ordinarily skilled in the art, an API may make the requested changes of Purnomo, Wolfe)”.
Rationale to claim 2 is applied here.
Claim 20, the combination may not explicitly teach the limitation.
Wolfe teaches “the method of claim 13, The method of claim 13, wherein the modified scheduling priority is based, at least in part, on selecting, in response to one or more API calls, the second priority value assigned to a graph node that represents the graph task instead of the first priority value assigned to a stream that includes the graph ([0109] Returning to FIG. 4, once the memory has been allocated, in the illustrated embodiment, the method 400 continues to block 430, where the processing system modifies the ordering of the nodes in the topological ordering in order to increase parallel utilization of resources. In various embodiments, this can include, for example, moving load operations (e.g., moving data from storage to memory) to earlier positions in the ordering, rearranging nodes to allow for parallel execution on separate processing units, and the like. Examiner notes APIs may be used to change ordering and as evidence by Ogrinz [0048] “The APIs are required to perform certain functions such as crawling of the catalog, ordering items”. Therefore it would be obvious to one ordinarily skilled in the art, an API may make the requested changes of Purnomo, Wolfe)”.
Rationale to claim 2 is applied here.
Claim/s 21-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Purnomo, Shreve, in further view of Ravala (Pub. No. US 2022/0070245).
Claims 21, 22, 23 the combination teaches the claim, wherein Purnomo teaches “the processors of claim 1, wherein the one or more APIs (i.e. GUI interface) calls are capable of causing one or more captured streams (i.e. streamed commands as evidenced below) to modify the scheduling priority of the graph task ([0033] In block 308, processor 120 receives, via profile user interface 185, an input from input device 190 for a modification of one or more execution attributes of one or more target tasks of tasks 210A-210D. For example, the input may correspond to a click and drag movement of one or more target tasks to a desired position in the histogram. Referring to FIG. 2B, one example input may correspond to a click and drag operation that moves task 210C from the upper “Graphics” region representing graphics queue 172 to the lower “Asynchronous Compute” region representing asynchronous compute 174. Referring to FIG. 2C, another example input may correspond to a click and drag operation that moves task 210C leftward such that task 210C starts at a beginning time of 2 milliseconds instead of the original beginning time of 4 milliseconds.)”.
However, the combination may not explicitly teach the captured commands of the interface are streamed.
Ravala teaches as evidence, commands of an interface are streamed ([0052] In some embodiments, computing device 85 of the user may include a processor 90, a memory 87, input and/or output (I/O) devices 88, and communication circuitry 86 for communicating 95 with TDI 15 and/or RDI 60 over a communication network. For example, I/O devices 88 may include a keyboard 98, a mouse 99, and a display 97. A graphic user interface (GUI) 96 may be displayed on display 97. Computing device 85 may be used to communicate 95 data stream commands and/or provisioning requests to TDI 15 and/or RDI 60. The commands and/or requests between computing device 85 and TDI 15 and/or RDI 60 may be entered by the user on GUI 96.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ravala with the teachings of Purnomo, Shreve in order to provide a system that teaches streams. The motivation for applying Ravala teaching with Purnomo, Shreve teaching is to provide evidence commands captured of Purnomo are stream based for the purposes of design choice. Purnomo, Shreve, Ravala are analogous art directed towards command processing. Together Purnomo, Shreve, Ravala teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Ravala with the teachings of Purnomo, Shreve by known methods and gained expected results.
Claim 24, 25, the combination taches the claim, wherein Shreve teaches “the one or more processors of claim 1, wherein one or more runtime API calls modify the scheduling priority with respect to one or more dependencies involving the graph task, and one or more captured streams (i.e. as taught by Ravala) further modify the scheduling priority with respect to one or more other dependencies involving the graph task ([0030] Each path determines sets of tasks, called ‘supertasks’. A supertask defines a collection of subtasks, their order of execution, total power estimate, and priority. A supertask's power estimate and priority are the summed values taken from each subtasks' corresponding value. Next, to remove any repeat executions for subtasks that are shared between supertasks, supertasks with overlapping subtasks are merged by taking the union of the set of their subtasks. If necessary, priorities are summed for each shared subtask when updating the supertask priority value. As an option, the combination of supertasks with the highest priority that can run given a current power budget are selected using, for example, a knapsack algorithm.)”.
Rationale to claim 1 is applied here.
Claim 26, the combination taches the claim, wherein Shreve teaches “the method of claim 13, wherein modifying the scheduling priority comprises modifying the scheduling priority, via one or more runtime API calls, with respect to one or more dependencies involving the graph task, and further modifying the scheduling priority, via one or more captured streams, with respect to one or more other dependencies involving the graph task ([0030] Each path determines sets of tasks, called ‘supertasks’. A supertask defines a collection of subtasks, their order of execution, total power estimate, and priority. A supertask's power estimate and priority are the summed values taken from each subtasks' corresponding value. Next, to remove any repeat executions for subtasks that are shared between supertasks, supertasks with overlapping subtasks are merged by taking the union of the set of their subtasks. If necessary, priorities are summed for each shared subtask when updating the supertask priority value. As an option, the combination of supertasks with the highest priority that can run given a current power budget are selected using, for example, a knapsack algorithm. Examiner notes (Ravala teaches as evidence, commands of an interface (i.e. Purnomo) are streamed [0052] In some embodiments, computing device 85 of the user may include a processor 90, a memory 87, input and/or output (I/O) devices 88, and communication circuitry 86 for communicating 95 with TDI 15 and/or RDI 60 over a communication network. For example, I/O devices 88 may include a keyboard 98, a mouse 99, and a display 97. A graphic user interface (GUI) 96 may be displayed on display 97. Computing device 85 may be used to communicate 95 data stream commands and/or provisioning requests to TDI 15 and/or RDI 60. The commands and/or requests between computing device 85 and TDI 15 and/or RDI 60 may be entered by the user on GUI 96.)”.
Rationale to claim 1 is applied here.
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 WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199
