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 .
Response to Amendment
This office action is in response to the amendment filed on 06/03/2026.
Claims 1-20 are presented for further examination.
Applicant's argument that the newly added claim limitation is not taught or suggested by the cited prior art has been fully considered but is moot in view of the new ground of rejection set forth below. Applicant's arguments are directed to limitations newly added by amendment, which are addressed by the combination of Alexander and Topp in the new ground of rejection below
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-5, 9, 12-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Alexander et al. (US 2013/0339650; hereinafter Alexander) in view of Topp et al. (US 2014/0281351; hereinafter Topp).
Regarding independent claims 1, 12, and 20, taking claim 1 as exemplary analysis,
Alexander teaches prefetcher comprising a buffer and a prefetch outstanding buffer operatively coupled to the buffer (Alexander discloses prefetch logic 205/405, pipeline 202/402, TLB 203/403, and prefetch buffer 206/406. Prefetch buffer 206/406 is a hardware-implemented buffer that stores virtual-address prefetch requests that cannot presently complete address translation. Alexander, Figs. 2–5, [0012]–[0019].
Alexander teaches that prefetch logic 205/405 issues a prefetch request comprising a virtual page address into pipeline 202/402. The request is presented to TLB 203/403 for translation. When the request misses the TLB and address-translation logic 204/404 is busy, the prefetch request is transferred to and stored in prefetch buffer 206/406. Alexander, [0012]–[0013], [0016]–[0018]; claims 1 and 9. Thus, Alexander teaches or suggests that the buffer is configured to send one or more prefetch virtual-address candidates to the prefetch outstanding buffer.
Alexander further teaches associating each stored prefetch request with an outstanding translation by match tag 411A–411N. Prefetch logic 405 monitors translation queue 409 and address-translation logic 404. When the translation identified by the match tag completes, the associated prefetch request is reissued from prefetch buffer 406 into pipeline 402 for translation and completion. Alexander, Fig. 4B, [0014], [0017], [0019]–[0022], [0030]–[0033]; claims 2 and 7. Accordingly, Alexander teaches that the prefetch outstanding buffer is configured to send one or more replay prefetch virtual addresses corresponding to the prefetch virtual-address candidates to the buffer based on the replay prefetch virtual addresses being ready for replay. Alexander’s “reissuing” of a previously unsuccessful virtual-address prefetch request is the claimed replay.
Alexander additionally teaches that prefetch buffer 206/406 is structurally separate from TLB 203/403 and address-translation logic 204/404. Alexander, Figs. 2 and 4A, [0016], [0018]. Alexander does not expressly identify address-translation logic 204/404 as an MMU that uses page tables and table-walking hardware.
Topp teaches a processor memory-management system including data TLB unit 172, TLB 370, and hardware page-miss handler 380. When a prefetch request misses TLB 370, the request triggers page-miss handler 380, which performs a page-table walk to locate the virtual-to-physical address translation. Topp, Figs. 1A and 3, [0046], [0048]–[0060]. Topp therefore teaches an MMU configured to use page tables and table-walking hardware to translate virtual addresses into physical addresses.
It would have been obvious to one of ordinary skill in the art before the effective filing date to implement Alexander’s address-translation logic 204/404 using Topp’s known MMU arrangement having TLB 370 and hardware page-miss handler 380. Both references address translating virtual-address data-prefetch requests after TLB misses. The modification would provide Alexander with a well-known hardware mechanism for obtaining a missing translation, thereby allowing stalled prefetch requests to be completed without software intervention and reducing translation latency.
The proposed modification would retain Alexander’s prefetch buffer 206/406 as a component separate from the address-translation logic/MMU, as expressly shown in Alexander’s Figs. 2 and 4A. Topp’s TLB and page-miss-handler teachings would be incorporated into Alexander’s separate address-translation logic 204/404; they would not require relocating prefetch buffer 206/406 into that logic. Therefore, the combined system teaches the prefetch outstanding buffer being separate from the MMU configured to use page tables and table-walking hardware.
Regarding claim(s) 2 and 13, the combination of Alexander and Topp further teaches wherein: the buffer is a translation lookaside buffer, and the translation lookaside buffer is configured to send the prefetch outstanding buffer the one or more prefetch virtual address candidates based on one or more virtual-to-physical address translation misses by the translation lookaside buffer (Alexander teaches that the claimed buffer may correspond to TLB 203/403. A prefetch request containing a virtual page address is checked in TLB 203/403 and is stored in prefetch buffer 206/406 when the request misses the TLB and address-translation logic 204/404 is unavailable. After the associated translation completes, the request is reissued from prefetch buffer 206/406 for translation by the TLB. Alexander, [0012]–[0013], [0016]–[0018]; claim 2.
Topp similarly teaches receiving data-prefetch and TLB-prefetch addresses, placing corresponding requests into TLB lookup/prefetch queues 362/364, and dispatching the requests to TLB 370. Topp, Fig. 3, [0048]–[0059], [0063]–[0068].
Thus, the combination teaches a translation lookaside buffer configured to send the prefetch outstanding buffer one or more prefetch virtual-address candidates based on virtual-to-physical-address translation misses.
To the extent that Alexander attributes movement of the missed request to prefetch logic 205/405 rather than directly to the TLB, it would have been obvious to provide the TLB miss indication and associated virtual address to the prefetch-buffer control logic because that information is necessary to determine which missed request is to be held and subsequently replayed. This is the arrangement taught by Topp’s TLB-prefetch and lookup-request paths).
Regarding claim(s) 3, the combination of Alexander and Topp further teaches wherein the translation lookaside buffer is a data translation lookaside buffer (dTLB) (Topp expressly teaches a data TLB unit 172 operatively coupled with data prefetcher 180 and TLB-prefetch component 185. Topp, Fig. 1A, [0046], [0048]. Thus, Topp teaches that the translation lookaside buffer is a data translation lookaside buffer (dTLB).
It would have been obvious to use Topp’s dTLB as Alexander’s TLB 203/403 because Alexander’s prefetch requests retrieve data lines from main memory into cache 202A/402A. Alexander, [0016], [0018]. A data TLB is the ordinary translation cache for such data-memory accesses).
Regarding claim(s) 4 and 14. the combination of Alexander and Topp further teaches wherein the prefetch outstanding buffer is configured to enter a prefetch virtual address candidate of the one or more prefetch virtual address candidates as an entry in the prefetch outstanding buffer based on the prefetch virtual address candidate being absent in the prefetch outstanding buffer (Topp teaches examining a TLB-prefetch queue to determine whether an entry requesting the same linear page number already exists. A new TLB-prefetch request and its linear page number are written into the queue only when there is no previous entry requesting the same linear-page-number translation. Topp, Fig. 3, [0053]–[0055], [0063]–[0064].
It would have been obvious to apply Topp’s duplicate-checking technique to Alexander’s prefetch buffer 206/406 before allocating a new entry. Both buffers store outstanding virtual-address prefetch information awaiting translation. Avoiding a second entry for an address already represented in the buffer would conserve the finite buffer capacity, avoid redundant translation work, and prevent multiple replays of the same prefetch address.
The combination therefore teaches entering a prefetch virtual-address candidate as an entry based on determining that the candidate is absent from the prefetch outstanding buffer).
Regarding claim(s) 5 and 15. the combination of Alexander and Topp further teaches wherein the prefetch outstanding buffer is configured to refrain from entering a prefetch virtual address candidate of the one or more prefetch virtual address candidates based on the prefetch virtual address candidate being an existing entry in the prefetch outstanding buffer (Topp teaches the complementary result of the duplicate check: a new request is written only if no previous entry requests the same LPN translation already. Topp, [0055], [0058], [0064]. Consequently, when an entry requesting the same translation already exists, Topp refrains from writing another entry.
It would have been obvious to use this duplicate-suppression rule in Alexander’s prefetch buffer for the reasons given regarding claim 4. The combination therefore teaches refraining from entering a prefetch virtual-address candidate based on that candidate being represented by an existing entry).
Regarding claims 9 and 19, Alexander teaches receiving initial prefetch requests from prefetch logic 405 and separately receiving replayed prefetch requests from prefetch buffer 406. Alexander further teaches that, after a translation completes, older buffered prefetch requests associated with that translation may be reissued while a newly generated prefetch request is saved in the prefetch buffer to wait for a later matching translation. Alexander, [0022]. This teaches favoring ready replay requests over newly generated requests.
Topp expressly teaches separate prefetch sources and queues: data-prefetch request queue 350, TLB lookup-request queue 362, and TLB-prefetch request queue 364. Topp further teaches arbitration in which lookup requests associated with data-prefetch requests already waiting for a physical page number receive higher priority than ordinary TLB-prefetch requests. Topp, Fig. 3, [0056]–[0059], [0067]–[0068].
It would have been obvious to apply Topp’s priority arbitration to Alexander’s initial and replay prefetch paths so that a replay request whose translation is already available is selected before a new speculative prefetch request. Ready replay requests have already occupied an outstanding-buffer entry and can immediately advance, whereas initial requests may require a new translation and additional buffering. Prioritizing ready replays would reduce outstanding-buffer occupancy and avoid starvation of previously delayed requests.
The combination therefore teaches receiving initial prefetch virtual addresses from a different prefetch queue and scheduling replay prefetch virtual addresses from the prefetch outstanding buffer ahead of the initial requests.
Claims 6-8 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Alexander et al. (US 2013/0339650; hereinafter Alexander) in view of Topp et al. (US 2014/0281351; hereinafter Topp), and further in view of Chang et al. (US 2010/0064120; hereinafter Chang).
Regarding claim(s) 6 and 16, Topp teaches that data-prefetch addresses are placed in data-prefetch request queue 350 while corresponding translation requests are placed in TLB lookup-request queue 362 and dispatched to TLB 370. If the TLB misses, page-miss handler 380 performs a page-table walk. After the translation completes, the resulting physical page number is returned to and updates the associated entry in data-prefetch request queue 350. Topp, Fig. 3, [0056]–[0060], [0067]–[0068].
Alexander teaches associating each buffered prefetch request with its outstanding translation using match tags 411A–411N. A match tag can identify a particular translation request, a translation-queue position, or a request currently being handled by the address-translation logic. Alexander, Fig. 4B, [0014], [0019]–[0021], [0030]–[0032].
Chang further teaches that an acknowledgment associated with completion of a translation may contain a tag that is matched to a particular buffer or scheduler entry. Chang, [0034]. Chang’s MMU provides a table-walk-complete acknowledgment identifying when the corresponding translation condition has cleared. Chang, Fig. 2, [0037], [0043]–[0045], [0057].
It would have been obvious to include Alexander’s match-tag or entry identifier in Topp’s translation request so that the physical-page-number response could be routed to the correct outstanding-prefetch-buffer entry. Topp expressly returns a PPN to the corresponding data-prefetch request queue entry, and Chang expressly teaches using a tag to associate a completion acknowledgment with a particular buffered request. Carrying the entry identifier with the request and returning it with the response represents a predictable tagged-transaction implementation that permits multiple translation requests to remain outstanding without ambiguity.
Accordingly, the combination teaches wherein: the prefetch outstanding buffer is configured to send a virtual-to-physical address translation request corresponding to a prefetch virtual address candidate of the one or more prefetch virtual address candidates to a memory management unit (MMU); and the virtual-to-physical address translation request includes an outstanding translation buffer identifier (OTB ID) associated with a prefetch virtual address of the prefetch virtual address candidate.
Regarding claim(s) 7 and 17, Alexander teaches monitoring the address-translation logic and translation queue for completion of the translation identified by the match tag. Upon completion, the associated prefetch request is reissued from prefetch buffer 206/406 into pipeline 202/402. Alexander, [0014], [0017], [0019]–[0022], [0033]; claims 2 and 7.
Chang teaches representing a buffered operation by a replay-wait state while the translation remains outstanding. Receipt of the corresponding acknowledgment changes the operation to a valid state in which it is eligible for reissuance. Chang, Fig. 3, [0052], [0054]–[0057]. Using Chang’s express state terminology in Alexander’s tagged prefetch buffer would have been an obvious implementation choice: when a translation-completion response containing the corresponding entry identifier is received, the entry is marked valid or ready for replay.
Claim 7 is written disjunctively. The combined references teach at least the first alternative: marking the prefetch virtual-address candidate ready for replay based on a response identifying the corresponding outstanding request and indicating completion of the virtual-to-physical translation.
Regarding claim(s) 8 and 18, Alexander explains that prefetch requests are non-architectural and may be discarded when the processor resources necessary to complete them are unavailable. Alexander, [0012]. Topp similarly explains that conventional data prefetchers drop prefetch requests that cannot obtain the required translation and identifies both page faults and failure to timely deliver a physical page number as failure conditions. Topp, [0003], [0056], [0060].
Chang teaches that failure to locate a translation in the page tables results in an exception. Chang, [0043].
It would have been obvious to drop Alexander’s corresponding buffered prefetch candidate when the MMU response indicates a page fault or inability to accommodate the translation request. Because a prefetch request does not affect architecturally observable execution, retaining a request that cannot legally or presently be translated would unnecessarily consume buffer capacity and could repeatedly generate the same fault. Dropping the request would predictably free the entry and avoid useless replay activity.
The combination therefore teaches dropping the candidate when the translation cannot be accommodated or encounters a translation page fault.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Alexander et al. (US 2013/0339650; hereinafter Alexander) in view of Topp et al. (US 2014/0281351; hereinafter Topp), and further in view of Pham et al. (US 10,754,782; hereinafter Pham).
Regarding claim(s) 10, Alexander in view of Topp teaches the prefetcher of claim 1, including the separate prefetch outstanding buffer and MMU having page tables and table-walking hardware.
Pham teaches a data cache unit having fill buffer 134. When a storage request misses the data cache, the request is sent to fill buffer 134 for servicing; an entry is assigned to the missed request, and the fill buffer initiates a request into the memory subsystem (Pham, Fig. 1; col. 5, ll. 13–27). Pham also teaches using a prefetcher to obtain cache lines expected to be used by storage requests (Pham, col. 6, ll. 1–11).
It would have been obvious to use Pham’s known fill-buffer/MSHR arrangement as the request buffer associated with Alexander’s prefetch mechanism because fill buffers conventionally retain outstanding cache-line requests.
A POSITA would understand a fill-buffer / MSHR entry to contain or be associated with the virtual address of the missed request, so the candidate generation step is a routine extraction. Applying Alexander’s prefetch outstanding buffer to virtual addresses associated with such line-fill requests when the translation buffer is unavailable would preserve the requests for later replay and avoid discarding useful prefetches.
Accordingly, the combination teaches or suggests the additional limitations of claim 10 - the buffer corresponds to one or more line fill buffers (Pham’s fill buffer 134) , and the prefetch outstanding buffer is configured to receive the one or more prefetch virtual address candidates based on one or more virtual addresses for data associated with the one or more line fill buffers based on a translation buffer in a memory management unit (MMU) being unavailable (Alexander’s retention logic applied to the VA already present in (or associated with) the fill-buffer entry).
Regarding claim(s) 11, Alexander in view of Topp teaches the prefetcher of claim 1. Alexander teaches translation queue 409 and teaches monitoring movement and completion of entries in that queue. Prefetch requests in prefetch buffer 406 are associated with translation-queue entries by match tags, and the prefetch requests are reissued when the associated queued translation leaves the pending state through completion. Alexander, [0014], [0018]–[0022].
Pham teaches that a store buffer may be a first-in, first-out buffer, with storage requests entered in program order, and that each storage request includes an address identifying a storage location (Pham, col. 5, ll. 1–10). Pham also teaches removing requests from the buffer and redispatching selected requests for further processing (Pham, col. 7, ll. 48–55; col. 9, ll. 35–55; claim 3).
It would have been obvious to provide the address associated with a request displaced or removed from Pham’s FIFO buffer to Alexander’s prefetch outstanding buffer when the request cannot proceed because translation resources are unavailable.
FIFO miss queues / store buffers routinely age or evict entries; once an entry is selected for removal and the associated translation is unavailable, forwarding the VA to the already-present outstanding buffer (Alexander) is a predictable way to avoid losing the prefetch opportunity. A POSITA would recognize that when a FIFO entry is being displaced and the request cannot proceed because translation resources are unavailable, the natural place to preserve the address is Alexander’s outstanding buffer rather than simply discarding it.
The combination therefore suggests a FIFO-buffer embodiment and the additional limitations of claim 11 - the buffer corresponds to one or more first-in first-out (FIFO) buffers, and the prefetch outstanding buffer is configured to receive the one or more prefetch virtual address candidates based on eviction of data associated with one or more virtual address of the one or more prefetch virtual address candidates from the one or more FIFO buffer.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM 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, TIM VO can be reached on (571)272-3642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRACY C CHAN/ Primary Examiner, Art Unit 2138
Prosecution Insights