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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Rejections - 35 USC § 112
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 2-7 and 12-17 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 pre-AIA the applicant regards as the invention.
Regarding claims 2 and 12, are indefinite because “the task” lacks sufficient antecedes basis, the claim recites “corresponding types of tasks”, but does not clearly introduce the singular task referred as “the task”.
Regarding claims 5 and 15, are indefinite because “the acceleration device” lacks clear antecedes basis, claims 1 and 11 introduce a plurality of acceleration devices and a singular target acceleration device, but it does not introduce a singular non target “acceleration device”.
Regarding claims 6 and 15, are indefinite because “the required or requested computing resource” lacks clear antecedes basis, the claims introduces different computing resources required or requested, but does not identify which singular resource is reference.
Regarding claims 7 and 17, are indefinite because “the acceleration device” lacks clear antecedes basis, claims 1 and 11 introduce a plurality of acceleration devices and a singular target acceleration device, but it does not introduce a singular non target “acceleration device”.
Regarding claims 3-4 and 13-14 dependent claims inherit the deficiencies of the respective parent claim.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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, 5, 8, 11, 15, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Muthiah (20240086106 ) in view of Shin (US 20220237040 A1).
Regarding claim 1, Muthiah teaches:
A method, comprising: (Claim 17. A method implemented using one or more controllers for one or more storage devices, the method comprising:)
determining, by a system comprising at least one processor, a target task to be assigned to acceleration devices of a storage system, the acceleration devices being configured to handle types of tasks. ([0032] In some aspects, the storage device 100 may include an accelerator QPD 208 for a die or plane and use that queue to submit die level compute tasks associated with one or more accelerators that reside in storage SoC as clients. [0047] In step 302, the controller 101 may receive an accelerator command, via a first accelerator interface of the one or more accelerator interfaces.[0048] In step 304, the controller 101 may identify a first memory of the one or more memories corresponding to a task for the accelerator command. If there is only one queue for an accelerator, then any commands from that accelerator will always go to that queue, and thus this identification step may not be needed.[0049] In step 306, the controller 101 may enqueue the task to a first queue corresponding to the first memory. The first queue may be configured to queue one or more tasks associated with the first accelerator corresponding to the first accelerator interface.)
determining corresponding computing resources required or requested to perform corresponding task queues of the acceleration devices. ([0045] At least one queue (e.g., the queue 208) is configured to queue one or more tasks associated with an accelerator of the one or more accelerators. Each queue (e.g., 202, 204, 206 or 208) of the one or more sets of queues may be associated with a respective priority level of a plurality of priority levels.; see also [0051-0056; claims 5-10)
Muthiah does not appear to explicitly teach: based on the computing resources for the corresponding task queues, selecting a target acceleration device from the acceleration devices; and assigning the target task to the target acceleration device.
However, Shim teaches: [0131] In operation 530, when the task request is received, the processor 200 obtains information on a current resource utilization status of the accelerator cluster 400 including a plurality of accelerators. For example, the processor 200 may obtain information on another task being executed in the accelerator cluster 400 and information on idle resources of the accelerator cluster 400, in response to the task request.[0132] The processor 200 may obtain the information on the current resource utilization status by performing a peer discovery between the accelerators.[0133] In operation 550, the processor 200 allocates accelerator resources for performing the task based on a utility of such a resource allocation that is based on the resource scheduling policy and the information on the current resource utilization status. The processor 200 may estimate the utility based on the resource scheduling policy and the information on the current resource utilization status.[0134] For example, the processor 200 may estimate a utility in a case of an additional allocation of accelerator resources to the task based on the resource scheduling policy and the information on the current resource utilization status. In another example, the processor 200 may estimate a utility in a case of a return of an accelerator resource by determining whether the task continues when the accelerator resource is returned, based on the resource scheduling policy and the information on the current resource utilization status.[0135] The processor 200 may perform the task by allocating a target accelerator which is at least a portion of the accelerators based on the estimated utility. The processor 200 may determine the target accelerator from among the accelerators based on the utility. The processor 200 may allocate, to the target accelerator, metadata for performing the task.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Muthiah and Shim before them, to include Shim’s utilization based target accelerator selection in Muthiah’s accelerator queue storage system. One would have been motivated to make such a combination to more efficiently assign queued task based on current accelerator utilization and avalible resources, thereby improving resource utilization and task processing efficiency as taught by Shim [0131-0135].
Regarding claim 5, Shim teaches:
The method of claim 1, wherein selecting the target acceleration device comprises: selecting the acceleration device with a lowest computing resource among the acceleration devices as the target acceleration device. ([0060] When the task request is received, the processor 200 may obtain information on the current accelerator resource utilization status of the accelerator cluster 400 including the plurality of accelerators. When the task request is received, the processor 200 may also obtain information on another task being executed in an accelerator cluster and information on idle resources of the accelerator cluster.[0121] When task B is ended, the CPU 411 may receive information indicating that accelerator resources corresponding to the accelerators 435 through 438 change to idle resources. The CPU 411 may then request the task scheduler 450 for a resource negotiation for the idle resources. [0127] The CPU 412 may execute task B using the five accelerators 434 through 438 including the returned accelerator 434. In such a case, a target accelerator for task B may be the accelerators 434 through 438. E.N: an idle accelerator has no current load therefore has the lowest current computing resource.)
Same motivation as claim 1
Regarding claim 8, Muthiah teaches:
The method of claim 1, further comprising: receiving write data; dividing the write data into parts of data with a predetermined size; and submitting a request for a corresponding type, among the types, of tasks executed for the parts of data. ([0014] In some aspects, one or more accelerators 110 may be coupled to the controller 101. In some aspects, the one or more accelerators 110 may be integrated within the controller 101. In some aspects, the one or more accelerators 110 may be controlled by different controllers (e.g., a controller similar to but separate from the controller 101). [0019] In some aspects, the controller 101 may be configured to store data received from the host device 104 in the flash memory 103 in response to a write command from the host device 104. Further, suppose that the controller 101 receives a request to store data for this accelerator, the FTL of the controller 101 may form a logical block 212 across the dies 0 through 7. Suppose the request is to store 128 Kilobytes, the FTL of the controller 101 causes storing 32 KB in die 0, 32 KB in die 1, and so on. The FTL may access data for the accelerator from any of the dies 0 through 7. However, dies 8 through 31 do not store data for the accelerator, so there are no accelerator QPDs associated with these dies (i.e., dies 8 through 31).)
Regarding claims 11, 15, 18 and 19 recite commensurate subject matter as claims 1, 5, and 8. Therefore, they are rejected for the same reasons.
Claims 2-4, 6, 7, 12-14, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Muthiah (20240086106 ) in view of Shin (US 20220237040 A1) and further view of Bass (US 20130152099 A1).
Regarding claim 2, Muthiah does not appear to explicitly teach:
The method of claim 1, wherein determining the computing resources for the corresponding task queues comprises: based on corresponding types of tasks in a first task queue among the corresponding task queues, determining the corresponding computing resources required or requested to perform the tasks; based on the corresponding computing resources for the tasks, determining a first computing resource required or requested to perform the first task queue; and based on the first computing resource for the first task queue, determining the corresponding computing resources for the corresponding task queues.
However, Bass teaches: [0026] With reference to a first embodiment, FIG. 1 shows a Queue Controller 102 and a plurality of queues 104, 105 and 106 for enqueuing jobs received from Job Requestor 101 and dispatching the jobs from the heads of the queues to hardware acceleration engines 107, 108 and 109, which may include different methods of encryption (RSA, AES), compression/decompression, or data analytics. A person of skill in the art will appreciate that many types of hardware accelerator engines could be employed using embodiments of the present invention and are not limited to the type shown in FIG. 7. FIG. 1 shows one queue (Q1, Q2 . . . Qn) for each type of hardware acceleration engine 107, 108 and 109. [0027] A queue comprises one or more queue positions ("position") in memory arranged in first-in-first-out stack order, wherein the depth of the stack is variable. Queue positions are shown in FIG. 1 as rectangular boxes representing empty positions, floating entries or dedicated positions. A position corresponds to the place in the order of the total number of queue entries allocated to a particular acceleration engine and is either empty or full. A full position has a queue entry ("entry") with a job allocated to it; an empty position does not. [0040] If the JobType matches a dedicated hardware accelerator for a specific Q, step 302 continues to step 303 which ascertains whether Q.Head is already allocated. If it is not, then the incoming job may be enqueued in this QE in step 307 and in this instance Q.Head =Q.Tail. If it is already allocated, then step 304 determines whether any unallocated, i.e., floating, QEs exist. If no floating entries are available, the job is rejected in step 309. If at least one unallocated QE exists, step 305 determines whether Q.Limit has been met; if it has then the job is rejected in step 309. If Q.Limit has not been met, then step 306 enqueues QE at the tail of Q. In boxes 306 and 307, the notation QE.JobInfo<-JobDescriptor means fields from the JobDescriptor the hardware accelerator requires to perform the job are copied from the JobDescriptor to the QE.JobInfo register. Such fields may comprise operation code, operand addresses, unique job identifier, job priority, etc. [0041] FIG. 4 describes the QC action of dispatching a job from a queue to an attached accelerator. It will be appreciated by one skilled in the art that an interface (not shown) between QC and the attached accelerator is implemented where:[0042] The accelerator can signal to QC that it may accept another job by asserting the JobComplete signal.[0043] The QC may dispatch JobInfo from Q.Head to the accelerator simultaneously asserting a JobValid signal to the accelerator.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Muthiah and Bass before them, to include Bass’s type specific queues and dynamic queue allocation in Muthiah’s accelerator queue storage system. One would have been motivated to make such a combination to more efficiently allocate resources according to types of queue task, thereby improving accelerator dispatch efficiency, as taught by Bass [0026-0027]-[0040-0043]
Regarding claim 3, Bass teaches:
The method of claim 2, further comprising: in response to a first task being added to a second task queue among the corresponding task queues, determining a third computing resource required or requested to perform the first task based on a first task type of the first task; and updating a second computing resource required or requested to perform the second task queue by adding the third computing resource. ([0026] With reference to a first embodiment, FIG. 1 shows a Queue Controller 102 and a plurality of queues 104, 105 and 106 for enqueuing jobs received from Job Requestor 101 and dispatching the jobs from the heads of the queues to hardware acceleration engines 107, 108 and 109, which may include different methods of encryption (RSA, AES), compression/decompression, or data analytics. A person of skill in the art will appreciate that many types of hardware accelerator engines could be employed using embodiments of the present invention and are not limited to the type shown in FIG. 7. FIG. 1 shows one queue (Q1, Q2 . . . Qn) for each type of hardware acceleration engine 107, 108 and 109. [0036] FIGS. 3-5 describe the operation of the Queue Controller (QC) with respect to the following events: 1. assignment of a Queue Entry (QE) to particular Queue, i.e., enqueing a job; 2. Job Completion and Job Dispatch; and 3. Job Termination ("JobKill"). The QC receives jobs from a Job Requestor and controls a plurality of Queue Entries (QE) by dynamically assigning Queue Entries to one of several queues. The QC dispatches jobs from the queues to hardware accelerators attached to the queues and is able to terminate jobs identified by the Job Requestor. A particular queue is referred to as Qn. A QE may be implemented with a series of registers in hardware named and defined as follows:)
Same motivation as claim 3
Regarding claim 4, Bass teaches:
The method of claim 3, further comprising: in response to a second task being removed from the second task queue, determining a fourth computing resource required or requested to perform the second task based on a second task type of the second task; and updating the second computing resource for the second task queue by subtracting the fourth computing resource from the second computing resource for the second task queue. ([0028] Entries advance by one queue position as jobs are dequeued and dispatched from the head position. In this manner an entry is emptied and becomes available to receive a new job from the Queue Controller. In a queue with a single position or in an empty queue, the tail position is the same as the head position. [0031] Job Requestor 101 may at any time request that one or more jobs associated with a particular identifier be removed from any and all of the queues, in any and all queue positions. This operation is called a "kill " Queue entries associated with killed jobs are emptied and become available to receive another job. Queue Controller 102 includes logic to interrogate this identifier in all allocated entries and remove entries with matching identifiers from the queues. [0032] Queue Controller 102 decides whether to accept a job from the Job Requestor for a given queue. To do so, it examines the job type, i.e., which type of hardware acceleration engine it requires, to choose the correct queue from the plurality of queues. If the entry dedicated to the head position of the destination queue is empty, the job is accepted and the entry at the head is filled with the job. If the entry at the head is full, the Queue Controller checks if the number of entries allocated to the queue is less than the limit and that a floating entry is available. If both of these conditions are true, the job is accepted, a floating entry is filled with the job and allocated to the tail of the queue. Otherwise, the job is rejected.)
Same motivation as claim 3
Regarding claim 6, Bass teaches:
The method of claim 1, further comprising: determining different computing resources required or requested to perform the types of tasks; and determining a resource weight of each type, among the types of tasks, based on ratios between the different computing resources, the resource weight characterizing the required or requested computing resource. ([0032] Queue Controller 102 decides whether to accept a job from the Job Requestor for a given queue. To do so, it examines the job type, i.e., which type of hardware acceleration engine it requires, to choose the correct queue from the plurality of queues. If the entry dedicated to the head position of the destination queue is empty, the job is accepted and the entry at the head is filled with the job. If the entry at the head is full, the Queue Controller checks if the number of entries allocated to the queue is less than the limit and that a floating entry is available. If both of these conditions are true, the job is accepted, a floating entry is filled with the job and allocated to the tail of the queue. Otherwise, the job is rejected. [0040] If the JobType matches a dedicated hardware accelerator for a specific Q, step 302 continues to step 303 which ascertains whether Q.Head is already allocated. If it is not, then the incoming job may be enqueued in this QE in step 307 and in this instance Q.Head =Q.Tail. If it is already allocated, then step 304 determines whether any unallocated, i.e., floating, QEs exist. If no floating entries are available, the job is rejected in step 309. If at least one unallocated QE exists, step 305 determines whether Q.Limit has been met; if it has then the job is rejected in step 309. If Q.Limit has not been met, then step 306 enqueues QE at the tail of Q. In boxes 306 and 307, the notation QE.JobInfo<-JobDescriptor means fields from the JobDescriptor the hardware accelerator requires to perform the job are copied from the JobDescriptor to the QE.JobInfo register. Such fields may comprise operation code, operand addresses, unique job identifier, job priority, etc.)
Same motivation as claim 3
Regarding claim 7, Muthiah teaches:
The method of claim 6, wherein determining the different computing resources comprises: determining reference bandwidths required or requested when the acceleration device performs the types of tasks using a same resource; determining corresponding sizes of the types of tasks; and determining the different computing resources based on the corresponding sizes and the reference bandwidths. ( [0033] In some aspects, the controller 101 may dynamically modify the priority of the accelerator QPD 208 of any die based on accelerator data bandwidth requirement and the state machine of the storage functions. For example, two accelerators, one performing object analysis on video frame at one frequency and another performing post processing of frames at another frequency would need different data bandwidth and may have different accelerator QPDs operating at different priorities. That is, the controller 101 may define multiple priority for one or more QPD per die associated with different accelerators based on pre-agreed compute requirements. [0036] In some aspects, the controller 101 may set priorities dynamically for accelerator QPDs 208 based on at least one of the following: (i) accelerator data bandwidth requirements, (ii) multiple priorities for multiple accelerator QPD in a die based on requesting client(s), (iii) storage state machine, such as failure, urgent relocation, and (iv) device power and thermal states when storage to compute ratio requirement changes. In some aspects, the controller 101 may determine the bandwidth requirements based on polling the accelerators 110 and/or the accelerators 110 may provide the controller 101 with the requirements ahead of compute operations. Different types of data or compute operations may require different data bandwidth; this may be the case even for same data in the memory 103. Different accelerator tasks may have different timing requirements for accessing data. Moreover, the amount of data accessed may be limited (e.g., only a few kilobytes) but accessing the data in a timely manner may be required. One accelerator may be performing a video processing operation and another may be processing data for machine learning operations.)
Regarding claims 12-17 recite commensurate subject matter as claims 2-7. Therefore, they are rejected for the same reasons.
Claims 9-10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Muthiah (20240086106 ) in view of Shin (US 20220237040 A1) and further view of Chen (US 20210373926 A1).
Regarding claim 9, Muthiah does not appear to explicitly teach:
The method of claim 8, wherein the types of tasks comprise at least two of an encryption task, a decryption task, a compression task, a decompression task, or a hashing task.
However, Chen teaches: [0021] Accelerator resource 110 may include one or more accelerator devices, such as accelerator devices 111-113 shown in FIG. 1. Accelerator resource 110 may act as a co-processor of storage system 100 so as to alleviate some processing tasks of a general-purpose processor (not shown). Accelerator resource 110 can realize accelerated operations for certain specific functions and operations, and can achieve higher execution efficiency than the general-purpose processor does. In some embodiments, accelerator resource 110 may be one or more QAT cards, which may accelerate the encryption and/or decryption of data, and may also accelerate the compression and/or decompression of data. It should be understood that although QAT cards are used as an example of the accelerator resource in some embodiments of the present disclosure, the accelerator resource may also be other hardware processing devices with an acceleration function for specific tasks (such as encryption, decryption, compression, and matrix operations).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Muthiah and Chen before them, to include Chens’s accelerators capable of encryption, decryption, compression. One would have been motivated to make such a combination to more efficiently perform computational storage operations that are suited for hardware acceleration.
Regarding claim 10, Chen teaches:
The method of claim 1, wherein the acceleration devices each comprise a Quick Assist Technology (QAT) device. ([0019] As mentioned above, accelerator technologies such as the QAT technology have been widely used in various systems, such as a storage system with deduplication applications. Such systems are usually built based on virtualization technologies. So, how to deploy and utilize accelerator resources in a virtualized environment becomes an important issue.)
Same motivation as claim 9
Regarding claim 20, the claim recites similar limitation as corresponding claim 9 and is rejected for similar reasons as claim 9 using similar teachings and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m 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, LEWIS BULLOCK JR can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights