DETAILED ACTION
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 .
Status of Claims
Claims 1-20 are pending and of the above claims 9-15 are withdrawn from consideration.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on July 09, 2026 is/are in compliance with the provisional of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Election/Restrictions
Applicant's election with traverse of claims 1-8 and 16-20 in the reply filed on July 09, 2026 is acknowledged. The traversal is on the ground(s) that both inventions recites "efficiently scheduling processing-in-memory (PIM) and non-PIM transactions" and a "memory controller" that execut[es] a PIM transaction and a non-PIM transaction" on a "set of PIM memory banks.". This is not found persuasive because apart from the memory controller and performing of PIM and non-PIM transactions the two inventions have no feature in common and furthermore the claims relate to different aspects concerning PIM/non-PIM transaction scheduling.
The requirement is still deemed proper and is therefore made FINAL.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 2, 4, 6-8, 16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutu et al. (US 2024/0220107) (hereinafter Dutu) (published July 04, 2024) in view of itself.
Regarding Claims 1 and 16, taking claim 16 as exemplary, Dutu discloses a processing-in-memory (PIM) device for efficiently scheduling PIM and non-PIM transactions, the PIM device comprising: a memory comprising a set of PIM memory banks; and
“FIG. 1 is a block diagram of a system 100 that includes a host with at least one core, a memory module with a memory and a PIM component, and a memory controller configured to grant requests by the host for the PIM component to perform transactions … The memory module 104 includes memory 110 and processing-in-memory component 112” (Dutu [0052])
“As depicted in the illustrated example of FIG. 1, the memory controller 114 includes a scheduling module 118. The scheduling module 118 is representative of logic configured to schedule requests 116 (e.g., both PIM requests and non-PIM requests) for execution in a manner that optimizes performance of the system 100 (e.g., limits computational resource consumption, decreases latency, and reduces power consumption of the system 100) when measured over execution of the requests 116” (Dutu [0063])
a memory controller coupled to the memory, and configured to perform operations comprising:
“The system 100 is further depicted as including memory controller 114. The memory controller 114 is configured to receive requests 116 from the host 102 (e.g., from a core 108 of the host 102). In the illustrated example, the requests 116 represent one or more PIM requests, one or more non-PIM requests, or a combination thereof” (Dutu [0061])
initiating execution of a PIM transaction on the set of PIM memory banks;
“PIM requests included in the scheduled requests 122 are transmitted by the memory controller 114 to an operation queue 130 of the processing-in-memory component 112. The operation queue 130 is representative of a data storage structure in the processing-in-memory component 112 that maintains an ordered list of operations scheduled for sequential execution by the processing-in-memory component 112 using data stored in memory 110. As part of executing a PIM request, the processing-in-memory component 112 generates a result 132 that includes data generated from processing data stored in the memory 110 during one or more operations involved in executing a PIM request” (Dutu [0070])
determining whether a latency of the PIM transaction exceeds a quality of service (QOS) limit;
“The respective thresholds define a time limit for enqueuing requests at the memory controller, such that a PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the PIM request stall threshold, and a non-PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the non-PIM stall threshold” (Dutu [0087] paragraph [0056] of applicant’s specification clarifies that PIM transaction is causing the exceeding of a QOS limit of the non PIM transaction; thus when non-PIM request must be scheduled for execution, the PIM request would cause the QOS of the non-PIM request to be exceeded)
determining whether the PIM transaction is buffering;
“The PIM mode history table 318, for instance, is updated by the PIM switch predictor 314 to enter a one or a zero indicating whether scheduling a PIM request at a given clock cycle will result in a maximum row locality (e.g., whether scheduling the PIM request at the clock cycle will result in a threshold number of row hits in an open row 306 of the bank 304)” (Dutu [0094] paragraph [0074] of applicant’s specification defines buffering as a page hit ratio satisfying a threshold)
suspending the execution of the PIM transaction based on the latency of the PIM transaction exceeding the QOS limit or based on the PIM transaction is buffering; and
“In addition to considering request priority information and estimated switching cost, the second arbiter 208 is configured to select from the multiple requests output by the first arbiter 206 based on a PIM request stall threshold and a non-PIM request threshold (e.g., as defined by the stall time system 128, described in further detail below with respect to FIG. 4)” (Dutu [0087])
“By implementing the arbitration system 124 and considering historical system performance metrics, the scheduling module 118 is configured to switch the system 100 between operating in a PIM mode and operating in a non-PIM mode based on behavior of a source (e.g., the host 102) from which requests 116 are received, which is not possible using conventional systems” (Dutu [0090] when switching to operating in a non-PIM mode, execution of PIM transactions are suspended)
initiating execution of a non-PIM transaction on the set of PIM memory banks of the PIM device.
“A system is switched between executing processing-in-memory (PIM) requests and executing non-PIM requests (block 702). The memory controller 114, for instance, causes the system 100 to switch from executing non-PIM requests to executing PIM requests, or causes the system 100 to switch from executing PIM requests to executing non-PIM requests” (Dutu [0128])
But does not explicitly state if the latency of the PIM transaction does not exceed the QOS limit for the determining of whether the PIM transaction is buffering. However Dutu does teach determining whether scheduling a PIM request will produce a threshold number of row hits and using that determination, along with stall thresholds, to arbitrate between PIM and non-PIM requests. It would have been obvious before the effective filing date of the invention to apply these disclosed scheduling criteria sequentially, such that, when the QoS condition does not require switching, the controller further determines whether the PIM transaction remains productive based on its row-hit/row-locality condition and, if not, suspends PIM execution and selects a non-PIM request. This modification would have been a predictable use of Dutu's existing arbitration criteria to achieve its stated objective of reducing latency and improving resource utilization, with a reasonable expectation of success because the same scheduler already evaluates these conditions to select between PIM and non-PIM execution.
The Examiner further notes for method claim 1, the limitation of “suspending the execution of the PIM transaction based on the latency of the PIM transaction exceeding the QOS limit or based on the PIM transaction buffering if the latency of the PIM transaction does not exceed the QOS limit” (emphases added) are contingent limitations and are not required under the broadest reasonable interpretation of the claim. (see MPEP 2111.04) The Examiner encourages the Applicant to further positively recites these limitations for them to be required.
Regarding Claims 3 and 18, Dutu further discloses wherein determining whether the PIM transaction is buffering comprises one or more of: determining, by the memory controller, whether the PIM transaction is at an end of a page hit stream; determining whether a page hit ratio of the PIM transaction satisfies a predetermined threshold; or determining whether a command queue occupancy rate of the PIM transaction satisfies a predetermined threshold.
“The PIM mode history table 318, for instance, is updated by the PIM switch predictor 314 to enter a one or a zero indicating whether scheduling a PIM request at a given clock cycle will result in a maximum row locality (e.g., whether scheduling the PIM request at the clock cycle will result in a threshold number of row hits in an open row 306 of the bank 304)” (Dutu [0094])
Regarding Claims 4 and 19, Dutu further discloses further comprising: determining, by the memory controller, that a latency of the non-PIM transaction exceeds the QOS limit;
“The respective thresholds define a time limit for enqueuing requests at the memory controller, such that a PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the PIM request stall threshold, and a non-PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the non-PIM stall threshold” (Dutu [0087] see fig. 3 blocks 304, 314, and paragraph [0056] of applicant’s specification clarifies that PIM transaction is causing the exceeding of a QOS limit of the non PIM transaction (and vice versa for changing form non-PIM to PIM); thus when PIM request must be scheduled for execution, the non-PIM request would cause the QOS of the PIM request to be exceeded)
suspending the execution of the non-PIM transaction based on the latency of the non-PIM transaction exceeding the QOS limit; and
“In addition to considering request priority information and estimated switching cost, the second arbiter 208 is configured to select from the multiple requests output by the first arbiter 206 based on a PIM request stall threshold and a non-PIM request threshold (e.g., as defined by the stall time system 128, described in further detail below with respect to FIG. 4)” (Dutu [0087])
“By implementing the arbitration system 124 and considering historical system performance metrics, the scheduling module 118 is configured to switch the system 100 between operating in a PIM mode and operating in a non-PIM mode based on behavior of a source (e.g., the host 102) from which requests 116 are received, which is not possible using conventional systems” (Dutu [0090] when switching to operating in a PIM mode, execution of non-PIM transactions are suspended)
resuming, by the memory controller, execution of the PIM transaction.
“A determination is made as to whether the system is executing PIM requests following the switch (block 704). In response to a first one of the scheduled requests 122 executed after the system switch being a PIM request executed by the processing-in-memory component 112 (e.g., a “Yes” determination at block 704), a difference between a PIM request stall threshold and a time at which the first one of the scheduled requests 122 was stalled at the request queue 120 is computed (block 706)” (Dutu [0129])
Regarding Claims 6 and 20, Dutu further discloses further comprising: determining, by the memory controller, that the PIM transaction has buffered above a buffer threshold if a latency of the non-PIM transaction does not exceed the QOS limit;
“The respective thresholds define a time limit for enqueuing requests at the memory controller, such that a PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the PIM request stall threshold, and a non-PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the non-PIM stall threshold” (Dutu [0087] see fig. 3 blocks 304, 314, and paragraph [0056] of applicant’s specification clarifies that PIM transaction is causing the exceeding of a QOS limit of the non PIM transaction (and vice versa for changing form non-PIM to PIM); thus when PIM request must be scheduled for execution, the non-PIM request would cause the QOS of the PIM request to be exceeded)
“The PIM mode history table 318, for instance, is updated by the PIM switch predictor 314 to enter a one or a zero indicating whether scheduling a PIM request at a given clock cycle will result in a maximum row locality (e.g., whether scheduling the PIM request at the clock cycle will result in a threshold number of row hits in an open row 306 of the bank 304)” (Dutu [0094])
suspending the execution of the non-PIM transaction based on the PIM transaction having buffered above the buffer threshold; and
“In some implementations, the switch cycle estimator 226 identifies that it is optimal to switch from operating in a non-PIM mode to operating in a PIM mode when doing so will result in a maximum number of PIM hits and when the number of potential PIM hits is greater than a number of potential non-PIM hits multiplied by a number of banks in a channel (or pseudo-channel) of the memory 110. In implementations, the maximum number of PIM hits is application-specific (e.g., specific to an application being run by the host 102 as part of generating the requests 116) and estimated based on historical instances of the host 102 running the application” (Dutu [0085])
resuming, by the memory controller, execution of the PIM transaction.
“A determination is made as to whether the system is executing PIM requests following the switch (block 704). In response to a first one of the scheduled requests 122 executed after the system switch being a PIM request executed by the processing-in-memory component 112 (e.g., a “Yes” determination at block 704), a difference between a PIM request stall threshold and a time at which the first one of the scheduled requests 122 was stalled at the request queue 120 is computed (block 706)” (Dutu [0129])
Regarding Claim 7, Dutu further discloses further comprising: determining, by the memory controller, that the non-PIM transaction is buffering if a latency of the non-PIM transaction does not exceed the QOS limit;
“The respective thresholds define a time limit for enqueuing requests at the memory controller, such that a PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the PIM request stall threshold, and a non-PIM request must be scheduled for execution if it has been stalled at the memory controller 114 for a time that satisfies the non-PIM stall threshold” (Dutu [0087] see fig. 3 blocks 304, 314, and paragraph [0056] of applicant’s specification clarifies that PIM transaction is causing the exceeding of a QOS limit of the non PIM transaction (and vice versa for changing form non-PIM to PIM); thus when PIM request must be scheduled for execution, the non-PIM request would cause the QOS of the PIM request to be exceeded)
“The non-PIM mode history table 320, for instance, is updated by the non-PIM switch predictor 316 to include values indicating whether scheduling a non-PIM request at a given clock cycle will provide a maximum number of row hits and a maximum number of open rows (e.g., whether scheduling the non-PIM request at the clock cycle will result in a threshold number of row hits and/or a threshold number of simultaneous open rows in one or more banks 304 of memory 110)” (Dutu [0096])
suspending the non-PIM transaction based on the non-PIM transaction buffering; and
“In addition to considering request priority information and estimated switching cost, the second arbiter 208 is configured to select from the multiple requests output by the first arbiter 206 based on a PIM request stall threshold and a non-PIM request threshold (e.g., as defined by the stall time system 128, described in further detail below with respect to FIG. 4)” (Dutu [0087])
“By implementing the arbitration system 124 and considering historical system performance metrics, the scheduling module 118 is configured to switch the system 100 between operating in a PIM mode and operating in a non-PIM mode based on behavior of a source (e.g., the host 102) from which requests 116 are received, which is not possible using conventional systems” (Dutu [0090] when switching to operating in a PIM mode, execution of non-PIM transactions are suspended)
resuming, by the memory controller, execution of the PIM transaction.
“A determination is made as to whether the system is executing PIM requests following the switch (block 704). In response to a first one of the scheduled requests 122 executed after the system switch being a PIM request executed by the processing-in-memory component 112 (e.g., a “Yes” determination at block 704), a difference between a PIM request stall threshold and a time at which the first one of the scheduled requests 122 was stalled at the request queue 120 is computed (block 706)” (Dutu [0129])
Regarding Claim 8, Dutu further discloses wherein determining that the non-PIM transaction is buffering comprises one or more of: determining that the non-PIM transaction is at an end of a page hit stream; determining that a page hit ratio of the non-PIM transaction fails to satisfy a predetermined threshold; or determining that a command queue occupancy rate of the non-PIM transaction fails to satisfy a predetermined threshold.
“The non-PIM mode history table 320, for instance, is updated by the non-PIM switch predictor 316 to include values indicating whether scheduling a non-PIM request at a given clock cycle will provide a maximum number of row hits and a maximum number of open rows (e.g., whether scheduling the non-PIM request at the clock cycle will result in a threshold number of row hits and/or a threshold number of simultaneous open rows in one or more banks 304 of memory 110)” (Dutu [0096])
Claims 2, 5, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutu (published July 04, 2024) in view of itself as applied to claim 1, 4, and 16 above, and further in view of Madan et al. (US 2024/0103745) (hereinafter Madan) (published March 28, 2024).
Regarding Claims 2 and 17, Dutu disclosed the method of claim 1 and device of claim 16, but does not explicitly state wherein suspending the execution of the PIM transaction comprises blocking an activation function and a precharge function for the PIM transaction on the set of PIM memory banks of the PIM device, wherein initiating the execution of the non-PIM transaction comprises unblocking an activation function and a precharge function for the non-PIM transaction on the set of PIM memory banks of the PIM device.
Madan discloses wherein suspending the execution of the PIM transaction comprises blocking an activation function and a precharge function for the PIM transaction on the set of PIM memory banks of the PIM device, wherein initiating the execution of the non-PIM transaction comprises unblocking an activation function and a precharge function for the non-PIM transaction on the set of PIM memory banks of the PIM device.
“When the last one or more PIM requests to be executed prior to switching to non-PIM mode are being executed, instead of issuing a memory request to an idle group of memory banks, the arbiter 202 closes any currently open rows (e.g., issues a command to precharge or deactivate any currently open rows) in any of the idle groups of memory banks, and opens the row (e.g., issues a command to activate the row) in an idle group of memory banks targeted by the next memory request to be issued” (Madan [0064])
It would have been obvious before the effective filing date to a person of ordinary skill in the art to implement Dutu's switching between PIM mode and non-PIM mode by controlling the conventional DRAM activation and precharge operations associated with the memory banks. Activation and precharge are well-known DRAM operations used to open and close rows in a memory bank, respectively. Madan expressly describes that, when switching to non-PIM mode, the arbiter closes currently open rows by issuing precharge/deactivate commands and opens the row targeted by the next memory request by issuing an activate command. Thus, when the scheduler determines that PIM execution is to be suspended and the system is to operate in non-PIM mode, preventing or blocking the activation and precharge operations associated with the PIM transaction, while permitting those operations for the selected non-PIM transaction, would have been a straightforward implementation of the disclosed mode switch.
The modification would merely use the conventional DRAM mechanisms for row activation and precharge to enforce the scheduling decision already made by Dutu. When operating in PIM mode, the controller permits the activation and precharge operations needed to execute the selected PIM transaction; when switching to non-PIM mode, the controller prevents the PIM transaction from causing those operations and instead permits the corresponding operations for the selected non-PIM transaction. Madan further demonstrates that controlling row precharge and activation in response to a transition between PIM and non-PIM execution was a known technique. A person of ordinary skill therefore would have had reason to apply these conventional memory-bank controls to Dutu's PIM/non-PIM scheduler to ensure that the physical memory-bank operations correspond to the selected execution mode, thereby avoiding conflicts between the suspended PIM transaction and the non-PIM transaction being executed.
Regarding Claim 5, Dutu disclosed the method of claim 4, but does not explicitly state wherein suspending the execution of the non-PIM transaction comprises blocking an activation function and a precharge function for the non-PIM transaction on the set of PIM memory banks, wherein resuming execution of the PIM transaction comprises unblocking an activation function and a precharge function for the PIM transaction on the set of PIM memory banks.
Madan discloses wherein suspending the execution of the non-PIM transaction comprises blocking an activation function and a precharge function for the non-PIM transaction on the set of PIM memory banks, wherein resuming execution of the PIM transaction comprises unblocking an activation function and a precharge function for the PIM transaction on the set of PIM memory banks.
“When the last one or more PIM requests to be executed prior to switching to non-PIM mode are being executed, instead of issuing a memory request to an idle group of memory banks, the arbiter 202 closes any currently open rows (e.g., issues a command to precharge or deactivate any currently open rows) in any of the idle groups of memory banks, and opens the row (e.g., issues a command to activate the row) in an idle group of memory banks targeted by the next memory request to be issued” (Madan [0064])
It would have been obvious before the effective filing date to a person of ordinary skill in the art to implement Dutu's switching between PIM mode and non-PIM mode by controlling the conventional DRAM activation and precharge operations associated with the memory banks. Activation and precharge are well-known DRAM operations used to open and close rows in a memory bank, respectively. Madan expressly describes that, when switching to non-PIM mode, the arbiter closes currently open rows by issuing precharge/deactivate commands and opens the row targeted by the next memory request by issuing an activate command. Thus, when the scheduler determines that PIM execution is to be suspended and the system is to operate in non-PIM mode, preventing or blocking the activation and precharge operations associated with the PIM transaction, while permitting those operations for the selected non-PIM transaction, would have been a straightforward implementation of the disclosed mode switch.
The modification would merely use the conventional DRAM mechanisms for row activation and precharge to enforce the scheduling decision already made by Dutu. When operating in PIM mode, the controller permits the activation and precharge operations needed to execute the selected PIM transaction; when switching to non-PIM mode, the controller prevents the PIM transaction from causing those operations and instead permits the corresponding operations for the selected non-PIM transaction. Madan further demonstrates that controlling row precharge and activation in response to a transition between PIM and non-PIM execution was a known technique. A person of ordinary skill therefore would have had reason to apply these conventional memory-bank controls to Dutu's PIM/non-PIM scheduler to ensure that the physical memory-bank operations correspond to the selected execution mode, thereby avoiding conflicts between the suspended PIM transaction and the non-PIM transaction being executed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Murphy (US 2017/0263306) discloses a processing-in-memory (PIM) memory system having memory banks configured to perform processing operations and techniques for scheduling PIM operations and conventional memory operations using the memory resources of the PIM device.
Kim et al. (US 2025/0045127) discloses techniques for scheduling PIM and non-PIM transactions in a memory system, including controlling execution of different types of transactions based on characteristics of the transactions and availability or utilization of memory resources.
Puthoor et al. (US 2025/0355594) discloses techniques for scheduling PIM and non-PIM transactions on PIM memory banks, including monitoring transaction conditions and selectively switching or suspending execution of one transaction to allow another transaction to use the PIM memory resources.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDNEY LI whose telephone number is (571)270-5967. The examiner can normally be reached Monday to Friday 10:00 AM to 6:00 PM.
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, Arpan P Savla can be reached at (571) 272-1077. 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.
/S.L./Examiner, Art Unit 2137
/PRASITH THAMMAVONG/Primary Examiner, Art Unit 2137
