DETAILED ACTION
Claims 1, 11, 15 are amended. Claims 4,18,22 are canceled. Claims 7-8 were previously canceled. Claims 1-3, 5-6, 9-17, 9-21 are pending.
Priority: 6/3/2022
Assignee: Micron
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 .
Claim objections
1.Claims 12-14 are objected to for a typo.
Independent claim 11 is directed to ‘A computer-readable non-transitory storage medium’. Dependent claims 12-14 do the same. But claims 12-14 have a typo, as they recite, ‘The computer-readable non-transitory storage medium of claim 1’. They must recite, ‘…..medium of claim 11’.
Note: An objection for a typographical error can be issued at any point during patent prosecution, including a Final O/A. See MPEP 608.01(i)
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.
Claim(s) 1-3, 5-6, 9-17, 9-21 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.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
1.Amended Claims 1,11,15 are rejected for reciting a limitation that is unclear, ambiguous and indefinite.
Amended Claim 1 recites, ‘….the controller to perform operations comprising: maintaining a plurality of processing threads for the plurality of memory access command queues’.
The spec does not recite this limitation. Para-0067 of the spec recites, ‘several processing threads can be supported for every memory access command queue 440’.
In addition to the inconsistency with the spec, the limitation is ambiguous, and the ambiguity lies in the mapping between the threads and queues.
It is unclear if there is a dedicated thread for every queue or if a single thread can sequentially service multiple queues. It is unclear if the threads act as a pool that pulls commands from any of the queues.
Since the claim recites maintaining ‘threads’, it implies the parallel processing of commands. Here the ambiguity lies in whether these threads process commands simultaneously and independently, or if they are synchronized under a specific execution hierarchy.
Since the threading architecture is undisclosed, the claim fails to describe how the commands are dequeued, prioritized, and executed. Hence the scope of claim 1 is indefinite.
Because the spec discloses maintaining the queues only by the controller (see Para-0069), and processing the commands only by the controller (see Para-0021), the spec fails to provide the boundaries and structure for how the threads interact with the controller, further rendering the scope of the claim indefinite. Hence claim 1 is rejected. Claims 11,15 have the same issue.
2.Amended Claims 1,11,15 are rejected for reciting a limitation that is unclear, misleading and indefinite.
Claim 1 recites, ‘….the controller to….: maintaining a plurality of processing threads for the plurality of memory access command queues, wherein each processing thread ….is utilized to service memory access commands directed to a respective memory device of the plurality of memory devices’.
The limitation is unrecited in the spec and cannot be inherently derived from the original disclosure.
In Para-0069, the spec explicitly recites, ‘The controller can maintain multiple memory access command queues’. Because the spec only discloses maintaining the queues, the spec fails to provide the boundaries and structure for how the threads interact with the controller, rendering the scope of the claim indefinite.
In order to ‘maintain’ the processing threads, the controller must be able to perform (or be aware of) thread ID/identifier, assignment, scheduling and thread tracking. Since the controller does not participate in any thread-based functions, it is unclear how the controller determines and maintains the mapping/association between the threads and the queues.
Since the controller does not track the threads, it is unclear how the controller identifies each processing thread. Accordingly it is unclear how the controller maps each thread to a respective memory device. Therefore it is unclear how ‘each processing thread is utilized to service commands directed to a respective memory device’, as recited in claim 1. Hence the scope of the limitation is uncertain and claim 1 is indefinite. Claims 11,15 have the same issue.
Note: This issue was mentioned in previous O/A. But neither the amendment nor the arguments resolve the issue. Hence the rejection has been clarified and maintained.
3.Amended Claims 1,11,15 are rejected for reciting a limitation that is unclear, misleading, and indefinite.
Claim 1 recites, ‘processing the memory access command by a first processing thread of the plurality of processing threads based on the memory access command being directed to a first memory device associated with the first processing thread’.
The limitation is unrecited in the spec and cannot be inherently derived from the original disclosure.
In Para-0021, the spec explicitly recites, ‘…sub-system controller (“controller”) can implement a scheduling algorithm for processing memory access commands’. Because the spec only discloses processing the commands by the controller, the spec fails to provide the boundaries and structure for how the threads interact with the controller, commands and the devices, rendering the scope of the claim indefinite.
As explained above, the spec does not disclose how the controller identifies each thread, or how it performs the thread to device mapping. Therefore the limitation, ‘….based on the memory access command being directed to a first memory device associated with the first processing thread’, being unclear, is indefinite.
Claim 1 recites a M:N mapping between threads and queues and Para-0067 of the spec recites that multiple threads process commands simultaneously to maintain device-specific ordering while allowing arbitrary out-of-order execution across devices. Based on the parallel processing and since the controller has no knowledge of the threads, it is unclear how ‘a first processing thread’ is identified, as required in claim 1. Given the ambiguous thread to queue mapping, it is also unclear how ‘a first processing thread’ is associated with the queue that provides the command.
Since the controller has no knowledge of the threads, it is unclear how the controller maps the association between ‘a first processing thread’ and ‘a first memory device’ to guide the command to ‘a first memory device’.
Furthermore, device identification and verification limitations have been canceled in claim 1. Accordingly, ‘a first memory device’ cannot be identified and the command cannot be directed to ‘a first memory device’.
In summary, the limitation, ‘the controller to perform….processing the memory access command by a first processing thread….directed to a first memory device….’, presents an unclear scope rendering the limitation a hypothetical function.
Accordingly claim 1 is rejected for reciting a limitation that is unclear, misleading and indefinite. Claims 11,15 have the same issue.
Note: This issue was mentioned in previous O/A. But neither the amendment nor the arguments resolve the issue. Hence the rejection has been clarified and maintained.
4.Amended Claims 1,11,15 are rejected for omitting a limitation thereby making controller functions unclear, inconsistent and indefinite.
Amended Claim 1 canceled device verification step, ‘verifying availability of the first memory device’., performed by the controller, and recited in spec, Fig. 5, step 530.
The spec does not indicate that Fig. 5, step 530, Memory device available?, can be optional or an excluded step. The cancellation misrepresents recited controller functions and presents an unclear scope.
Hence claim 1 is rejected for reciting a limitation that is indefinite. Claims 11,15 have the same issue. No valid reason has been provided for the cancellation. For examination, the spec is followed.
Note: Previous step 520 is also canceled. The spec also does not indicate that the previous step, Fig. 5, step 520, Identify memory device, can be optional or an excluded step. No valid reason has been provided for the cancellation. The cancellation invalidates the Fig. 5 controller functions.
This issue was previously mentioned. Since neither the amendment nor the arguments resolve the issue, the rejection has been maintained.
5.Claim 4 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 4 recites, ‘responsive to failing to validate availability of the memory device, leaving the ….command in the command queue’.
As mentioned above, device verification performed by the controller before preforming resource availability check, has been canceled. Since the withdrawn step has lost its place in the workflow/algorithm, it is unclear when the verification is performed.
Hence claim 4 is rejected for reciting a limitation that is unclear, inconsistent and indefinite. For examination, the spec is followed.
Note: This issue was previously mentioned. Since neither the amendment nor the arguments resolve the issue, the rejection has been maintained.
6.Amended Claims 1,11,15 are rejected for omitting a limitation thereby making controller functions unclear, inconsistent and indefinite.
Claim 1 recites, ‘responsive to determining that the memory access command fits the predefined power budget, transmitting the command to the first memory device’.
The spec does not recite transmitting the command to the device after predefined power budget verification or Fig. 5, step 540.
The spec recites next step 550, and Para-0073 of the spec recites, ‘At operation 550, the controller verifies availability of one or more hardware modules….. If the verification succeeds, then the command is transmitted to the memory device.
The spec does not recite that step 550 is an optional step. The cancellation invalidates claimed controller functions and invalidates the disclosure.
Therefore, transmitting the command to the first memory device after verification of the controller resource (power budget), and omitting the hardware module verification, is inconsistent with the spec. Claims 11, 15 have a similar issue. For examination, the spec is followed.
Note: This issue was previously mentioned. Since neither the amendment nor the arguments resolve the issue, the rejection has been maintained.
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-3, 5, 9, 11-13, 15-17, 19-21 are rejected under AIA 35 U.S.C. 103 as being unpatentable over La Fratta et al (20190121545) in view of Brewer (20190340022), Vainer et al (20220100562), and Dobelstein et al (20170285988).
As per Claim 1, La Fratta discloses a system (La Fratta, [0018 - Fig. 1 shows a computing system including memory system 120 and capable of implementing a command selection policy]; [0019 – In Fig. 1, the computing system includes host 102 coupled to controller 104 via interface 103, which is coupled to memory system 120 via an interface 105]), comprising:
a plurality of memory devices (La Fratta, [0019 – In Fig. 1, memory system 120 includes memory devices 110-1, 110-2,…,110-N, referred to as memory 110]);
a controller (La Fratta, [Fig. 1: controller 104]; [Fig. 2: controller 204]) coupled to the plurality of memory device (La Fratta, [0019 – In Fig. 1, controller 104 is coupled to memory system 120 via an interface 105. Memory system 120 includes memory devices 110-1, 110-2,…,110-N]; [0020 – As per Fig. 1, controller 104 transfers commands and/or data between host 102 and memory system 120]), the controller to perform operations (La Fratta, [0037 - Figs. 3A-3B: command selection operations, comparison operations]) comprising:
maintaining a plurality of memory access command queues (La Fratta, [0024 – Fig. 2: a plurality of prioritized queues 248-0(Q0), 248-1(Q1), 248-2(Q2),….248-(k−1)(Qk−1)]);
retrieving a memory access command from a memory access command queue (La, Fratta, [Figs. 1-2: a command selection policy]) of the plurality of memory access command queues (La Fratta, [0011 - In the FRFCFS policy, the memory controller iterates through the command queue and selects the first command it encounters that is ready to be issued]; [0026 – In Fig. 2, prioritization logic 244 iterates through the plurality of queues 248 to select a command]),
determining whether the memory access command fits a predefined power budget specifying the amount of power to be spent within a certain time (La Fratta, [0024 – In Fig. 2, command selection logic 240 includes prioritized queues, timing parameter logic 242, and prioritization logic 244 to implement a command selection policy]; [0025 - Timing parameter logic 242 tracks various timing constraints associated with accessing a memory device by a command, thereby implying an association with the power spent within a certain time or a predetermined power budget]; [0010 - Timing constraints affect whether a command can be issued from controller to the memory device. For example, various support circuitry associated with a memory device include timing constraints that determine when a particular command is ready for execution by the memory device, thereby implying determining a ‘predetermined power budget’ for the command because circuitry/transistors activity and time are associated with power/energy; Power consumption of command is chip-dependent and device dependent. Since neither the spec nor the claim recite how the ‘predetermined power budget’ for a command is determined, the citation is a valid interpretation]);
responsive to determining that the memory access command fits the predefined power budget (La Fratta, [0040 – In Fig. 3B, responsive to determining that the ‘jth’ command is not directed to a same row as an older write command, at step 389 it is determined whether the ‘jth’ command is ready to issue. Whether the controller determines a particular command to be issuable or not depends on timing parameters associated with a memory device, thereby implying that the command fits the predetermined power budget]),
transmitting the memory access command to the first memory device (La Fratta, [0026 - In Fig. 2, arrow 247 represents a selected command sent/transmitted to the memory device]; [0040 – In Fig. 3B, if the ‘jth’ command is determined to be ready, implying predetermined power budget verification, then at step 396 the command is issued to the first memory device]);
removing the memory access command from the memory access command queue (La Fratta, [0026 – In Fig. 2, arrow 235 represents control signals associated with command selection logic 240 iterating through commands 232 and removing commands 232 from queue 230 once they have been issued to the memory device, thereby implying removing the memory access command from the memory access command queue]).
The claim does not recite how the controller maintains threads or queue-to-thread mapping or thread-to-device assignment is achieved.
Brewer discloses,
maintaining a plurality of processing threads (Brewer, [0131 - Fig. 8 shows HTP 300/Hybrid Threading Processor. The core control circuit 310 comprises control logic and thread selection circuitry 330 and network interface circuitry 335]; [0141 - HTP 300 generates calls to create threads on local or remote compute elements. Such calls are also created as outgoing work descriptor packets]; [0132 - When a work descriptor packet arrives, the control logic and thread selection circuitry 330 assigns an available thread ID to the thread of the word descriptor packet, from the thread ID pool registers 322, with the assigned thread ID used as an index to the other registers of the thread memory 320 which are then populated with corresponding data from the work descriptor packet, thereby implying that work descriptor packet has the information for the controller about the respective threads which can be associated with the respective devices for storage operations]) for the plurality of memory access command queues (Brewer, [0127 – In Fig. 8, the execution queue 345 is provided with different levels of priority, as a first priority queue 355 and a second lower priority queue 360, with execution of the threads in the first priority queue 355 occurring more frequently than the execution of the threads in the second lower priority queue 360, thereby implying maintaining a plurality of threads for a plurality of command queues]);
wherein each processing thread of the plurality of processing threads is utilized to service memory access commands (Brewer, [0254 - Fig. 11 shows the first interconnection network 150 and representative data/work descriptor packets]; [Figs. 9A-9B]; [0138 – Fig. 9A starts at step 400, upon reception of a work descriptor packet. The work descriptor packet is decoded, in step 402, and the various registers of thread memory 320 is populated with the information received in the work descriptor packet, initializing a context block, in step 404. When a thread ID is available, in step 406, a thread ID is assigned, in step 408, thereby continuing to perform all steps in Fig. 9A-9B]) directed to a respective memory device of the plurality of memory devices (Brewer, [0136,0137 - When a r/w packet is received by controller 120 for memory 125 and decoded, the thread ID of the thread which made the request is obtained; This implies that the memory request directed to the corresponding target device which is handled by the controller, has the thread information which can be used by the controller to associate each thread with the target device]; [0172 - When a buffer is written to the memory controller 120, then the thread is suspended until a completion is received in order to ensure memory 125 consistency, thereby implying that the thread information shared between the HTP with the controller via the work descriptor data packet for a target memory device discloses how each processing thread is utilized to service memory access commands directed to that memory device]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the Hybrid Threading Processor of Brewer into the command selection policy of La Fratta, for the benefit of a core control circuit adapted to automatically schedule an instruction for execution by the processor core in response to a received work descriptor data packet (Brewer, 0014).
Vainer discloses ‘processing threads’ or ‘threads’ and further clarifies command processing by the thread based on thread to memory device assignment as follows,
processing the memory access command (Vainer, [0043 – In Fig. 2, command request 220.1 is assigned to thread 202.1]) by a first processing thread (Vainer, [0108 – In Fig. 8, step 820, each processing thread selects commands from their corresponding queue according to the priority, selection logic, and processing resources of that processing thread]; [Fig. 8: step 820, queue command requests for processing in each thread]; [0013 - Each thread from the plurality of threads has a different associated pool of command identifiers, and means for returning, upon completion of the first command, the first command identifier to the first pool of command identifiers, thereby implying processing the memory access command by the first thread]) of the plurality of processing threads (Vainer, [Fig. 2: threads 202.1-202.3]; [Claim 1 - Receive a first command request for initiating a first command for a first thread selected from a plurality of threads]) based on the memory access command being directed to a first memory device associated with the first processing thread (Vainer, [Fig. 2 shows how the thread identifier for each request is included in the request sent to the controller, and then used/extracted by the controller to associate the thread to the target memory device, as described in Fig. 8]; [Fig. 8: step 822, Execute commands against target memory device]; [0043 - As each command request is received, it is assigned to one of threads 202 for processing. So command request 220.1 is assigned to thread 202.1, command request 220.2 is assigned to thread 202.2, and command request 220.3 is assigned to thread 202.3; Since each command request identifies a target memory device, the above assignment between the command request and a thread discloses the mapping/association between the target memory device and the thread. This further implies that the memory access command is directed to a first memory device associated with the first processing thread]);
La Fratta, Brewer recite the command queue, threads, devices assignment. Vainer further clarifies the assignment. Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the pool system of Vainer into the command selection policy of La Fratta, Brewer for the benefit of using the allocated command identifier pool system which is implemented in a storage system for more reliably and efficiently handling storage commands in a threaded system to reduce latency in the command identifier assignment operation (Vainer, 0040).
Dobelstein clarifies the predefined power budget as follows,
determining whether the memory access command fits a predefined power budget specifying the amount of power to be spent within a certain time (Dobelstein, [0027 – In Fig. 1B, controller 140 controls an amount of power available to banks or subarrays by controlling a number of banks or subarrays that can perform an operation/command at a given time or within a given timeframe, thereby implying a predefined power budget. The claim does not define ‘predefined’. Also in Para-0072, the spec recites ‘memory access operation’]; [0077 – In Fig. 3, power budget register 347 acts as a shared register and controls banks 321 or subarrays 325, 326, 327 that perform concurrent operations at a given time or within a given time period]; [0028 – In Fig. 1B, controller 140 communicates with a bank arbiter and power budget register to allow only a certain number of subarrays or banks to be accessed to perform a memory operation within a certain timeframe]);
responsive to determining that the memory access command fits a predefined power budget (Dobelstein, [0058 – In Fig. 3, counter 349 is used to ensure that the power budget is not exceeded]), transmitting, the memory access command to the memory device (Dobelstein, [0057 - A channel controller 143 coupled to the bank arbiter 145-1, wherein the channel controller 143 directs a data transfer associated with at least one bank, e.g., 121-0 of the plurality of banks 121-0,….,121-N based on the threshold number of available concurrent data transfers. Host 110 is configured to control the timing of an operation/command of at least one bank, e.g., 121-0, based on a priority of the operation being performed by the one bank, 121-0, thereby implying transmitting the command/operation to the memory device]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the predefined power budget of Dobelstein into the command selection policy of La Fratta, Brewer, Vainer for the benefit of memory power coordination that includes concurrently performing a memory operation by a threshold number of memory regions and executing a command to cause a budget area to perform a power budget operation associated with the memory operation (Dobelstein, 0012).
As per Claim 2, the rejection of claim 1 is incorporated and La Fratta discloses,
wherein the memory access command (La Fratta, [Fig. 4], [0023 – In Fig. 2, received commands 232 can be categorized based on various factors including command type, e.g., read or write, command address, e.g., whether the command targets an open or closed row of the memory device, and/or command age, e.g., time since being received, among various other factors including a relationship of one command to another, e.g., a read-after-write dependence etc.]) is one of:
a read command, a write command, an erase command, or a memory device configuration command (La Fratta, [Abstract - A memory controller employs a first-ready, first-come, first-served/FRFCFS policy in which certain types of commands, e.g., read commands are prioritized over other types of commands, e.g., write commands]; [Claim 12 - Read commands of the first type are column read commands, and read commands of the second type are row read commands]; [0020 - Controller 104 receives memory transaction requests, in the form of read/load and write/store commands, from host 102]; [0010 - A FCFS policy includes scheduling commands/device configuration command received by a memory controller for execution by a memory device, e.g., a main memory such as a DRAM device, based on the order in which the commands were received/decoded by the controller; Since the claim does not define ‘device configuration command’, the citation is a valid interpretation]).
As per Claim 3, the rejection of claim 1 is incorporated and La Fratta discloses,
wherein the operations (La Fratta, [Figs. 3A-3B: command selection operations]) further comprise:
retrieving, from a predefined storage location, executable instructions (La Fratta, [0023 – In Fig. 2, controller 204/hardware decodes the incoming access requests and categorizes corresponding commands 232 in accordance with a desired command selection policy/workflow/executable instructions]; [0014 - Implementing a command selection policy that has similarities to a FRFCFS policy along with a strict read priority, and is implemented via execution of instructions stored on machine-readable media/predefined storage location, Fig. 2]) specifying a workflow for verifying availability of hardware resources for servicing memory access commands (La Fratta, [0024 – In Fig. 2, controller 204 includes command selection logic 240 used to implement a desired command selection policy/workflow. The command selection logic 240/instructions includes a plurality of prioritized queues 248-0(Q0), 248-1(Q1), 248-2(Q2),…, 248-(k−1)(Qk−1), which are referred as prioritized queues 248/hardware resources, as well as timing parameter logic 242 and prioritization logic 244 used to implement a desired command selection policy]; [0025 - The timing parameter logic 242/instructions is responsible for tracking various timing constraints associated with accessing a memory device to which commands will be issued. Such timing constraints can include constraints such as timing of various control signals, e.g., read/write enable signals, and/or address signals, e.g., row/column address signals, etc.]; [0026 - Prioritization logic 244/instructions is responsible for iterating through commands 232 in queue 230, determining designated priority categories for the received commands 232, inserting the commands 232 selected ones of the priority queues 248, and iterating through the plurality of queues 248, in order of priority, to select a particular command to issue to the memory device; Since the claim does not define ‘workflow’, and its representation, the above citation implies retrieving, from a predefined storage location, executable instructions specifying a workflow for verifying availability of resources for servicing memory access commands]).
As per Claim 5, the rejection of claim 1 is incorporated and La Fratta, Brewer, Vainer, Dobelstein disclose,
wherein the operations (Dobelstein, [0018 - operations carried out using a power budget register]) further comprise:
responsive to determining that the memory access command fails to fit the predefined power budget (Dobelstein, [0058 – In Fig. 3, counter 349 is used to ensure that the power budget is not exceeded]; [0078 - The power budget register 347 is configured such that no more than four banks can perform an operation concurrently, based on the counter 349. If five banks are ready to perform their respective operations, the power budget register 347 can deny the respective operations to the banks, thereby implying failure to fit the predefined power budget]), leaving the memory access command in the memory access command queue (Dobelstein, [0085 - Denying the operation associated with the particular bank among the plurality of banks based on the counter having a value of zero]; [0086 - Denying the operation associated with the particular subarray among the plurality of subarrays based on the threshold number associated with the counter being exceeded; Since the claim does not recite the criteria to ‘fail’, both cases, counter being zero or counter exceeding threshold are a valid interpretation of failure to fit, thereby implying leaving the command in the queue]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the predefined power budget of Dobelstein into the command selection policy of La Fratta, Brewer, Vainer for the benefit of memory power coordination that includes concurrently performing a memory operation by a threshold number of memory regions and executing a command to cause a budget area to perform a power budget operation associated with the memory operation (Dobelstein, 0012).
As per Claim 9, the rejection of claim 1 is incorporated and La Fratta discloses,
wherein the operations (La Fratta, [Figs. 3A-3B: command selection operations]) further comprise:
responsive to determining that a last memory access command has been removed from the memory access command queue, switching to a second memory access command queue having a lower priority than the memory access command queue (La Fratta, [0033 - Responsive to a determination that the highest priority queue 248-0 does not contain an issuable command, the controller 204 searches the second highest priority queue 248-1/second lower priority queue and selects the first command encountered that is determined to be issuable, thereby implying that in response to determining that a last memory access command has been removed from the memory access command queue, switching to a second memory access command queue having a lower priority than the memory access command queue; Since the claim does not define the command removal process, it is valid to interpret the highest priority queue not containing another issuable command as being equivalent to the last memory access command being removed from the memory access command queue]).
As per Claim 11, La Fratta discloses a computer-readable non-transitory storage medium comprising executable instructions (La Fratta, [0014 - Execution of instructions stored on machine-readable media, which can include non-transitory media including volatile and/or nonvolatile memory]) that, when executed by a controller (La Fratta, [Fig. 1: controller 104]; [Fig. 2: controller 204]) managing a plurality of memory devices (La Fratta, [0019 – In Fig. 1, controller 104 is coupled to memory system 120 via an interface 105. Memory system 120 includes memory devices 110-1, 110-2,…,110-N, referred to as memory 110]; [0003 - Memory cells can be arranged into arrays, with the arrays being used in memory devices]), cause the controller to perform operations (La Fratta, [0037 - Figs. 3A-3B: command selection operations, comparison operations]), comprising:
The remaining limitations are similar to claim 1 and therefore the same rejections are incorporated.
As per Claim 12, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 13, it is similar to claim 3 and therefore the same rejections are incorporated.
As per Claim 15, it is similar to claim 1 and therefore the same rejections are incorporated.
As per Claim 16, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 17, it is similar to claim 3 and therefore the same rejections are incorporated.
As per Claim 19, it is similar to claim 5 and therefore the same rejections are incorporated.
As per Claim 20, it is similar to claim 9 and therefore the same rejections are incorporated.
As per Claim 21, the rejection of claim 1 is incorporated and La Fratta discloses,
wherein the memory access command queue is a highest priority queue of a plurality of memory access command queues (La Fratta, [0027 - The prioritized queues 248 are indexed in priority order such that queue 248-0/Q0 has a highest priority]).
Claims 6, 10, 14 are rejected under AIA 35 U.S.C. 103 as being unpatentable over La Fratta et al (20190121545) in view of Brewer (20190340022), Vainer et al (20220100562), Dobelstein et al (20170285988) and Asnaashari et al (US20140310431A1).
As per Claim 6, the rejection of claim 3 is incorporated and La Fratta, Brewer, Vainer, Dobelstein disclose hardware resources.
Asnaashari further discloses,
wherein the one or more hardware resources comprise an internal memory buffer of a specified size within an internal memory of the controller (Asnaashari, [Fig. 3: main buffer 334]; [0045 – In Fig. 3, the channel DMA, e.g., 354-1,….,354-N, are coupled to a channel buffer, e.g., 358-1,….358-N]; [0090 - Fig. 9B shows an entry in the DMA Descriptor Block/DDB of Fig. 9A. Fig. 9B indicates data fields by type, e.g., set-up, status, info, description, size, and location]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the channel buffers of Asnaashari into the command selection policy of La Fratta, Brewer, Vainer, Dobelstein for the benefit of optimized processing by the controller wherein when the back end channels are busy, such as when the associated channel buffers are full, the front end portion of the controller is prevented from distributing commands to the back end channels (Asnaashari, 0061).
As per Claim 10, the rejection of claim 1 is incorporated and La Fratta discloses,
wherein the operations are performed by a data path sequencer comprised by the controller (La Fratta, [0024 - Fig. 2: controller 204]; [0026 – In Fig. 2, controller 204 comprises prioritization logic 244/sequencer which is responsible for iterating through commands 232 in queue 230, determining designated priority categories for the received commands 232, inserting the commands 232 selected ones of the priority queues 248, and iterating through the plurality of queues 248, in order of priority, to select a particular command to issue to the memory device]),
and wherein the data path sequencer is implemented by an application specific integrated circuit (ASIC) (La Fratta, [0020 – In Fig. 1, controller 104 can comprise a state machine, a sequencer, and/or some other type of control circuitry, which may be implemented in the form of an application specific integrated circuit/ASIC coupled to a printed circuit board]).
Asnaashari further clarifies the data path sequencer as follows,
wherein the operations are performed by a data path sequencer comprised by the controller (Asnaashari, [0053 – In Fig. 3, command dispatcher 318 includes a command processor portion and a dispatcher portion, which are discrete hardware modules]; [0059 - Fig. 3 shows memory system controller 310 comprising the command processor portion of the command dispatcher which can re-order/sequencer commands within a group of commands, combine/coalesce commands by grouping multiple commands into one or more commands, or determine that a particular command is not to be executed, such as when it can be determined that a subsequent command will modify data at a particular memory location, among other command optimization techniques; Since the claim does not define ‘data path sequencer’ and how it works, the citation is a valid interpretation]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the command dispatcher’s command processor portion of Asnaashari into the command selection policy of La Fratta, Brewer, Vainer, Dobelstein for the benefit of using it as a data path sequencer because it can re-order commands within a group of commands, combine commands by grouping multiple commands into one or more commands etc. (Asnaashari, 0059).
As per Claim 14, it is similar to claim 10 and therefore the same rejections are incorporated.
Response to arguments
The Applicant's arguments filed on March 17, 2026 have been fully considered, but they are not persuasive.
Applicant argues, ‘Support for the claimed feature of "maintaining a plurality of processing threads for the plurality of memory access command queues" is clearly provided, e.g., ….the Specification….’ (Rem, Pg. 8)
Response: This argument is incorrect.
As mentioned in the 112(b), the present limitation ‘maintaining a plurality of processing threads for the plurality of memory access command queues’ is inconsistent with the spec. Para-0067 of the spec, recites, ‘several processing threads can be supported for every memory access command queue’.
The limitation differs from the spec and the difference lies in the mapping ratio between the threads and the queues. Please see the 112(b).
As an aside, all amendments must be supported by the spec. If the applicant amends to cure an indefiniteness issue, they must not claim subject matter the inventor did not originally possess.
Applicant further argues, ‘Therefore, step 520 is not "essential" subject matter’. (Rem, Pg. 10)
Response: This argument is incorrect.
Fig. 5 recites a flow chart describing a set of rules performed by the controller to process a command in a queue. The flowchart in the drawings is not a suggestion. It is the definitive algorithm that gives structure to the functions recited in the claim. In Para-0070, the spec recites, ‘At operation 520, the controller identifies the memory device specified by the memory access command’. The spec does not recite that step 520 is an optional step or it can be omitted or inessential.
Furthermore, the claim 1 recitation, ‘….based on the memory access command being directed to a first memory device….’ requires that the ‘first memory device’ is identified via step 520. The cancellation conflicts with claim 1 and suggests that the command is directed to any arbitrary memory device, which changes the scope of the claim. Hence the rejection is maintained.
Applicant further argues, ‘The applicant….disagrees. Support for the claimed feature of "processing the….command by a first processing thread" is clearly provided,….passage….spec’,……Specification 0067. (Rem, Pg. 10)
Response: This argument is incorrect.
A mere reference by the applicant to a paragraph/passage in the spec (Para-0067), without explaining in detail how that paragraph teaches the limitation(s), leaves the metes and bounds of the claim scope unclear. The applicant’s silence is an indication that claim(s) 1, 11, 15 do not align with para-0067 of the spec.
The main drawback of Para-0067 of the spec is that it fails to show how the controller is integrated into the recitations of the paragraph and how it manages the threads, queues and devices.
That said, Para-0067 has significant issues under 112(b) and 112(a), primarily stemming from vague scoping and contradictions. For example, the paragraph requires commands to be processed in-order per device but out-of-order across devices. Since multiple threads process commands simultaneously, maintaining device-specific ordering while allowing arbitrary out-of-order execution across devices, recites an indefinite scope. The lack of figures explaining how queues, threads and devices map to each other, adds to the contradictions.
Since multiple threads process commands simultaneously, reciting a ‘corresponding memory device’ is a relative term because it does not clearly teach which device is being referenced.
The phrase, ‘several processing threads’ is ambiguous because it can represent a static pool of threads or dynamic allocation of threads. Since it also fails to clearly specify whether the multithreading occurs concurrently or in parallel, the scope is indefinite.
That said, Claim 1 recites, ‘processing the ….command by a first processing thread of the….threads based on the ….command being directed to a first memory device associated with the first processing thread’. The spec does not recite this limitation.
As recited, the ‘processing….’ is ‘based on the ….command being directed to a first memory device associated with the first processing thread’. The latter part, ‘based on….’, suggests that the thread dictates the path of the command. But since Para-0067 discloses that multiple threads process commands simultaneously, it is unclear which is ‘a first thread’.
It is unclear if ‘a first thread’ is associated with the queue of the retrieved command. More importantly, the spec does not disclose how it is determined that ‘a first thread’ is associated with ‘a first device’. Accordingly, the limitation recites an indefinite scope and is open to multiple interpretations. See 112(b).
Applicant further argues, ‘….Contrary to the Office's assertion, nothing in the claim indicates any "hypothetical steps performed by a first thread and controller’. (Rem, Pg. 11)
Response: This argument is incorrect.
Claim 1 (flipped version) recites, ‘based on the memory access command being directed to a first memory device associated with the first processing thread, processing the memory access command by a first processing thread of the plurality of processing threads’.
As mentioned in the previous argument, the limitation recites a targeted data transaction in a multithreaded system where a specific execution path dictated by ‘a first thread’, directs the command to a designated ‘a first device’. This ‘execution path’ requires mapping information, but the spec, Para-0067 does not disclose how the controller manages the queues, their threads and maps ‘a first thread’ to guide the command to ‘a first device’.
More importantly, there is no written description explaining how the ‘threads’ are integrated into the claimed apparatus and how the controller identifies each thread and associates it with a ‘corresponding first device’. As per the spec, the controller has no knowledge of the threads. As a result, the received command cannot be processed by the ‘a first thread’ to reach ‘a first device’, rendering the limitation a hypothetical scenario.
Applicant further argues, ‘Therefore, step 550 is not "essential" subject matter. (Rem, Pg. 12)
Response: This argument is incorrect.
Fig. 5 of the spec discloses a flow chart/algorithm. As mentioned in the 112(b), Fig. 5, step 560 is a conditional statement, which evaluates to either true or false and dictates a strict path. If true, take path X, else-if false, take path Y. The spec clearly recites the two distinct paths based on whether step 560 evaluates to true or false. See Paras-0072,0073.
A conditional statement does not mean that the statement can be skipped or bypassed. The spec does not explicitly teach that the step can be skipped or that it is inessential. Skipping it means the claim fails to include all ‘essential elements’ and changes how the invention works and claim scope. Hence the rejection is maintained.
Applicant further argues, ‘However, Brewer has no teachings that could be reasonably interpreted as indicating the claimed correspondence within a thread and a corresponding memory device’. (Rem, Pg. 13)
Response: This argument is incorrect.
What is claimed and what is described in the spec do not align with each other. According to the spec, the controller has no knowledge of threads. So how the controller manages threads is indefinite.
Paras-0021,0069 of the spec do not disclose how ‘threads’ are integrated into the claimed apparatus. Therefore how the mapping between a thread and a corresponding device is established is indefinite.
The combination of the prior art discloses the above requirement, wherein Brewer discloses that the HTP interacts with memory controller 120 to read and write to memory 125/target via work descriptor data packets. The information in the work descriptor data packet identifies the target memory device for read or write. Para-0271 recites that memory 125 can be Flash or E2PROM memory which are examples of RAM-ROM hybrid memory, as required by the disclosure.
Brewer, Figs. 9A-9B, Para-0138 show how information in the work descriptor is assigned to a thread ID to execute the instruction to read/write to memory 125. This suggests that the thread ID establishes the mapping between that thread and a corresponding memory device 125.
Paras-0118,0154 further prove the mapping between each thread and target device by having HTP 300 track each thread reading/writing to memory 125. Also a count of all executed threads are maintained in memory 125.
Brewer discloses the creation and management of threads as the HTP interacts with controller 120 to read or write to memory 125. Paras-0136,0137 recite that when a r/w packet is received by controller 120 for memory 125 and decoded, the thread ID of the thread which made the request is obtained. Hence it is valid to interpret that each thread is mapped to the corresponding memory device. Para-0172 recites a write operation to memory 125 as directed by a thread. These citations imply that the thread ID is shared between HTP and the controller for target memory device 125 via the work descriptor packet. This information helps each thread to be utilized to service memory access commands directed to a corresponding memory device.
Applicant further argues, ‘Vainer has no teachings…. interpreted as "associate[ing] the thread to the target memory device”.’ (Rem, Pg. 14)
Response: This argument is incorrect.
Vainer complements Brewer because Vainer, Figs. 1,6-8 clarifies the mapping between queues, threads and memory devices. For example, Vainer, Fig. 8, Paras-0109,0110 recite, ‘At block 820, a thread manager may queue commands for processing and each processing thread may select commands from their corresponding queue according to the priority, selection logic, and processing resources of that processing thread. At block 822, the storage commands may be executed against the target memory devices. For example, each processing thread may, in parallel, select storage commands from their corresponding queues and execute them (against their target device)’. The spec supports parallel execution.
Vainer, Para-0043 recites, ‘As each command request is received, it is assigned to one of threads 202 for processing. So command request 220.1 is assigned to thread 202.1, command request 220.2 may be assigned to thread 202.2, and command request 220.3 may be assigned to thread 202.3.
Since each command request identifies a target memory device, the above assignment between the command request and a thread discloses the mapping/association between the target memory device and the thread.
Therefore Vainer discloses associating the thread to the target memory device.
Applicant further argues, ‘Conversely, Vainer….teaches that multiple threads may operate on the same target memory device’. (Rem, Pg. 14)
Response: This argument is incorrect.
Vainer, Para-0004 recites that if the above problem arises, the commands are managed so that they are executed in each independent context/thread in such a way that no conflicts are created when interacting with the shared resource/target device. Hence, Vainer discloses a solution to the problem.
That said, the spec recites the same problem. Spec, Para-0067 recites that multiple threads process commands simultaneously to maintain device-specific ordering while allowing arbitrary out-of-order execution across devices. But the spec does not disclose the solution to the problem.
Therefore the spec discloses ‘holes’ (race conditions, deadlocks etc.) when processing commands with threads.
Applicant further argues, ‘Vainer has no teachings…."wherein each processing thread …..is utilized to service memory access commands directed to a respective memory device of the plurality of….devices."’ (Rem, Pg. 15)
Response: This argument is incorrect.
The argument has been addressed. Please see above.
Applicant further argues, ‘Therefore, the cited references,….fail to teach …the claimed "maintaining plurality….threads for the plurality of ….command queues, wherein each processing thread ….is utilized to service memory access commands directed to a respective memory device….." (Rem, Pg. 15)
Response: This argument is incorrect.
The limitation is unrecited in the spec and cannot be inherently derived from the original disclosure. The spec does not disclose the mapping between queues, threads and devices, as required by the limitation.
Because the spec only discloses maintaining the queues by the controller, and processing commands only by the controller, the spec fails to provide the boundaries and structure for how the threads interact with the controller, commands and devices, rendering the scope of the claim indefinite.
Claim 1 is based on an isolated paragraph, Para-0067 of the spec. The thread-based limitations of claim 1 are unsubstantiated because Para-0067 of the spec does not disclose how the controller is integrated into the recitations of the paragraph. According to the spec, the controller has no knowledge of the threads. And the arguments are incorrect because they rely on improper limitations to mischaracterize the prior art.
The original disclosure discloses how the controller maintains queues to process commands to r/w to the memory devices. But the applicant uses a casual reference to threads in Para-0067 to recite a different invention in claim 1, focused on maintaining threads to process commands with an elusive controller.
The inventor does not possess the architecture and functions involving the controller, threads, queues and memory devices, as claimed by the applicant.
The combination of La Fratta,Brewer,Vainer,Dobelstein, wherein Brewer,Vainer disclose the mapping between the threads, queues and memory devices as maintained by the controller. As explained in the above arguments and the O/A, Brewer,Vainer disclose the above requirement. Please see O/A.
Examiner Notes -
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
1.’Assigning and scheduling threads for multiple prioritized queues’, US20140373021A1, Microsoft - An operating system provides a pool of worker threads servicing multiple queues of requests at different priority levels. A concurrency controller limits the number of concurrently executing, i.e., active, worker threads. The operating system tracks the number of concurrently executing threads above each priority level, and preempts operations of lower priority worker threads in favor of higher priority worker threads (Para-0005).
2. ‘Thread commencement using a work descriptor packet in a self-scheduling processor’, US20190339976A1, Micron - A multi-threaded, self-scheduling processor is disclosed which can create threads on local or remote compute elements. The processor comprises: a processor core adapted to execute a fiber create instruction, and a core control circuit coupled to the processor core, the core control circuit adapted to automatically schedule the fiber create instruction for execution by the processor core and generate one or more work descriptor data packets to another processor or hybrid threading fabric circuit for execution of a corresponding plurality of execution threads (Para-0011).
Conclusion
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 ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm 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, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132
Prosecution Insights