DETAILED ACTION
Remarks
Applicant presents a request for continued examination dated 15 September 2026 responsive to the 3 June 2026 final Office action (the “Previous Action”).
Claims 1-22 are amended. Claim 23 is cancelled. New claim 25 is added.
Claim 1-22 and 24-25 are pending. Claims 1, 8 and 15 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 15 September 2026 has been entered.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Applicant’s arguments are moot in view of the new ground(s) of rejection below, necessitated by Applicant’s amendments.
Claim Rejections - 35 USC § 112
The Previous Action’s § 112 rejections are withdrawn in view of Applicant’s claim amendments.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-22 and 25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
As to claim 1, the claim recites the following:
one or more processors, comprising:
circuitry to:
identify, by traversing a computational graph from a result node towards one or more input nodes two or more operations of the computational graph whose corresponding results have not been computed;
combine, the identified two or more operations;
generate one or more processor-executable kernels based on at least on the combined two or more of the identified operations and
cause the one or more processor-executable kernels to be performed.
Under the broadest reasonable interpretation in light of the specification the above underlined elements recite a mental process because all of the above steps are performable by the human mind with aid of pen and paper. Note that the human mind with aid of pen and paper is capable of analyzing each node of a graph starting at a result node towards input nodes (i.e., traversing the graph) and that kernels only appear to be groups of operations. (See The specification at par. [0060]).
None of the additional elements integrate the judicial exception into a practical application. References to “one or more processors” and “circuitry” amount to nothing more than implementing the abstract idea on a generic computer. Reference to causing the processor-executable kernels to be performed, amounts to a mere recitation of the words “apply it.” See M.P.E.P. § 2106.05(f).
Looking at the claim limitations as an ordered combination yields the same conclusion as that reached when looking at the elements individually. Their collective function is merely to implement the abstract idea on a generic computing device and “apply it.”
The claim does not include additional elements that amount to significantly more than the judicial exception either, for the substantially the same reasons discussed above with respect to a practical application.
As to claim 2, the features of this claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because the human mind with air of pen and paper is capable of partitioning the graph and the “to limit compilation times” is merely intended use. The claim does not actually require compiling anything.
As to claim 3-6, the features of these claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because they only further describe the abstract idea itself.
As to claim 7, the features of this claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because storing the results as claimed is merely extra-solution data outputting and because storing information in memory is recognized by courts as well-understood, routine and conventional activity. See M.P.E.P. § 2106.05(d).
As to claim 8, the claim is directed to a judicial exception without significantly more substantially the same reasons as claim 1. The addition of memory to store instructions that, if executed by one or more processors causes the system to perform the recited operations amounts to nothing more than implementing the abstract idea on a generic computer. See M.P.E.P. § 2106.05(f).
As to claim 9-11, the features of these claims do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more for reasons substantially the same as those set forth above with respect to claims 2-4.
As to claim 12-13, the features of these claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because they only further describe the abstract idea itself.
As to claim 14, the features of this claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because storing the results as claimed is merely extra-solution data outputting and because storing information in memory is recognized by courts as well-understood, routine and conventional activity. See M.P.E.P. § 2106.05(d).
As to claim 15, the claim is directed to a judicial exception without significantly more substantially the same reasons as claim 1.
As to claim 16-19, 21-22 and 25, the features of these claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because they only further describe the abstract idea itself.
As to claim 20, the features of this claim do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because storing the results as claimed is merely extra-solution data outputting and because storing information in memory is recognized by courts as well-understood, routine and conventional activity. See M.P.E.P. § 2106.05(d).
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 1, 3-8, 10-22 and 25 are rejected under 35 U.S.C. 103 as unpatentable over McGuire (US 2007/0294663) (art of record – hereinafter McGuire) in view of Bendersky et al. (US 9,798,527) (art of record – hereinafter Bendersky).
As to claim 1, McGuire discloses one or more processors, comprising:
circuitry (e.g., McGuire, Fig. 1 and associated text, par. [0033]: there are multiple components within runtime system 10, and they all run on the main CPU 960) to:
identify, by traversing a computational graph, two or more operations of the computational graph whose corresponding results have not been computed; (e.g., McGuire, par. [0318]: ProgGen 600 traverses the operation dependence graph in order to find operations eligible for fusion. Operations are eligible to be fused into the compute kernel currently being formed once all their inputs are guaranteed to have been previously computed by this compute kernel or a previously generated one; par. [0320]: ProgGen maintains two lists of operations, the non-fusible ready list [operations whose corresponding results have not been computed] and the fusible ready list)
combine, the identified two or more operations; and (e.g., McGuire, par. [0317]: the selection of operations to fuse together) and
generate one or more processor-executable kernels based on at least on the combined two or more of the identified operations (e.g., McGuire, par. [0317]: operations to fuse together into a computer kernel; par. [0028]: kernels execute on the processing elements) and
cause the one or more processor-executable kernels to be performed (e.g., McGuire, par. [0035]: the runtime system 10 is configured to execute compute kernels).
McGuire does not explicitly disclose traversing a computational graph from a result node towards one or more input nodes.
However, in an analogous art, Bendersky discloses:
traversing a computational graph from a result node towards one or more input nodes (e.g., Bendersky, col. 7 l. 66 – col. 8 l. 1: Fig. 4 and associated text, the compilation constructs this fused representation by traversing all paths in the graph from A 410 up to the inputs, B 401a and C 401b).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the traversal of McGuire such that it is backwards (i.e., from a result node towards one or more input nodes), as taught by Bendersky. McGuire suggests the combination because McGuire discloses traversing the graph without limiting that traversal to any particular direction. It would also have been obvious to try and modify the traversal of McGuire such that it is performed in the backwards direction because as shown by Aman et al. (US 9,184,980), traversal of a graph can be successfully performed in either a forwards or backwards direction. See M.P.E.P. § 2143(I)(E).
As to claim 3, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above), Meixner further discloses:
wherein the one or more processor-executable kernels are to include operations capable of being performed together (e.g., McGuire, par. [0272]: ProgGen 600 must determine which operations may be executed together as part of the same compute kernel).
As to claim 4, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above) Meixner further discloses:
wherein the one or more processor-executable kernels are generated as one or more processor-executable kernels, (e.g., McGuire, par. [0028]: kernels execute on the processing elements) where the one or more processor-executable kernels are to include operations capable of being performed on different processing architectures (e.g., McGuire, par. [0272]: operations may be executed together as part of the same compute kernel; par. [0060]: the system prepares compute kernels for different types of processing elements; par. [0011]: processing elements may or may not have the same processor architecture; par. [0530]: the system may compile one or more compute kernels; par. [0047]: The ProgGen 600 generates multiple copies of compiled programs, one for each type of processing element of the parallel-processing computer system for executing the compiled programs).
As to claim 5, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above), McGuire further discloses:
wherein the circuitry is further to identify the two or more operations based, at least in part, at least on traversing the graph until a first object is reached that is to be materialized as an input of a second object (e.g., McGuire, par. [0044]: each IR node [object] representing an operation to be performed by the system; par. [0318]: in some embodiments a simpler algorithm is used to assign operations to kernels. In such a scheme, the ProgGen 600 essentially traverses the operation dependence graph in order to find operations eligible for fusion. Operations [objects] are eligible to be fused into the kernel currently being formed once all their inputs are guaranteed to have been previous computed [materialized] by this compute kernel or a previously generated one; par. [0045]: a map operation takes one or more arrays as input [i.e., inputs include data structures as well]).
As to claim 6, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above), Meixner further discloses:
wherein the one or more processor-executable kernels are further to include a first and a second processor-executable kernel, the second processor-executable processor kernel to be dependent on the first processor-executable kernel (e.g., McGuire, Fig. 7B and associated text, par. [00370]: the program sequence 712 includes three programs “(or computer kernels)” A, B and C. Program A has one temporary output T_0. Program B has another temporary output T_1. Program C has the two temporary outputs T_0, T_1 as its input [so C is dependent on A and B]; par. [0374]: because the two inputs T_0, T_1 to the program C are both ready, the E-Scheduler 800 can submit the program C to the executor for execution).
As to claim 7, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above), Meixner further discloses:
wherein the circuitry is further to store one or more results of one or more first operations performed on the one or more processor-executable kernel to be input into one or more second operations(e.g., McGuire, par. [0044]: each IR node representing an operation. These IR nodes are used by the runtime system (e.g., the program generator 600) to generate computer kernels; par. [0061]: the ProgGen 600 determines which set of IR nodes should correspond to a computer kernel and attempts to merge operations into the compute kernel; par. [0118]: memory space for data arrays is allocated when it is needed to store an operation result; par. [0275]: where one operation produces the input of another, the second operation may consume the results of the first).
As to claim 8, it is a system claim having limitations substantially similar to those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by McGuire, include:
a system, comprising memory to store executable instructions that, if executed by one or more processors, (e.g., McGuire, Fig. 1 and associated text, par. [0033]: there are multiple components within runtime system 10, and they all run on the main CPU 960 [running software requires storing it in memory]) cause the system to: (see rejection of claim 1 above).
As to claim 10, it is a system claim having limitations substantially similar to those of claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 11, it is a system claim having limitations substantially similar to those of claim 4. Accordingly, it is rejected for substantially the same reasons.
As to claim 12, McGuire/Bendersky discloses the system of claim 8 (see rejection of claim 8 above) McGuire further discloses:
wherein the memory stores further executable instructions that, if executed by the one or more processors, cause the system to identify the two or more operations based, at least on traversing the graph until a first data structure is reached that is to be materialized as an input of a second data structure (e.g., McGuire, par. [0044]: each IR node [object] representing an operation to be performed by the system; par. [0318]:in some embodiments a simpler algorithm is used to assign operations to kernels. In such a scheme, the ProgGen 600 essentially traverses the operation dependence graph in order to find operations eligible for fusion. Operations are eligible to be fused into the kernel currently being formed once all their inputs are guaranteed to have been previously computed [materialized] by this compute kernel or a previously generated one; par. [0045]: a map operation takes one or more arrays as input [i.e., inputs include data structures as well]; par. [0044]: each IR node representing an operation to be performed by the system; par. [0140]: “Data” node identifies an input to a particular parse node).
As to claim 13, McGuire/Bendersky discloses the system of claim 8 (see rejection of claim 8 above), McGuire further discloses:
wherein the one or more processor-executable kernels are further to include a first and a second processor-executable kernel, the second processor-executable processor kernel to be dependent on an output of the first processor-executable kernel (e.g., Meixner, par. [0037]: one or more “consumer” kernels that represent the next stage/operation in the pipeline/DAG. In this manner, a “producer” kernel has its output data forwarded to a “consumer” kernel).
As to claim 14, McGuire/Bendersky discloses the system of claim 8 (see rejection of claim 8 above), McGuire further discloses:
further comprising a register, (see immediately below)
wherein the memory stores further executable instructions that, if executed by the one or more processors, cause the system to store, in the register, one or more results of one or more first operations performed on the one or more processor-executable kernels to be input into one or more second operations (e.g., McGuire, par. [0044]: each IR node representing an operation. These IR nodes are used by the runtime system (e.g., the program generator 600) to generate computer kernels; par. [0061]: the ProgGen 600 determines which set of IR nodes should correspond to a computer kernel and attempts to merge operations into the compute kernel [an operation in a kernel being “on” the kernel]; par. [0272]: the result(s) of one fused operation may be passed directly to a consuming operation using the most efficient means possible on the target architecture “(e.g., using registers)” [i.e., storing the results in those registers]).
As to claim 15, it is a method claim having limitations substantially similar to those of claim 1. Accordingly, it is rejected for substantially the same reasons.
As to claim 16, McGuire/Bendersky discloses the method of claim 15 (see rejection of claim 15 above), McGuire further discloses:
wherein the one or more processor-executable kernels include sequential phases of operations, the sequential phases of operations represented one or more instances across the graph of by the two or more operations (e.g., McGuire, par. [0044]: each IR node representing an operation. These IR nodes are used by the runtime system (e.g., the program generator 600) to generate computer kernels; par. [0061]: the ProgGen 600 determines which set of IR nodes should correspond to a computer kernel and attempts to merge operations into the compute kernel; par. [0272]: results of a fused operation may be passed directly to a consuming operation; par. [0276]: for example, operations computing a scalar result could be fused with an operation that multiplies that scalar by a vector, thereby producing a vector).
As to claim 17, McGuire/Bendersky discloses the method of claim 15 (see rejection of claim 15 above), McGuire further discloses:
wherein the one or more processor-executable kernels include operations performed together in a single kernel launch (e.g., McGuire, par. [0272]: operations may be executed together as part of the same compute kernel).
As to claim 18, McGuire/Bendersky discloses the method of claim 15 (see rejection of claim 15 above), McGuire further discloses:
wherein the one or more processor-executable kernels corresponding to the graph perform operations for the graph executable on differently architecture processors, (e.g., McGuire, par. [0545]: a uniform intermediate representation (IR). The intermediate representation is represented as a directed acyclic graph (DAG); par. [0061]: the ProgGen 600 determines which set of IR nodes should correspond to a computer kernel and attempts to merge operations into the compute kernel; par. [0035]: a compute kernel is an executable program that runs on one or more processing elements; par. [0060]: the system prepares compute kernels for different types of processing elements; par. [0011]: processing elements that may or may not have the same processor architecture; par. [0011]: processing elements may or may not have the same processor architecture; par. [0530]: the system may compile one or more compute kernels; par. [0047]: The ProgGen 600 generates multiple copies of compiled programs, one for each type of processing element of the parallel-processing computer system for executing the compiled programs).
As to claim 19, McGuire/Bendersky discloses the method of claim 15 (see rejection of claim 15 above), McGuire further discloses:
wherein identifying the two or more operations comprises traversing the graph until a first data structure is reached that is materialized as an input of a second data structure, (e.g., McGuire, par. [0044]: each IR node [object] representing an operation to be performed by the system; par. [0318]: in some embodiments a simpler algorithm is used to assign operations to kernels. In such a scheme, the ProgGen 600 essentially traverses the operation dependence graph in order to find operations eligible for fusion. Operations [objects] are eligible to be fused into the kernel currently being formed once all their inputs are guaranteed to have been previous computed [materialized] by this compute kernel or a previously generated one; par. [0045]: a map operation takes one or more arrays as input [i.e., inputs include data structures as well]; par. [0140]: “Data” node identifies an input to a particular parse node).
wherein the one or more process-executable kernels include a first processor-executable kernel and a second processor-executable kernel, (see below) and
wherein the first processor-executable kernel provides the input to the second processor-executable kernel (e.g., McGuire, Fig. 7B and associated text, par. [00370]: the program sequence 712 includes three programs “(or computer kernels)” A, B and C. Program A has one temporary output T_0. Program B has another temporary output T_1. Program C has the two temporary outputs T_0, T_1 as its input; par. [0374]).
As to claim 20, McGuire/Bendersky discloses the method of claim 15 (see rejection of claim 15 above), McGuire further discloses:
further comprising storing one or more results of one or more first operations performed on a first set of processor-executable kernels input into one or more second operations performed on a second set of processor-executable kernels (e.g., McGuire, Fig. 7B and associated text, par. [00370]: the program sequence 712 includes three programs “(or computer kernels)” A, B and C. Program A has one temporary output T_0. Program B has another temporary output T_1. Program C has the two temporary outputs T_0, T_1 as its input [note that all outputs and inputs must be stored if they are to be used]; par. [0118]: the memory space is allocated when it is needed to store an operation result).
As to claim 21, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1) McGuire further discloses
wherein the combining the identified two or more operations and, traversing the computational graph results in selective kernel generation (e.g., McGuire, par. [0318]: ProgGen 600 traverses the operation dependence graph in order to find operations eligible for fusion. Operations are eligible to be fused into the compute kernel currently being formed once all their inputs are guaranteed to have been previously computed by this compute kernel or a previously generated one).
McGuire does not explicitly disclose traversing the computational graph from the result node toward one or more input nodes.
However, in an analogous art, Bendersky discloses:
traversing the computational graph from the result node toward one or more input nodes (e.g., Bendersky, col. 7 l. 66 – col. 8 l. 1: Fig. 4 and associated text, the compilation constructs this fused representation by traversing all paths in the graph from A 410 up to the inputs, B 401a and C 401b).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the traversal of McGuire such that it is backwards (i.e., from a result node towards one or more input nodes), as taught by Bendersky. McGuire suggests the combination because McGuire discloses traversing the graph without limiting that traversal to any particular direction. It would also have been obvious to try and modify the traversal of McGuire such that it is performed in the backwards direction because as shown by Aman et al. (US 9,184,980), traversal of a graph can be successfully performed in either a forwards or backwards direction. See M.P.E.P. § 2143(I)(E).
As to claim 22, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above) McGuire discloses:
wherein a traversal is to identify one or more nodes that have been materialized and to identify one or nodes that have not been materialized to assist in the combining of the identified two or more operations (e.g., McGuire, par. [0317]: operations to fuse together into a computer kernel; par. [0318]: in some embodiments a simpler algorithm is used to assign operations to kernels. In such a scheme, the ProgGen 600 essentially traverses the operation dependence graph in order to find operations eligible for fusion. Operations [objects] are eligible to be fused into the kernel currently being formed once all their inputs are guaranteed to have been previous computed [materialized] by this compute kernel or a previously generated one; par. [0320]: ProgGen 600 maintains two lists of operations, the non-fusible ready list [nodes that have not been materialized] and the fusible ready list) (this language is only directed to non-limiting intended use. McGuire also combines across stages as set forth above with respect to claim 21).
McGuire does not explicitly disclose backward traversal.
However, in an analogous art, Bendersky discloses:
backward traversal (e.g., Bendersky, col. 7 l. 66 – col. 8 l. 1: Fig. 4 and associated text, the compilation constructs this fused representation by traversing all paths in the graph from A 410 up to the inputs, B 401a and C 401b).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the traversal of McGuire such that it is backwards (i.e., from a result node towards one or more input nodes), as taught by Bendersky. McGuire suggests the combination because McGuire discloses traversing the graph without limiting that traversal to any particular direction. It would also have been obvious to try and modify the traversal of McGuire such that it is performed in the backwards direction because as shown by Aman et al. (US 9,184,980), traversal of a graph can be successfully performed in either a forwards or backwards direction. See M.P.E.P. § 2143(I)(E).
As to claim 25, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above) McGuire further discloses:
wherein the result node comprises a root node representing a final result of a computation represented by the computational graph (e.g., McGuire, Fig. 7 and associated text, par. [0370: the DAG 710 includes one output port [see figure, the last port being the final result])
Claim 2 and 9 are rejected under 35 U.S.C. 103 as unpatentable over McGuire (US 2007/0294663) in view of Bendersky (US 9,798,527) in further view of Meixner et al. (US 2017/0249716) (art of record --- hereinafter Meixner) and Eble et al. (US 2016/0147511) (art of record – hereinafter Eble).
As to claim 2, McGuire/Bendersky discloses the one or more processors of claim 1 (see rejection of claim 1 above) but does not explicitly disclose wherein the one or more processor-executable kernels are to be generated by partitioning the graph so that any and all processor-executable kernels are equal to or below a threshold size to limit compilation times.
However, in an analogous art, Meixner dislcoses:
wherein the one or more processor-executable kernels are to be generated by partitioning the graph so that any and all processor-executable kernels are equal to or below a threshold size (Meixner, par. [0102]: a DAG of kernels; par. [0137]: in the case of graph splitting, the amount of data that is processed by the DAG exceeds the internal memory requirements of the image processor. As such, the DAG has to be split into multiple DAGs, each of which process an amount of data that is within the internal storage space limits of the image processor. If the storage requirements of a single DAG exceed the memory capacity of one or more of these memories [i.e., a threshold], multiple DAGs are created; par. [0123]: a fission split may be imposed by the compiler if the kernel being split K is more computationally intense and/or its instruction footprint is too large to fit into the stencil processor memory [the size of that memory being a threshold]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the generation of kernels using a graph taught by McGuire/Bendersky, such that the kernels are to be generated by partitioning the graph so that any and all processor-executable kernels are equal to or below a threshold size, as taught by Meixner, as Meixner would provide the advantage or a means of avoiding kernels that are too large. (See Meixner, pars. [0137], [0123]).
Further, in an analogous art, Eble discloses:
a threshold size to limit compilation times (e.g., Eble, par. [0073]: the one or more complexity metrics may include a count of lines of code in a candidate splitting region; par. [0074]: use of a function splitting technique may be necessary or desirable only when a source function has a complexity level that exceeds the maximum complexity level; par. [0033]: to divide large size functions into smaller size functions, which by virtue of their size, can be quickly compiled [note too that this language is not limiting as to only expresses the intended result of the positively recited step. See M.P.E.P. § 2111.04]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the threshold size of McGuire/Meixner, such that it comprises a size to limit compilation times, as taught by Eble, as Eble would provide the advantage of a means of ensuring the kernels can be quickly compiled. (See Eble, par. [0033]).
As to claim 9, it is a system claim having limitations substantially similar to those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Claim 24 is rejected under 35 U.S.C. 103 as unpatentable over McGuire (US 2007/0294663) in view of Bendersky (US 9,184,980) in further view of Kerr et al. (US 2015/0339209) (art of record – hereinafter Kerr).
As to claim 24, McGuire/Bendersky disclose the one or more processors of claim 1 (see rejection of claim 1 above) but does not explicitly disclose wherein library calls are intercepted to form the computational graph.
However, in an analogous art, Kerr discloses:
wherein library calls are intercepted to form the computational graph (e.g., Kerr, par. [0061]: the dependency extractor instruments a software application to capture data associated with each task that is executed [capturing this information being intercepting it]. Subsequently, the dependency extractor constructs a dependency graph that captures each task as a node; par. [0033]: a task is a component such as an API call or a computation operation on the CPU; par. [0025]: the CUDA API 101 includes calls and libraries; par. [0029]: tasks, such as CUDA API calls).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the computational graph of McGuire such that it is formed by intercepting library calls, as taught by Kerr, as Kerr would provide the advantage of a means of better directing optimization efforts of the program. (See Kerr, par. [0011]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM 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, Hyung S Sough can be reached at (571)272-6799. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
