A DRAM refresh command hands the memory device a fixed, unforgiving slice of time. The refresh cycle time — tRFC, the interval the device is allowed to occupy before the host may issue another command to that bank — is the budget, and everything the device wants to accomplish under cover of that refresh has to fit inside it. Modern DRAM increasingly wants to accomplish more than one thing there. Beyond restoring charge to the cells, devices now carry bookkeeping about how hard each row is being hit by its neighbors, and that bookkeeping has to be maintained, reset, and rewritten somewhere. A Micron Technology, Inc. application published July 16, 2026 is directed to squeezing that second job into the same window as the first, and to the specific circuit-level reason it cannot simply be done all at once.

The application, US20260204307A1, is titled Performing Serialized Update Procedures during a Refresh Period and names Yang Lu, Donald Morgan, and QiaoHua Dong as inventors. Claim 1, the first independent claim, recites a method performed by a memory device: receiving a refresh command; concurrently refreshing, during a time interval and based on that command, at least two rows within a bank, those rows associated with different refresh sections of the bank; and "performing at least two update procedures in a serialized manner during the time interval to update usage-based-disturbance data stored within the at least two rows." The two halves of that claim are in tension by design — the refresh is parallel, the update is emphatically not.

"Usage-based disturbance" is the document's own term of art, and it is worth glossing for readers who know the phenomenon by its informal industry name, Rowhammer: the effect in which repeatedly activating one wordline disturbs charge in physically adjacent rows. Claim 2 pins the data type down directly — the usage-based-disturbance data "comprises activation counts associated with the at least two rows." Claim 4 then specifies what an update writes: a default value that may be a same fixed value, different randomized values, or values calculated from the counts' current values. In other words, the update procedure at issue is the periodic zeroing or re-seeding of per-row activation counters that live in the array alongside the data they describe.

Why the updates run in series

The obvious engineering question is why a device that just refreshed three rows simultaneously cannot update three counters simultaneously. The application's description supplies the answer, and it is a column-path problem rather than a row-path one. Claim 5 recites that the at least two rows are associated with different column segments, and that those different column segments are associated with different column repair solutions — the per-segment redundancy mappings that steer accesses around defective columns discovered at test. Two rows refreshed together on the same wordline timing can nonetheless sit behind two different repair maps, and a repair map is expressed physically as which column select lines fire.

By performing the multiple update procedures in series, the memory device can utilize appropriate column repair solutions to access the usage-based-disturbance data and avoid a potential conflict on global input/output (GIO) lines.— Performing Serialized Update Procedures during a Refresh Period, US20260204307A1

That is the whole argument compressed into one sentence of the abstract's description. The global input/output lines are the shared datapath out of the array; drive two column segments onto them in the same cycle with two different repair mappings applied and the accesses collide. Serializing sidesteps the collision without adding a second GIO network. Claim 20, reciting against the second independent method claim, makes the mechanism explicit at the signal level: the first update procedure comprises activating a first set of column select lines based on a first column repair solution associated with the first column segment, and the second comprises activating a second set of the column select lines based on a second column repair solution associated with the second column segment. One repair solution, one column-select activation, one counter rewritten — then the next.

The timing is where the disclosure earns its title. Claim 7 recites performing a first update procedure on a first row during a first portion of the time interval and a second update procedure on a second row during a second portion occurring after the first — an explicit ordering, not merely a set of operations. On the apparatus side, claim 15 requires the circuit to perform the first, second, and third update procedures during the refreshing of those rows and prior to the end of the refresh cycle time corresponding to the refresh command. Claim 16 adds a start condition: the first update procedure is performed after a time interval associated with a row column delay has elapsed since the refresh command was received. Read together, these recite a scheduled train of column accesses that begins once the rows are open and finishes before tRFC expires — a sequence fitted into slack that the refresh operation already owns.

Claim structure and classification

The application carries 20 claims across three independent claims. Claim 1 is the method framing described above. Claim 10 is the apparatus counterpart, reciting a memory device with at least one bank whose rows are associated with different refresh sections and each configured to store usage-based-disturbance data corresponding to the row, circuitry configured to concurrently refresh at least two of them, and a separate circuit configured to perform the at least two update procedures in a serialized manner during that interval. Splitting the refresh circuitry from the update circuit in the apparatus claim is a notable drafting choice: it describes the counter-update engine as its own block hanging off the bank rather than as a mode of the refresh logic. Claim 17 is a second method claim that drops the refresh step entirely and recites only the two ordered update procedures on a first refreshed row and a second refreshed row, each associated with its own refresh section and column segment.

Classification places the filing squarely in DRAM refresh control. It is classified under G11C 11/40618, G11C 11/40603, and G11C 11/40615 — the subgroups covering refresh operations and refresh circuitry for volatile semiconductor memory, rather than under error-correction or security art. That is consistent with how the document frames itself throughout: this is refresh scheduling and column-path arbitration, not a detection algorithm.

The publication arrived alongside a broader run of Micron applications. US20260204308A1, on outputting data from a memory device, published the same day. Nearby publications include US20260196285A1, on storing error information and providing recommendations based on it; US20260186896A1, on storing memory metadata; and US20260188417A1, on forcing memory cell failures in a memory device. On the process side, US20260198284A1 covers conductive interconnects and methods of forming them. The metadata-storage and error-information applications share a theme with this one: array capacity spent on data about the data, and the access machinery required to reach it.

US20260204307A1 is a published application, not a granted patent. Publication means the disclosure is now public and the claim set as filed is on the record; it does not mean any of these claims have been examined or allowed, and the scope may change before any grant. What the document establishes today is the engineering account: as per-row disturbance counters move into the array, the constraint that shapes how they are maintained is not the refresh timing itself but the column repair map and the single shared datapath underneath it.