Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-2, 4-8, 10-12, 14-18, and 20 are pending. Claims 3, 9, 13, and 19 are canceled by Applicant.
Examiner Notes
Examiner cites particular paragraphs and/or columns and lines in the references as applied to Applicant’s claims 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 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. The prompt development of a clear issue requires that the replies of the Applicant meet the objections to and rejections of the claims. Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06.
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.
Claim Objections
As per claim 17, it is objected to due to minor informalities. In ll. 2, “se” should be “the second information”. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 10-12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Munshi et al. (US 2008/0276262) (hereinafter Munshi as previously cited) in view of
Neiman et al. (US 7,376,693) (hereinafter Neiman) in view of
Rafique et al. (US 2015/0212859) (hereinafter Rafique as previously cited).
As per claim 1, Munshi primarily teaches the invention as claimed including a storage system comprising:
a memory (fig. 11, block 1104-1107); and
a processing circuit coupled to the memory (fig. 1, blocks 115 and 117) , the processing circuit including a first compute kernel, and a second compute kernel ([0051]-[0052] a plurality of compute kernel execution instances for executing corresponding compute kernel objects), the processing circuit being configured to:
a first compute function corresponding to the first compute kernel and a second compute function corresponding to the second compute kernel ([0050]-[0051] a compute kernel object may be an object created for the associated streams and executables of the corresponding processing task to perform a function i.e., a compute kernel object performs a compute function and a plurality of compute kernel execution instances for executing corresponding compute kernel objects); and
execute, based on the information, the first compute function and the second compute function via respectively the first compute kernel and the second compute kernel according to the first order as identified in the first task ([0051]-[0052] and [0061] execute compute kernel objects according their priorities).
Munshi does not explicitly teach:
receive a first task from a first application, wherein the first task identifies a first compute function and a second compute function, the first task identifying a first order of execution of the first compute function and the second compute function;
based on an available resource to execute the first task, transmit information to the first compute kernel and the second compute kernel in the first order of the execution of the first compute function and the second compute function as identified in the first task.
However, Neiman teaches receive a first task from a first application, wherein the first task identifies a first compute function and a second compute function (col. 24, ll. 41 to col. 25, ll. 7 deploy a compute function on a node computing device of a distributed computing system in communication with a local computing device configured to perform computations for a first portion of a computer software application and to send a second portion of said application for computation on said distributed computing network, wherein said second portion comprises a job comprising an input, wherein said input comprises a task to be performed by said compute function, initiating said job on said node computing device; and providing said input to said job after initiating said job on said node computing device; col. 25, ll. 50-52 wherein said compute function is one of a plurality of compute functions deployed on said distributed computing system; and col. 26, ll. 15-21 wherein said job further comprises a meta-information comprising an identification of said compute function for use with said job and meta-information comprising an identification of a sequence of task computations for said plurality of tasks).
Neiman and Munshi are both concerned with compute functions/kernels and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Munshi in view of Neiman because it would provide for a configuration of a queue which may be closely correlated with that of the node computers adapting to work most efficiently together. The queue may represent the single point of failure for the compute backbone, such that the number of components downstream of the queue may be increased substantially without increasing the probability of a failure of the entire compute backbone, even though the mean time to failure of some component downstream of the queue is likely to decrease as the number of such components increases. With such an arrangement, a user may be guaranteed to obtain a result from the compute backbone even if all components downstream of the fault tolerant queue fail and need to be replaced. In this way, the queue may represent a minimum availability of the compute backbone.
Munshi in view of Neiman do not explicitly teach:
the first task identifying a first order of execution of the first compute function and the second compute function;
based on an available resource to execute the first task, transmit information to the first compute kernel and the second compute kernel in the first order of the execution of the first compute function and the second compute function as identified in the first task.
However, Rafique teaches:
the first task identifying a first order of execution of the first compute function and the second compute function ([0056]-[0057] registry manager module stores a list of a plurality of registered compute kernels, wherein the list includes identifying information for each compute kernel including an identifier for each compute kernel and timing information for each compute kernel; [0066] information included in the received execution request from the first virtual machine is compared to information in the registry manager module in order to identify the first compute kernel from amongst the registered compute kernels; [0089] in the event that none of the one or more graphics processing units identified in the records stored by the unit collection module are free, then the scheduler module queues the compute kernel for later execution when one or more of the currently executing compute kernels has completed its execution);
based on an available resource to execute the first task, transmit information to the first compute kernel and the second compute kernel in the first order of the execution of the first compute function and the second compute function as identified in the first task ([0073]-[0074] scheduler module is configured to receive information about the registered first compute kernel from the registry manager module along with information about available resources of the one or more graphics processing units from the unit collection module. The scheduler module uses the information about the registered first compute kernel to determine what resources will be needed in order to execute the first compute kernel. The scheduler module is configured to compare the required resources with the available resources and allocate the first compute kernel to at least one of the one or more graphics processing units and [0089] in the event that none of the one or more graphics processing units identified in the records stored by the unit collection module are free, then the scheduler module queues the compute kernel for later execution when one or more of the currently executing compute kernels has completed its execution).
Rafique and Munshi are both concerned with compute functions/kernels and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Munshi in view of Neiman in view of Rafique because it would provide a way to allocate the best available resources to compute kernels to minimize interference between execution of the compute kernels while efficiently sharing resources between applications.
As per claim 2, the combination of references above teaches wherein the processing circuit is further configured to:
receive a second task from a second application (Neiman col. 4, ll. 12-24 plurality of applications), wherein the second task identifies the first compute function and the second compute function (Neiman col. 24, ll. 41 to col. 25, ll. 7 deploy a compute function on a node computing device of a distributed computing system in communication with a local computing device configured to perform computations for a first portion of a computer software application and to send a second portion of said application for computation on said distributed computing network, wherein said second portion comprises a job comprising an input, wherein said input comprises a task to be performed by said compute function, initiating said job on said node computing device; and providing said input to said job after initiating said job on said node computing device; col. 25, ll. 50-52 wherein said compute function is one of a plurality of compute functions deployed on said distributed computing system; and col. 26, ll. 15-21 wherein said job further comprises a meta-information comprising an identification of said compute function for use with said job and meta-information comprising an identification of a sequence of task computation for said plurality of tasks) and a second order of execution of the first compute function and the second compute function (Rafique [0056]-[0057] registry manager module stores a list of a plurality of registered compute kernels, wherein the list includes identifying information for each compute kernel including an identifier for each compute kernel and timing information for each compute kernel; [0066] information included in the received execution request from the first virtual machine is compared to information in the registry manager module in order to identify the first compute kernel from amongst the registered compute kernels; [0089] in the event that none of the one or more graphics processing units identified in the records stored by the unit collection module are free, then the scheduler module queues the compute kernel for later execution when one or more of the currently executing compute kernels has completed its execution), wherein the second order is different from the first order (Munshi [0030] it should be appreciated that some of the operations described may be performed in different order); and
execute the first compute function and the second compute function according to the second order (Munshi [0051]-[0052] and [0061] execute compute kernel objects according their priorities).
As per claim 10, Munshi further teaches the storage system of claim 1 further comprising: an interface accessible to the first application for generating the first compute function and the second compute function according to the first order ([0033] Application Programming Interface and [0051] API calls to a compute runtime to execute a compute kernel may include the number of threads that execute simultaneously in parallel on a compute processor and the number of compute processors to use. A compute kernel execution instance may include a priority value indicating a desired priority to execute the corresponding compute kernel object).
As per claim 11, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 12, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
As per claim 20, it has similar limitations as claim 10 and is therefore rejected using the same rationale.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Munshi in view of Neiman in view of Rafique in view of Senapaty et al. (US 10,365,949) (hereinafter Senapaty).
As per claim 4, Munshi in view of Neiman in view of Rafique do not explicitly teach wherein the memory includes a first queue and a second queue, and wherein the processing circuit is further configured to:
store the first task in the first queue; and
based on storing the first task in the first queue, add the information for the first task to the second queue and modify the first queue.
However, Senapaty teaches wherein the memory includes a first queue and a second queue, and wherein the processing circuit is further configured to:
store the first task in the first queue (col. 21, ll. 4-15 en-queuing a first job on a first queue); and
based on storing the first task in the first queue, add the information for the first task to the second queue (col. 21, ll. 4-15 en-queuing a first job on a first queue, the first job including the second set of events; wherein the en-queuing the first job on the first queue causes a first worker process to execute the first lambda and process the second set events; after the second set of events are successfully processed by the first lambda, en-queuing a second job on a second queue, the second job including the second set of events; and wherein a second worker process pulls the second job from a second queue and processes the second set of events) and modify the first queue (col. 21, ll. 4-15 en-queuing a first job on a first queue).
Senapaty and Munshi are both concerned with event processing and queues in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Munshi in view of Neiman in view of Rafique in view of Senapaty because it would provide a way of using multiple job queues to decrease event processing latency even in the case where a job queue does not unexpectedly fail or crash. By en-queuing jobs for lambdas onto jobs queues in datacenters where the lambdas execute, lambdas can pull jobs from the job queues without requiring a large amount of inter-datacenter network traffic. This in turn allows events to be processed with lower latency without straining the limits of the network of the system.
As per claim 14, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
Claims 5-7 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Munshi in view of Neiman in view of Rafique in view of Memon et al. (US 11,169,843) (hereinafter Memon).
As per claim 5, Munshi does not explicitly teach wherein the processing circuit is further configured to:
transmit, to the first compute function, second information associated with a first location in the memory storing a first input, wherein the first compute function is configured to retrieve the first input from the first location for performing a first computation, wherein the first compute function is configured to generate a first output based on the first computation and store the first output in a second location of the memory.
However, Memon teaches wherein the processing circuit is further configured to:
transmit, to the first compute function, second information associated with a first location in the memory storing a first input, wherein the first compute function is configured to retrieve the first input from the first location for performing a first computation (col. 13, ll. 51-56 the input to the first compute function is determined to be the output from the second compute function by determining that a memory location to which the second compute function writes is the same memory location from which the first compute function reads), wherein the first compute function is configured to generate a first output based on the first computation and store the first output in a second location of the memory (col. 15, ll. 65 to col. 16, ll. 4 the input to the first compute function is determined to be the output from the second compute function by pre-fetching the at least one kernel, applying test data to the first and second compute functions, and determining that a memory location to which the second compute function writes is the same memory location from which the first compute function reads).
Memon and Munshi are both concerned with compute functions/kernels and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Munshi in view of Neiman in view of Rafique in view of Memon because it would provide a way to the extent that a single kernel can be decomposed into separate sub-sections, for the sub-sections could be assigned to different co-processors for either parallel (if no data dependency) or serial (with data dependency) computation, where each co-processor is chosen to increase the overall efficiency (such as minimum completion time) of the execution of the kernel.
As per claim 6, Memon teaches wherein the processing circuit is further configured to: transmit third information associated with the second location to the second compute function, wherein the second compute function is configured to retrieve data stored in the second location as a second input to the second compute function for performing a second computation (col. 13, ll. 51-56 the input to the first compute function is determined to be the output from the second compute function by determining that a memory location to which the second compute function writes is the same memory location from which the first compute function reads), wherein the second compute function is configured to generate a second output based on the second computation and store the second output in a third location of the memory (col. 15, ll. 65 to col. 16, ll. 4 the input to the first compute function is determined to be the output from the second compute function by pre-fetching the at least one kernel, applying test data to the first and second compute functions, and determining that a memory location to which the second compute function writes is the same memory location from which the first compute function reads).
As per claim 7, Munshi further teaches wherein communication with the first compute function for transmitting the second information is via a stream connection ([0049] and [0060] a dependency condition may be based on relationships between input streams fed by output streams, and a dependency condition between execution instances according to input streams and output streams of the corresponding functions for the execution instances can be detected).
As per claim 15, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
As per claim 16, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
As per claim 17, it has similar limitations as claim 7 and is therefore rejected using the same rationale.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Munshi in view of Neiman in view of Rafique in view of Memon in view of Cerny et al. (US 11,080,814) (hereinafter Cerny).
As per claim 8, Munshi in view of Neiman in view of Rafique in view of Memon do not explicitly teach wherein the second information is included in a packet based on a set packet format.
However, Cerny teaches wherein the second information is included in a packet based on a set packet format (col. 16, ll. 1-11 rendering command buffers contain commands of various types that specify the location and format of a render target and commands to execute compute kernels).
Cerny and Munshi are both concerned with compute kernels and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Munshi in view of Neiman in view of Rafique in view of Memon in view of Cerny because it would provide for limits to the performance that an individual GPU can attain, e.g. deriving from the limits on how large the GPU can be. Responsibility for rendering is divided between a plurality of the GPUs based on screen regions. Prior to rendering the geometry, the GPUs generate information regarding the geometry and its relation to the screen regions. This allows the GPUs to more efficiently render the geometry or avoid rendering it altogether. As an advantage, for example this allows the multiple GPUs to render more complex scenes and/or images in the same amount of time.
As per claim 18, it has similar limitations as claim 8 and is therefore rejected using the same rationale.
Response to Arguments
Applicant's arguments regarding the 35 U.S.C. 102/103 prior art rejections have been considered but are moot in view of the new grounds of rejection necessitated by Applicant’s amendments because the new grounds of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Munshi et al. (US 2020/0250005) disclose data parallel computing on multiple processors.
Munshi et al. (US 2011/0285729) disclose sub-buffer objects.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Adam Lee whose telephone number is (571) 270-3369. The examiner can normally be reached on M-TH 8AM-5PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Pierre Vital can be reached on 571-272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/Adam Lee/Primary Examiner, Art Unit 2198 April 17, 2026
Prosecution Insights