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 .
The Office Action is in response to claims filed 09/02/2026.
Claims 1-20 are pending.
Claim Objections
The claim objection to claim 14 has been withdrawn.
Claim 8 is objected to because it recites “and in response to the API call, causing a context associated with the series of operations, to be performed using the one or more processors, to be stored in the storage location.” Examiner understands that it is the operations that are “to be performed using the on or more processors” and that it is the “context” that is stored in the storage location. The wording and punctuation causes a lack of clarity. For example, it could be interpreted that the context is performed using the one or more processors. Appropriate clarification/correction is required.
Claim 20 is objected to because it recites “identifiers are included.” Claims 7 and 14 recite similar subject matter, but instead recite “identifiers are indicated.” The connection between “included” and “indicated” is unclear. Appropriate correction is required.
Claim Rejections - 35 USC § 112
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.
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. Claim 10 has been amended to recite “wherein the API call includes the arguments indicating the storage location of the one or more processors usable to store the context.” Applicant stated that support for the amended claims can be found in the specification. Examiner did not find support for an API argument that indicates the “storage location of the one or more processors.”
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6, 10, and 13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites that “the one or more identifiers are indicated based at least on the series of operations operating on the one or more processors.” Claim 1, from which claim 6 depends on, recites “a context associated with a series of operations to be performed by the one or more processors.” The “operations” were not recited to be “operating” on the one or more processors before being recited in claim 6. Therefore, it is indefinite and unclear of how identifiers are indicated based on operations operating on the one or more processors. For the purposes of compact prosecution, examiner interprets that the one or more identifiers are indicated based on the series of operations to be performed by the one or more processors.
Claim 10 recites “wherein the API call includes the arguments indicating the storage location of the one or more processors usable to store the context.” The phrase “storage location of the one or more processors” is unclear. The broadest reasonable interpretation of “storage location” is an address in volatile or non-volatile memory such as RAM, a solid state drive, or a hard disk drive. Processors do not have a “storage location” because processors are not stored in memory. For the purposes of compact prosecution, examiner interprets the API call to include the arguments indicating the storage location that is accessible to the one or more processors and that the one or more processors can use that storage location to store the context.
Claim 13 recites “indicating one or more identifiers based at least on the series of operations operating on the one or more processors.” Claim 8, from which claim 13 depends on, recites “arguments indicating a series of operations to be performed by one or more processors.” Similar to claim 6, the “operations” were not recited to be “operating on the one or more processors before being recited in claim 13. Therefore, it is indefinite and unclear of how identifiers are indicated based on operations operating on the one or more processors. For the purposes of compact prosecution, examiner interprets that the one or more identifiers are indicated based on the series of operations to be performed by the one or more processors.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3, 5, 8-10, 12, 15-17, and 19 is/are rejected under 35 U.S.C. 102 as being unpatentable over Fontaine et al. Pat. No. US 20220334890 A1 (hereafter Fontaine ‘890).
With regard to claim 1, Fontaine ‘890 teaches one or more processors, comprising (¶ [0064] states “API functions illustrated in FIGS. 3-5 are performed by any suitable processor and/or combination of processors, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof”):
circuitry to, in response to an application programming interface (API) call, return a context associated with a series of operations to be performed by the one or more processors (¶ [0064] states “API functions illustrated in FIGS. 3-5 are performed by any suitable processor and/or combination of processors, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof.” ¶ [0067] states “FIG. 3 illustrates a diagram 300 of a User Object Create API call.” ¶ [0067] additionally states “User Object Create API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to create a user object, which refers to a data structure that indicates a destructor and a reference count.” ¶ [0067] additionally states “In at least one embodiment, said user object corresponds to a computing resource, such as said object, region of memory, data object, data structure, and/or any suitable computing resource utilized in operations of a computer program. In at least one embodiment, said user object is utilized to track references to said computing resource in which once said reference count reaches zero, said destructor is invoked to destroy or otherwise delete said computing resource.” ¶ [0068] states “In at least one embodiment, parameter “object_out” indicates a location to return a handle to said user object” and “In at least one embodiment, parameter “ptr” indicates a pointer to pass to a destroy function (e.g., destructor). In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.” Examiner’s Note: the callback function is at least one of the series of operations to be performed by the one or more processors).
With regard to claim 3, Fontaine ‘890 teaches the one or more processors of claim 1. Fontaine ‘890 additionally teaches wherein the API call includes arguments comprising a memory location usable to store one or more data structures that include the context (¶ [0068] states “parameter “object_out” indicates a location to return a handle to said user object.” See FIG. 3).
With regard to claim 5, Fontaine ‘890 teaches the one or more processors of claim 1. Fontaine ‘890 additionally teaches wherein one or more streaming multiprocessors (SMs) comprise a subset of SMs of the one or more processors allocated to perform the series of operations (¶ [0249] states “In at least one embodiment, pipeline manager 2602 manages configuration of one or more DPCs 2606 for processing tasks allocated to GPC 2600. In at least one embodiment, pipeline manager 2602 configures at least one of one or more DPCs 2606 to implement at least a portion of a graphics rendering pipeline. In at least one embodiment, DPC 2606 is configured to execute a vertex shader program on a programmable streaming multiprocessor (“SM”) 2614.” ¶ [0251] states “each DPC 2606 included in GPC 2600 comprise, without limitation, … one or more SMs 2614.” ¶ [0248] states “each GPC 2600 includes, without limitation, … one or more Data Processing Clusters (“DPCs”).” Examiner’s Note: in each GPC, there are multiple DPCs. Each DPC contains multiple SMs. The SMs in a DPC are a subset of all SMs. Tasks are allocated to the GPC and DPC. These tasks are the series of operations associated with the context, or user object).
With regard to claim 8, Fontaine ‘890 teaches a computer-implemented method comprising (¶ [0076] states “FIG. 6 illustrates an example of a process 600 of generating data structures … some or all of process 600 (or any other processes described herein, or variations and/or combinations thereof) is performed under control of one or more computer systems”):
receiving an application programming interface (API) call including arguments indicating a series of operations to be performed by one or more processors and a storage location (¶ [0067] states “FIG. 3 illustrates a diagram 300 of a User Object Create API call, in accordance with at least one embodiment.” ¶ [0068] states “In at least one embodiment, parameter “object_out” indicates a location to return a handle to said user object” and “In at least one embodiment, parameter “ptr” indicates a pointer to pass to a destroy function (e.g., destructor). In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.” Examiner’s Note: the callback function is at least one of the series of operations to be performed by the one or more processors);
and in response to the API call, causing a context associated with the series of operations, to be performed using the one or more processors, to be stored in the storage location (¶ [0069] states “following said User Object Create API call indicating creation of said user object, said user object is created and a handle to said user object is returned in a location specified by parameter “object_out.””).
With regard to claim 9, Fontaine ‘890 teach the computer-implemented method of claim 8. Fontaine ‘890 additionally teaches wherein the API call includes the arguments indicating the series of operations to be performed using one or more streaming multiprocessors (SMs) (¶ [0068] states “In at least one embodiment, parameter “ptr” indicates a pointer to pass to a destroy function (e.g., destructor). In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.” ¶ [0064] states “API functions illustrated in FIGS. 3-5 are performed by any suitable processor and/or combination of processors, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof, and in any suitable order and/or manner, such as in parallel.” ¶ [0249] states “In at least one embodiment, pipeline manager 2602 manages configuration of one or more DPCs 2606 for processing tasks allocated to GPC 2600. In at least one embodiment, pipeline manager 2602 configures at least one of one or more DPCs 2606 to implement at least a portion of a graphics rendering pipeline. In at least one embodiment, DPC 2606 is configured to execute a vertex shader program on a programmable streaming multiprocessor (“SM”) 2614.”).
With regard to claim 10, Fontaine ‘890 teaches the computer-implemented method of claim 8. Fontaine ‘890 additionally teaches wherein the API call includes the arguments indicating the storage location of the one or more processors usable to store the context (¶ [0068] states “parameter “object_out” indicates a location to return a handle to said user object.” See FIG. 3. ¶ [0064] states “API functions illustrated in FIGS. 3-5 are performed by any suitable processor and/or combination of processors, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof, and in any suitable order and/or manner, such as in parallel.” Examiner’s Note: in light of the 112(b) rejection, examiner interpreted the storage location to be accessible to the one or more processors so that the storage location is usable to store the context. See 35 U.S.C. 112(b) rejection for more details).
With regard to claim 12, Fontaine ‘890 teaches the computer-implemented method of claim 8. Fontaine ‘890 additionally teaches wherein one or more streaming multiprocessors (SMs) comprise a subset of SMs of the one or more processors to perform the series of operations (¶ [0249] states “In at least one embodiment, pipeline manager 2602 manages configuration of one or more DPCs 2606 for processing tasks allocated to GPC 2600. In at least one embodiment, pipeline manager 2602 configures at least one of one or more DPCs 2606 to implement at least a portion of a graphics rendering pipeline. In at least one embodiment, DPC 2606 is configured to execute a vertex shader program on a programmable streaming multiprocessor (“SM”) 2614.” ¶ [0251] states “each DPC 2606 included in GPC 2600 comprise, without limitation, … one or more SMs 2614.” ¶ [0248] states “each GPC 2600 includes, without limitation, … one or more Data Processing Clusters (“DPCs”).” Examiner’s Note: in each GPC, there are multiple DPCs. Each DPC contains multiple SMs. The SMs in a DPC are a subset of all SMs. Tasks are allocated to the GPC and DPC. These tasks are the series of operations associated with the context, or user object).
With regard to claim 15, Fontaine ‘890 teaches a computer system comprising (¶ [0102] states “FIG. 10 illustrates a processing system 1000, in accordance with at least one embodiment”):
one or more processors and memory storing executable instructions that when executed by the one or more processors, cause the one or more processors to (¶ [0076] states “code is stored on a computer-readable storage medium in form of a computer program comprising a plurality of computer-readable instructions executable by one or more processors. In.” ¶ [0102] states “processing system 1000 includes one or more processors 1002 and one or more graphics processors 1008.” ¶ [0107] states “memory device 1020 can operate as system memory for processing system 1000, to store data 1022 and instructions 1021 for use when one or more processors 1002 executes an application or process”):
in response to an application programming interface (API) call, return a context associated with a series of operations to be performed by the one or more processors (¶ [0064] states “API functions illustrated in FIGS. 3-5 are performed by any suitable processor and/or combination of processors, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof.” ¶ [0067] states “FIG. 3 illustrates a diagram 300 of a User Object Create API call.” ¶ [0067] additionally states “User Object Create API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to create a user object, which refers to a data structure that indicates a destructor and a reference count.” ¶ [0067] states “In at least one embodiment, said user object corresponds to a computing resource, such as said object, region of memory, data object, data structure, and/or any suitable computing resource utilized in operations of a computer program. In at least one embodiment, said user object is utilized to track references to said computing resource in which once said reference count reaches zero, said destructor is invoked to destroy or otherwise delete said computing resource.” ¶ [0068] states “In at least one embodiment, parameter “object_out” indicates a location to return a handle to said user object” and “In at least one embodiment, parameter “ptr” indicates a pointer to pass to a destroy function (e.g., destructor). In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.”).
With regard to claim 16, Fontaine ‘890 teaches the computer system of claim 15. Fontaine ‘890 additionally teaches wherein the context indicates one or more references to resources used by runtime software to manage execution of one or more workloads (¶ [0067] states “In at least one embodiment, said user object corresponds to a computing resource, such as said object, region of memory, data object, data structure, and/or any suitable computing resource utilized in operations of a computer program. In at least one embodiment, said user object is utilized to track references to said computing resource in which once said reference count reaches zero, said destructor is invoked to destroy or otherwise delete said computing resource.”).
With regard to claim 17, Fontaine ‘890 teaches the computer system of claim 15. Fontaine ‘890 additionally teaches wherein the API call includes arguments comprising a memory location usable to store the one or more data structures comprising the context (¶ [0068] states “parameter “object_out” indicates a location to return a handle to said user object.” See FIG. 3. Examiner’s Note: the user object is a data structure that comprises the context).
With regard to claim 19, Fontaine ‘890 teaches the computer system of claim 15. Fontaine ‘890 additionally teaches wherein one or more streaming multiprocessors (SMs) comprise a subset of SMs of the one or more processors allocated to perform the series of operations (¶ [0249] states “In at least one embodiment, pipeline manager 2602 manages configuration of one or more DPCs 2606 for processing tasks allocated to GPC 2600. In at least one embodiment, pipeline manager 2602 configures at least one of one or more DPCs 2606 to implement at least a portion of a graphics rendering pipeline. In at least one embodiment, DPC 2606 is configured to execute a vertex shader program on a programmable streaming multiprocessor (“SM”) 2614.” ¶ [0251] states “each DPC 2606 included in GPC 2600 comprise, without limitation, … one or more SMs 2614.” ¶ [0248] states “each GPC 2600 includes, without limitation, … one or more Data Processing Clusters (“DPCs”).” Examiner’s Note: in each GPC, there are multiple DPCs. Each DPC contains multiple SMs. The SMs in a DPC are a subset of all SMs. Tasks are allocated to the GPC and DPC. These tasks are the series of operations associated with the context, or user object).
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) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fontaine ‘890 in view of Fontaine Pat. No. US 20220342728 A1 (hereafter Fontaine ‘728).
With regard to claim 2, Fontaine ‘890 teaches the one or more processors of claim 1. Fontaine ‘890 does not explicitly teach an argument comprising a stream.
However, in an analogous art, Fontaine ‘728 additionally teaches wherein the API call includes arguments comprising a stream indicating the series of operations to be performed using one or more streaming multiprocessors (SMs) (¶ [0057] states “parameters for said stream get capture info API call include “stream.”” See FIG. 2. ¶ [0049] states “a stream indicates a sequence of one or more operations.” ¶ [0241] states “SM 2314 comprises, without limitation, a programmable streaming processor that is configured to process tasks represented by a number of threads.” ¶ [0240] states “each DPC 2306 included in GPC 2300 comprise, without limitation, … one or more SMs 2314”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the API with arguments comprising a stream of Fontaine ‘728 with the user object create API of Fontaine ‘890. As a result, the API receives a stream argument, and it is the stream argument that indicates the series of operation to be performed. According to Fontaine ‘728 ¶ [0056], “stream get capture info API call is utilized to obtain a handle to said graph associated with said capturing stream which can be utilized to perform operations on said graph. In at least one embodiment, said stream get capture info API call is utilized to query said stream's capture state.” In other words, streams are used to interact with graphs, so the API resulting from the combination uses streams to interact with graphs. A person having ordinary skill in the art would have been motivated to make this combination to manage graph code efficiently (¶ [0003] states “Graph code can be generated and utilized to perform various operations. Management of graph code can be difficult, as graph code can be complex. Techniques to manage graph code may therefore be improved using CUDA or other parallel computing platform code”). Fontaine ’890 also describes using objects and graphs (¶ [0054] states “when said reference counter reaches a value of 0, said system determines that said object utilized by said graph can be released (e.g., memory allocated for said object can be released) or otherwise destroyed”), which gives further application of managing graphs efficiently.
Claim(s) 4, 6-7, 11, 13-14, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fontaine ‘890 in view of Munshi et al. Pat. No. US 10067797 B2 (hereafter Munshi).
With regard to claim 4, Fontaine ‘890 teaches the one or more processors of claim 1.
Fontaine ‘890 additionally teaches wherein the API call returns an indication that one or more identifiers have been stored (¶ 0069] states “following said User Object Create API call indicating creation of said user object, said user object is created and a handle to said user object is returned in a location specified by parameter “object_out”” and “status is returned in response to said User Object Create API call to indicate a status indication of said User Object Create API call. In at least one embodiment, said status indication indicates if one or more operations of said User Object Create API are successful, have failed, or if other errors have occurred.” Examiner’s Note: the status indication returned from the API indicates whether the storage operation of User Object Create API was successful).
Fontaine ‘890 does not explicitly teach an identifier.
However, in an analogous art, Munshi teaches wherein the API call returns an indication that one or more identifiers have been stored (Col. 7 Lines 43-45 states “the compute platform layer 111 may generate a computing device identifier 307 in response to API requests from the application”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the computing device identifiers of Munshi with the user object that is stored according to a parameter of the function call of Fontaine ‘890. As a result, the computing device identifier is part of the user object that is stored at the location specified by “object_out.” A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 6, Fontaine ‘890 teaches the one or more processors of claim 1. Fontaine ‘890 additionally teaches wherein one or more identifiers are indicated based at least, on the series of operations operating on the one or more processors (¶ [0068] states “In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.” Examiner’s Note: in light of the 112(b) rejection related to the operations operating on the one or more processors, examiner interprets this to refer to the series of operations that are to be performed and that are associated with the context of claim 1. See 35 U.S.C. § 112(b) rejection for more detail).
Fontaine ‘890 does not explicitly teach identifiers.
However, in an analogous art, Munshi teaches wherein one or more identifiers are indicated based at least, on the series of operations operating on the one or more processors (Col. 7 Lines 43-47 states “the compute platform layer 111 may generate a computing device identifier 307 in response to API requests from the application 303 for configuring data parallel processing resources according to a list of capability requirements included in the API requests.” Col. 7 Lines 36-37 state “an application 303 and a platform layer 305 may be running in a host CPU 301.” Examiner’s Note: the computing device identifiers are indicated based on API requests from the application).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the computing device identifiers of Munshi with the destroy callback function of Fontaine ‘890. As a result, when the callback function is specified, it will indicate the computing device identifiers of resources that are to be freed. A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 7, Fontaine ‘890 teaches the one or more processors of claim 1. Fontaine ‘890 additionally teaches wherein one or more identifiers are indicated by a sub-context associated with the series of operations performed by the one or more processors (¶ [0068] states “In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.”).
Fontaine ‘890 does not explicitly teach that one or more identifiers are indicated by a sub-context.
However, in an analogous art, Munshi teaches wherein one or more identifiers are indicated by a sub-context associated with the series of operations performed by the one or more processors (Col. 7 Lines 33-36 states “FIG. 3 is a block diagram illustrating one embodiment of a plurality of physical computing devices configured as a logical computing device using a computing device identifier.” Col. 7 Lines 47-54 states “The computing device identifier 307 may refer to a selection of actual physical computing devices Physical_Compute_Device-1 305 through Physical_Compute_Device-N 311 according to the configuration by the compute platform layer 111. In one embodiment, a logical computing device 309 may represent the group of selected actual physical computing devices separate from the host CPU 301.” See FIG. 3. Examiner’s Note: the logical computing device 309 is the sub-context. When the computing device identifier refers to a selection of physical computing devices, it is being indicated by the logical computing device 309).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the logical computing device representing a group of computing devices of Munshi with the API of Fontaine ‘890. As a result, the devices represented by the logical computing device are associated with the callback function associated with the user object of Fontaine ‘890. The destroy callback function of Fontaine ‘890 can be used to free the resources indicated by the logical computing device of Munshi. A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 11, Fontaine ‘890 teaches the computer-implemented method of claim 8. Fontaine ‘890 additionally teaches further comprising: in response to the API call, indicating that one or more identifiers have been stored (¶ 0069] states “following said User Object Create API call indicating creation of said user object, said user object is created and a handle to said user object is returned in a location specified by parameter “object_out”” and “status is returned in response to said User Object Create API call to indicate a status indication of said User Object Create API call. In at least one embodiment, said status indication indicates if one or more operations of said User Object Create API are successful, have failed, or if other errors have occurred.” Examiner’s Note: the status indication returned from the API indicates whether the storage operation of User Object Create API was successful).
Fontaine ‘890 does not explicitly teach identifiers.
However, in an analogous art, Munshi teaches further comprising: in response to the API call, indicating that one or more identifiers have been stored (Col. 7 Lines 43-45 states “the compute platform layer 111 may generate a computing device identifier 307 in response to API requests from the application”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the computing device identifiers of Munshi with the user object that is stored according to a parameter of the function call of Fontaine ‘890. As a result, the computing device identifier is part of the user object that is stored at the location specified by “object_out.” A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 13, Fontaine ‘890 teaches the computer-implemented method of claim 8. Fontaine ‘890 additionally teaches further comprising: in response to the API call, indicating one or more identifiers based at least on the series of operations operating on the one or more processors (¶ [0068] states “In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.” Examiner’s Note: in light of the 112(b) rejection related to the operations operating on the one or more processors, examiner interprets this to refer to the series of operations that are to be performed. See 35 U.S.C. § 112(b) rejection for more detail).
Fontaine ‘890 does not explicitly teach the identifiers are indicated by a context.
Munshi additionally teaches further comprising: in response to the API call, indicating one or more identifiers based at least on the series of operations operating on the one or more processors (Col. 7 Lines 33-36 states “FIG. 3 is a block diagram illustrating one embodiment of a plurality of physical computing devices configured as a logical computing device using a computing device identifier.” Col. 7 Lines 47-54 states “The computing device identifier 307 may refer to a selection of actual physical computing devices Physical_Compute_Device-1 305 through Physical_Compute_Device-N 311 according to the configuration by the compute platform layer 111. In one embodiment, a logical computing device 309 may represent the group of selected actual physical computing devices separate from the host CPU 301.” See FIG. 3. Examiner’s Note: the logical computing device 309 is the context. When the computing device identifier refers to a selection of physical computing devices, it is being indicated by the logical computing device 309).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the logical computing device and computing device identifiers of Munshi with the user object and callback function of Fontaine ‘890. When the user object create API is called, the destroy callback function is specified. In the combination, the destroy callback function indicates the computing device identifiers of computer resources that would be freed. Therefore, the identifiers are indicated by the series of operations, and it is in response to the API call.
A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 14, Fontaine ‘890 teaches the computer-implemented method of claim 8. Fontaine ‘890 additionally teaches wherein one or more identifiers are indicated by a sub-context of the context, wherein the context is associated with the series of operations to be performed using the one or more processors (¶ [0067] states “User Object Create API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to create a user object, which refers to a data structure that indicates a destructor and a reference count.” ¶ [0067] additionally states “In at least one embodiment, said user object corresponds to a computing resource, such as said object, region of memory, data object, data structure, and/or any suitable computing resource utilized in operations of a computer program. In at least one embodiment, said user object is utilized to track references to said computing resource in which once said reference count reaches zero, said destructor is invoked to destroy or otherwise delete said computing resource.” ¶ [0068] states “In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.”).
Fontaine ‘890 does not explicitly teach identifiers.
However, in an analogous art, Munshi teaches wherein one or more identifiers are indicated by a sub-context of the context, wherein the context is associated with the series of operations to be performed using the one or more processors (Col. 7 Lines 33-36 states “FIG. 3 is a block diagram illustrating one embodiment of a plurality of physical computing devices configured as a logical computing device using a computing device identifier.” Col. 7 Lines 47-54 states “The computing device identifier 307 may refer to a selection of actual physical computing devices Physical_Compute_Device-1 305 through Physical_Compute_Device-N 311 according to the configuration by the compute platform layer 111. In one embodiment, a logical computing device 309 may represent the group of selected actual physical computing devices separate from the host CPU 301.” See FIG. 3. Examiner’s Note: the logical computing device 309 is the sub-context. When the computing device identifier refers to a selection of physical computing devices, it is being indicated by the logical computing device 309).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the logical computing device and computing device identifier of Munshi with the user object and callback function of Fontaine ‘890. The user object identifies a count of references to computer resources and is the context. The logical computing device that represents a group of selected actual computing devices is a subset of the resources referred to by the user object. Therefore, the logical computing device is a sub-context of the context. A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 18, Fontaine ‘890 teaches the computer system of claim 15. Fontaine ‘890 additionally teaches wherein the API call returns an indication that one or more identifiers have been stored (¶ 0069] states “following said User Object Create API call indicating creation of said user object, said user object is created and a handle to said user object is returned in a location specified by parameter “object_out”” and “status is returned in response to said User Object Create API call to indicate a status indication of said User Object Create API call. In at least one embodiment, said status indication indicates if one or more operations of said User Object Create API are successful, have failed, or if other errors have occurred.” Examiner’s Note: the status indication returned from the API indicates whether the storage operation of User Object Create API was successful).
Fontaine ‘890 does not explicitly teach identifiers.
However, in an analogous art, Munshi teaches wherein the API call returns an indication that one or more identifiers have been stored (Col. 7 Lines 43-45 states “the compute platform layer 111 may generate a computing device identifier 307 in response to API requests from the application”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the computing device identifiers of Munshi with the user object that is stored according to a parameter of the function call of Fontaine ‘890. As a result, the computing device identifier is part of the user object that is stored at the location specified by “object_out.” A person having ordinary skill in the art would have been motivated to make this combination “for configuring data parallel processing resources according to a list of capability requirements included in the API requests” (Col. 7 Lines 45-47). This is performed for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
With regard to claim 20, Fontaine ‘890 teaches the computer system of claim 15. Fontaine ‘890 additionally teaches wherein one or more identifiers are included in a sub-context associated with the series of operations to be performed by the one or more processors (¶ [0068] states “In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use.”)
Fontaine ‘890 does not explicitly teach that one or more identifiers are indicated by a sub-context.
However, in an analogous art, Munshi teaches wherein one or more identifiers are included in a sub-context associated with the series of operations to be performed by the one or more processors (Col. 7 Lines 33-36 states “FIG. 3 is a block diagram illustrating one embodiment of a plurality of physical computing devices configured as a logical computing device using a computing device identifier.” Col. 7 Lines 47-54 states “The computing device identifier 307 may refer to a selection of actual physical computing devices Physical_Compute_Device-1 305 through Physical_Compute_Device-N 311 according to the configuration by the compute platform layer 111. In one embodiment, a logical computing device 309 may represent the group of selected actual physical computing devices separate from the host CPU 301.” See FIG. 3. Examiner’s Note: the logical computing device 309 is the sub-context. When the computing device identifier refers to a selection of physical computing devices, it is being indicated by the logical computing device 309).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the logical computing device representing a group of computing devices of Munshi with the API of Fontaine ‘890. As a result, the devices represented by the logical computing device are associated with the callback function associated with the user object of Fontaine ‘890. The destroy callback function of Fontaine ‘890 can be used to free the resources indicated by the logical computing device of Munshi. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “[allowing] an application to perform a task using any available processing resources, such as CPUs and one or more GPUs, capable of performing the task” (Col. 1 Lines 55-58) and addresses the problem of how “to leverage processing resources of both CPUs and GPUs” (Col. 1 Lines 50-51).
Response to Arguments
Applicant's arguments filed 09/02/2026 have been fully considered but they are not persuasive.
With regard to the 35 U.S.C. § 103 rejection of independent claims 1, 8, and 15, applicant argues that Fontaine ‘890 in view of Munshi does not teach the amended claims. Applicant specifically argues that the user object create API and reference count of Fontaine ‘890 does not teach the limitation “in response to an [API] call, return a context associated with a series of operations to be performed by the one or more processors” in claim 1 (Page 7 of Applicant’s remarks).
Examiner respectfully disagrees. The broadest reasonable interpretation of “context” in view of ¶ [0082] of the applicant’s specification is “a description of resources available to a processor.” According to Fontaine ‘890 ¶ [0067], the “User Object Create API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to create a user object, which refers to a data structure that indicates a destructor and a reference count.” Fontaine ‘890 ¶ [0067] additionally states “In at least one embodiment, said user object is utilized to track references to said computing resource in which once said reference count reaches zero, said destructor is invoked to destroy or otherwise delete said computing resource.” The reference count is a description of resources available to a processor. Additionally, the destroy callback function (or destructor) is a series of operations to be performed by the one or more processors. Therefore, Fontaine ‘890 anticipates the amendments to claim 1, and Examiner rejects independent claim 1 under 35 U.S.C. § 102. Examiner also rejects independent claims 8 and 15 under 35 U.S.C. § 102 for similar reasons.
Applicant additionally argues “claims 3-5, 6, 7, 9, 10-14, and 16-20 are allowable at least for depending from an allowable independent claim” and “that at least some of claims 3-5, 6, 7, 9, 10-14, and 16-20 additionally recite patentable subject matter not taught or otherwise rendered obvious by Fontaine ‘890 and Munshi individually or in combination (Page 9 of Applicant’s remarks).
Examiner respectfully disagrees. Although Applicant’s arguments are thorough and complete, there are no separate arguments against the dependent claims. The arguments are not persuasive for the same reasons as the response to the arguments against the claim from which these claims depend. Additionally, since independent claims 1, 8, and 15 are rejected under 35 U.S.C. § 102 (Fontaine ‘890), the arguments that Munshi does not cure the deficiencies of Fontaine ‘890 for claims 3, 5, 9-10, 12, 16-17, and 19 are moot.
Examiner rejects claims 3, 5, 9-10, 12, 16-17, and 19 under 35 U.S.C. § 102 and maintains the 35 U.S.C. § 103 rejection against claims 4, 6-7, 11, 13-14, 18, and 20 (Fontaine ‘890 in view of Munshi).
Applicant additionally argues “claims 2, 6, 9, 13, and 16 are allowable at least for depending from an allowable independent claim” and “that at least some of claims 2, 6, 9, 13, and 16 additionally recite patentable subject matter not taught or otherwise rendered obvious by Fontaine ‘890, Munshi, and Fontaine ‘729, individually or in combination” (Page 9 of Applicant’s remarks).
Examiner respectfully disagrees. Although Applicant’s arguments are thorough and complete, there are no separate arguments against the dependent claims. The arguments are not persuasive for the same reasons as the response to the arguments against the claim from which these claims depend. Additionally, Applicant’s arguments against claims 6, 9, 13, and 16 related to the combination of Fontaine ‘890, Munshi, and Fontaine ‘728 are considered moot because the rejection of claims 6, 9, 13, and 16 does not rely upon the combination of Fontaine ‘890, Munshi, and Fontaine ‘728. See Examiner’s response to arguments above for claims 6, 9, 13, and 16.
Examiner rejects claim 2 under 35 U.S.C. § 103 (Fontaine ‘890 in view of Fontaine ‘728).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20240054595 A1
teaches
CONCURRENT COMPUTE CONTEXT
US 20240378790 A1
teaches
PIPELINED GRAPHICS STATE MANAGEMENT
US 20190235924 A1
teaches
DYNAMIC PARTITIONING OF EXECUTION RESOURCES
US 20180285110 A1
teaches
EFFICIENT MULTI-CONTEXT THREAD DISTRIBUTION
THIS ACTION IS MADE FINAL. 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 PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm.
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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
