CTFR 16/731,906 CTFR 79455 DETAILED ACTION 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claims 1-14 and 16-21 are presented for examination. This office action is in response to the Claims/Remarks on 1/29/26. All references in this office action were cited in a previous PTO-892. Applicant’s arguments have been fully considered but are moot in view of the new grounds of rejections. Claim Rejections - 35 USC § 112 07-30-01 AIA The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. 07-31-01 Claim 10 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre- AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. As to claim 10, the specification does not reasonably convey to one of ordinary skill in the art that the inventor had possession of modifying an executable version of a task graph “without modifying nodes of the task graph.” As to claim 14, the specification does not describe the claimed invention “wherein the one or more parameters of the node are task-dependent.” The specification does not use the term “task-dependent,” nor does it describe parameters as depending on a task or task type. Thus, the originally filed disclosure does not reasonably convey possession of the claimed “task-dependent parameters.” Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-4, 9-12, 14, 17, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Schildan et al. (hereinafter Schildan) (US 8,549,529 B1) in view of Bach (US 2021/0216290 A1) . As to claim 1, Schildan teaches a non-transitory computer readable medium (removable storage 608 and/or non-removable storage 610) storing instructions that, when executed by one or more processors (Processing Unit 602 contains Central Processing Unit 604, Graphics Processing Unit 606, etc.) , cause the one or more processors to execute at least one application programming interface (API) call (CUDA/OpenCL/FILTERGRAPH API used to generate execution graph) and modifying (resource configuration can be modified after execution graph is generated/instantiated) an executable version of a task graph (execution graph 206, 212, 220, or 224, which are derived from input graph 100) after the executable version of the task graph has been instantiated (instance of an execution graph are generated by the selector 304 and/or the inserting module 306) for execution without generating (the execution graph may be modified further by a resource based on one or more parameters or attributes of the media input provided by the user) a new executable version of the task graph (an executable version of the execution graph is generated) (col. 1, lines 51-67; col. 3, lines 10-30; col. 6, lines 17-23 and 55-64; col. 7, lines 57-65; Figs. 1, 2A, 6) . Schildan implies modifying an executable version of a task graph after the execution version of the task graph has been instantiated. For example, Fig. 2A illustrates execution graph 206 has both functions 208 and 210 in the CPU, while execution graph 212 splits them across CPU and GPU – this indicates modification of node parameters or structure after instantiation, such as changing resource assignments. Also, Schildan discloses that “the execution graph may be modified further by a resource based on one or more parameters or attributes of the media input provided by the user” (col. 6, lines 61-64) . The phrase “modified further” strongly implies that the execution graph already exists or has been instantiated and that an additional modification is being performed after instantiation. While Schildan teaches implicit support for modification of the executable version of the task graph after it is instantiated, Bach is cited to confirm, reinforce, and make explicit the understanding that executable graphs can be modified after instantiation via specification-based differences and parameter updates. Bach teaches a graph updating system 300 that takes a base executable graph 302, which is an already instantiated/generated graph that is executable, as well as source 304 and target 306 graphs, which are modified versions of that executable graph. The updated graph 350 (generated by updating engine 330) incorporates modifications from those existing executable versions. Therefore, this teaches that parameter updates (modified parameter set 405) and structural changes are applied to graphs that have already been generated/instantiated (Title; Abstract; [0005]; [0053]-[0056]; [0065]-[0066]; [0082]-[0083]; [0090]-[0093]; Fig. 3) . It would have been obvious to one of ordinary skill in the art before the effective date of the application to incorporate Bach’s explicit parameter update mechanism into Schildan’s execution graph system. The suggestion/motivation for doing so would have been to provide the predicted result of being able to modify graphs after instantiation to resolve parameters and keeping the graphs updated during runtime and for an improved version management that is more efficient/reliable/automated (Bach: [0055]; [0043]) . As to claim 2, Schildan (change/modify one or more parameters 108; CUDA/OpenCL/FILTERGRAPH API) (col. 1, lines 51-67; col. 3, lines 13-15; col. 5, lines 63-67) in view of Bach ([0055]; [0065]-[0066]; [0090]; Fig. 3) teaches wherein the at least one API call, when executed, modifies one or more parameters of a node included in the executable version of the task graph. As to claim 3, Schildan teaches wherein the node corresponds to a task to be performed by a computing resource when the executable version of the task graph is launched (col. 4, lines 27-41) . As to claim 4, Schildan teaches wherein the task comprises a kernel task, a host task, a memory set task, or a memory copy task (col. 2, lines 23-24) . As to claim 9, Schildan (different workload from instances directed to different resources (CPU, GPU), sometimes inserting conversion functions; change/modify one or more parameters 108; CUDA/OpenCL/FILTERGRAPH API) (col. 1, lines 51-67; col. 3, lines 13-15; col. 5, lines 63-67; Fig. 2A) in view of Bach ([0055]; [0090]-[0091]; [0082]; Fig. 3) teaches wherein the instructions, when executed by the one or more processors, further cause the one or more processors to execute at least one additional API call to launch a modified executable version of the task graph that configures one or more computing resources to perform a second workload that is different than a first workload performed by the executable version of the task graph prior to being modified. As to claim 10, Schildan teaches a computer-implemented method comprising calling an application programming interface (API) (CUDA/OpenCL/FILTERGRAPH API used to generate execution graph) to modify (resource configuration can be modified after execution graph is generated/instantiated) an executable version of a task graph (execution graph 206, 212, 220, or 224, which are derived from input graph 100) after the executable version of the task graph has been instantiated for execution without modifying nodes of the task graph (modification of parameters or attributes instead of nodes) (an executable version of the execution graph is generated) (col. 1, lines 51-67; col. 3, lines 10-30; col. 6, lines 17-23; col. 7, lines 57-65; Figs. 1, 2A, 6) . Schildan implies modifying an executable version of a task graph after the execution version of the task graph has been instantiated. For example, Fig. 2A illustrates execution graph 206 has both functions 208 and 210 in the CPU, while execution graph 212 splits them across CPU and GPU – this indicates modification of node parameters or structure after instantiation, such as changing resource assignments. Also, Schildan discloses that “the execution graph may be modified further by a resource based on one or more parameters or attributes of the media input provided by the user” (col. 6, lines 61-64) . The phrase “modified further” strongly implies that the execution graph already exists or has been instantiated and that an additional modification is being performed after instantiation. Thus, the modification is based on parameters or attributes , not by changes of the functions/nodes of the graph. While Schildan teaches implicit support for modification of the executable version of the task graph after it is instantiated, Bach is cited to confirm, reinforce, and make explicit the understanding that executable graphs can be modified after instantiation via specification-based differences and parameter updates. Bach teaches a graph updating system 300 that takes a base executable graph 302, which is an already instantiated/generated graph that is executable, as well as source 304 and target 306 graphs, which are modified versions of that executable graph. The updated graph 350 (generated by updating engine 330) incorporates modifications from those existing executable versions. Therefore, this teaches that parameter updates and structural changes are applied to graphs that have already been generated/instantiated (Title; Abstract; [0005]; [0053]-[0056]; [0065]-[0066]; [0082]-[0083]; [0090]; Fig. 3) . It would have been obvious to one of ordinary skill in the art before the effective date of the application to incorporate Bach’s explicit parameter update mechanism into Schildan’s execution graph system. The suggestion/motivation for doing so would have been to provide the predicted result of being able to modify graphs after instantiation to resolve parameters and keeping the graphs updated during runtime and for an improved version management that is more efficient/reliable/automated (Bach: [0055]; [0043]) . As to claim 11, it is rejected for the same reasons as stated in the rejection of claim 2. As to claim 12, it is rejected for the same reasons as stated in the rejection of claim 3. As to claim 14, Schildan teaches a computer-implemented method to call an application programming interface (API) to modify an executable graph (Abstract; Figs 1, 2A, and 6) , the method comprising: generating the executable graph from a task graph, wherein the executable graph configures one or more computing resources to perform a first workload (instance of an execution graph are generated by the selector 304 and/or the inserting module 306) (Abstract; Fig. 2A, 3) ; and modifying (resource configuration can be modified after execution graph is generated/instantiated) , by the API (CUDA/OpenCL/FILTERGRAPH API) , one or more parameters (Parameters 108) of a node included in the executable graph (one or more nodes in graph 200) to generate a modified executable graph (execution graph 200 after it is updated or adjusted based on input parameters) , after the executable graph has been instantiated (instance of an execution graph are generated by the selector 304 and/or the inserting module 306) for execution (an executable version of the execution graph is generated) , wherein the one or more parameters of the node are task-dependent (parameters 108 may be the same or different for each of the functions 104 and 106, wherein parameters may correspond to particular functions; therefore, different functions in an input graph may have different parameters) (col. 1, lines 51-67; col. 3, lines 10-30 and 47-49; col. 4, lines 7-19; col. 6, lines 17-23; col. 7, lines 57-65; Figs. 1, 2A, 6) ; wherein the modified executable graph configures the one or more computing resources to perform a second workload that is different than the first workload (first and second workloads can be different such as applying different data processing filters and effects based on the input parameters) (Abstract; Fig. 2A) . Schildan implies modifying an executable version of a task graph after the execution version of the task graph has been instantiated. For example, Fig. 2A illustrates execution graph 206 has both functions 208 and 210 in the CPU, while execution graph 212 splits them across CPU and GPU – this indicates modification of node parameters or structure after instantiation, such as changing resource assignments. Also, Schildan discloses that “the execution graph may be modified further by a resource based on one or more parameters or attributes of the media input provided by the user” (col. 6, lines 61-64) . The phrase “modified further” strongly implies that the execution graph already exists or has been instantiated and that an additional modification is being performed after instantiation. While Schildan teaches implicit support for modification of the executable version of the task graph after it is instantiated, Bach is cited to confirm, reinforce, and make explicit the understanding that executable graphs can be modified after instantiation via specification-based differences and parameter updates. Bach teaches a graph updating system 300 that takes a base executable graph 302, which is an already instantiated/generated graph that is executable, as well as source 304 and target 306 graphs, which are modified versions of that executable graph. The updated graph 350 (generated by updating engine 330) incorporates modifications from those existing executable versions. Therefore, this teaches that parameter updates and structural changes are applied to graphs that have already been generated/instantiated (Title; Abstract; [0005]; [0053]-[0056]; [0065]-[0066]; [0082]-[0083]; [0090]; Fig. 3) . It would have been obvious to one of ordinary skill in the art before the effective date of the application to incorporate Bach’s explicit parameter update mechanism into Schildan’s execution graph system. The suggestion/motivation for doing so would have been to provide the predicted result of being able to modify graphs after instantiation to resolve parameters and keeping the graphs updated during runtime and for an improved version management that is more efficient/reliable/automated (Bach: [0055]; [0043]) . As to claim 16, Schildan teaches wherein the executable graph is an executable Compute Unified Device Architecture (CUDA) graph or an executable Heterogeneous compute Interface for Portability (HIP) graph (CUDA) (col. 1, lines 51-67; col. 5, lines 25-33) . 07-21-aia AIA Claim s 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Schildan in view of Bach, and further in view of Lee et al. (hereinafter Lee) (US 2020/0257672 A1) . As to claim 5, Schildan in view of Bach does not teach that when its task comprises a host task, the one or more parameters include at least one of a pointer to a callback function on a central processing unit or an argument of the callback function. However, Lee teaches using reference 924 such as a pointer to callbacks 930 that are associated with a statement or operation ([0119]). It would have been obvious to one of ordinary skill in the art before the effective date of the application to modify Schildan in view of Bach such that it would include the teachings of Lee , namely, the one or more parameters include at least one of a pointer to a callback function on a central processing unit or an argument of the callback function, as taught and suggested in Lee . The suggestion/motivation for doing so would have been to provide the predicted result of having the ability to rollback or abort a transaction, without committing the statements ( Lee - [0002]). As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 5 . 07-21-aia AIA Claim s 6-7, 18-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Schildan in view of Bach, and further in view of Bates et al. (hereinafter Bates) (US 2007/0074207 A1) . As to claim 6, Schildan in view of Bach does not explicitly teach wherein, when the task comprises a memory set task, the one or more parameters include at least one of a location of a block of memory to set, a size of the block of memory, or a fill value of the block of memory. However, Bates teaches task parameters that include: I/O addresses, I/O sizes, addresses for input and output task data ([0038]) . In addition, the SpuTaskContext* points to memory with task definition and includes info for DMA transfer setup, which describes a set or fill operation ([0051]) . It would have been obvious to one of ordinary skill in the art before the effective date of the application to modify Schildan in view of Bach such that wherein, when the task comprises a memory set task, the one or more parameters include at least one of a location of a block of memory to set, a size of the block of memory, or a fill value of the block of memory, as taught and suggested in Bates . The suggestion/motivation for doing so would have been to provide the predicted result of improving performance and scaling to implement task management more efficiently with low PPU usage, low memory usage and low DMA bandwidth usage (Bates: [0031]) . As to claim 7, Schildan in view of Bach does not explicitly teach teaches wherein, when the task comprises a memory copy task, the one or more parameters include at least one of a location of a block of source memory, a location of a destination where contents of the source memory are to be copied, or a size of the block of source memory. However, Bates teaches a MEM copy program…using an available SPU to transfer from one location in the main memory 106 to another location ([0047]) . In addition, Bates teaches I/O addresses, I/O sizes, addresses for input and output task data ([0038]) . It would have been obvious to one of ordinary skill in the art before the effective date of the application to modify Schildan in view of Bach such that wherein, when the task comprises a memory copy task, the one or more parameters include at least one of a location of a block of source memory, a location of a destination where contents of the source memory are to be copied, or a size of the block of source memory, as taught and suggested in Bates . The suggestion/motivation for doing so would have been to provide the predicted result of improving performance and scaling to implement task management more efficiently with low PPU usage, low memory usage and low DMA bandwidth usage (Bates: [0031]) . As to claim 18, it is rejected for the same reasons as stated in the rejection of claim 6. As to claim 19, it is rejected for the same reasons as stated in the rejection of claim 7. As to claim 21, Schildan suggest the computer-implemented method of claim 12, wherein the one or more parameters correspond to different parameters based, at least in part, on a type of task by teaching that parameters 108 may be the same or different for each of the functions 104 and 106, wherein parameters may correspond to particular functions. Therefore, different functions in an input graph may have different parameters (col. 1, lines 51-67; col. 3, lines 10-30 and 47-49; col. 4, lines 7-19). However, Bates more explicitly teaches this limitation by disclosing its task definition/parameters, which includes both a Task Type field and Task Parameters field ([0038]-[0040]) . It would have been obvious to one of ordinary skill in the art before the effective date of the application to include Bates’s teaching as mentioned above to Schildan in view of Bach’s task execution system/method because it would be desirable to provide resources to many task classes and do so efficiently with its resources (Bates - [0014]-[0015]) . 07-21-aia AIA Claim s 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Schildan in view of Bach, and further in view of Koneru et al. (hereinafter Koneru) (US 2021/0406069 A1) . As to claim 8, Schildan in view of Bach does not teach wherein, when the task comprises a kernel task, the one or more parameters include at least one of a number of threads or one or more arguments for the kernel task. However, Koneru teaches graph processing with a directed acyclic graph and having a kernel task with one or more parameters including a number of threads “T” and/or arguments (Abstract; [0135]; [0297]; [0306]; [0308]). It would have been obvious to one of ordinary skill in the art before the effective date of the invention to modify Schildan in view of Bach such that it would have a kernel task with one or more parameters include at least one of a number of threads or one or more arguments for the kernel task, as taught and suggested in Koneru . The suggestion/motivation for doing so would have been to provide the predicted result of utilizing threads to achieve fine grained scheduling and processing ( Koneru - [0115]). As to claim 20, it is rejected for the same reasons as stated in the rejection of claim 8 . Response to Arguments Applicant’s arguments were fully considered but are moot in view of the new grounds of rejections. Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim 13 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Conclusion 07-40 AIA 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 KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM. 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, Bradley Teets can be reached at 571-272-3338. 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. /KENNETH TANG/Primary Examiner, Art Unit 2197 Application/Control Number: 16/731,906 Page 2 Art Unit: 2197 Application/Control Number: 16/731,906 Page 3 Art Unit: 2197 Application/Control Number: 16/731,906 Page 5 Art Unit: 2197 Application/Control Number: 16/731,906 Page 6 Art Unit: 2197 Application/Control Number: 16/731,906 Page 7 Art Unit: 2197 Application/Control Number: 16/731,906 Page 8 Art Unit: 2197 Application/Control Number: 16/731,906 Page 9 Art Unit: 2197 Application/Control Number: 16/731,906 Page 12 Art Unit: 2197 Application/Control Number: 16/731,906 Page 13 Art Unit: 2197
Prosecution Insights