DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1, 3-9, 11, and 20 have been amended.
Claims 1-20 have been examined.
The claim objections in the previous Office Action have been addressed and are withdrawn.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 8, 2025 has been entered.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Non-patent literature titled, “Access Map Pattern Matching for High Performance Data Cache Prefetch” by Ishii et al. (hereinafter referred to as “Ishii”) in view of US Patent 11,204,878 by Pusderis et al. (previously cited and hereinafter referred to as “Pusderis”).
Regarding claims 1, 11, and 20, taking claim 1 as representative, Ishii discloses:
a processing system, comprising: a load-store unit (Ishii discloses, at p. 16, Table 3, and related description, a processor having a load queue and store queue, which discloses a load-store unit.); and
a prefetcher connected to the load-store unit, the prefetcher including (Ishii discloses, at p. 2, a prefetcher, which discloses being connected to the load-store unit.).:
…a plurality of subzones, and each subzone has a plurality of cache lines (Ishii discloses, at Figure 2 and related description, zones having a number of cache lines, which discloses subzones.); and
an access map for each subzone, wherein each bit position represents a cache line in the plurality of cache lines (Ishii discloses, at p. 6, a memory access map for each hot zone, with “each entry in the bitmap-like data structure” being mapped to a cache line, which discloses each bit position represents a cache line.),
wherein the prefetcher is configured to: determine whether a demand request matches…[a prefetch engine] the demand request being a memory access for a particular address, wherein determining whether the demand request matches…[the prefetch engine] includes determining whether the particular memory address lies within the zone associated with…[the prefetch engine] (Ishii discloses, at pp. 6-7, determining whether a memory access for a particular memory location in particular zone is observed, which discloses a memory access for a particular address and determining whether the particular address lies within a given zone.),
wherein …[the prefetch engine] is configured to: update, with respect to the demand request, a bit position in an access map of a subzone managed by the matching prefetch engine (Ishii discloses, at pp. 6-7, updating the memory access map in response to a memory access, which discloses with regard to a demand request.),
determine a pattern from an access map of a subzone managed by the matching prefetch engine when a defined number of demand requests have been matched to the subzone managed by the matching prefetch engine (Ishii discloses, at p. 9, determining a pattern based on a number of demand requests matching.), and
generate a prefetch request based on at least the determined pattern (Ishii discloses, at p. 9, generating prefetch requests based on the pattern.).
Ishii does not explicitly disclose a plurality of prefetch engines, wherein each prefetch engine is associated with a zone, each zone comprising a plurality of the aforementioned subzones.
However, in the same field of endeavor (e.g., prefetch) Pusderis discloses:
a plurality of prefetch engines, each associated with a zone (Pusderis discloses, at Figures 3 and 4 and related description, a plurality of prefetch engines, each of which is allocated to a respective sub-region.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Ishii to include Pusderis’s multiple prefetch engines in order to improve performance by increasing prefetching capabilities. Duplicating prefetchers and dividing work between the multiple prefetchers allows faster performance.
Regarding claims 2 and 12, taking claim 2 as representative, Ishii, as modified, discloses the elements of claim 1, as discussed above. Ishii also discloses:
the prefetcher further comprises a prefetch map for each subzone, wherein each bit position represents a cache line in the plurality of cache lines, and wherein the prefetcher is configured to update, with respect to a generated prefetch request, a bit position in a prefetch map for a subzone in a matching prefetch engine (Ishii discloses, at p. 7, a memory access map for each hot zone and updating a bit in a corresponding entry in response to a prefetch request.).
Regarding claim 3, Ishii, as modified, discloses the elements of claim 2, as discussed above. Ishii also discloses:
the prefetcher is further configured to: determine a demand confirmation when a demand request hits a prefetch map (Ishii discloses, at Table 1 and related description, updating the state in response to a good prefetch, which discloses determining a demand confirmation.).
Regarding claims 4 and 17, taking claim 4 as representative, Ishii, as modified, discloses the elements of claim 3, as discussed above. Ishii also discloses:
the prefetcher is further configured to: maintain a counter for a number of demand confirmations for each prefetch engine (Ishii discloses, at Table 1 and related description, determining the number of good prefetches, which discloses a counter for demand confirmations.); and
increase a prefetch distance for a prefetch engine when the counter meets a threshold, wherein the prefetch distance determines how far ahead a prefetch request stream is relative to an associated demand stream (Ishii discloses, at Table 1 and related description, adjusting the prefetch degree based on the metrics, which discloses increasing distance based on a threshold number of good prefetches.).
Regarding claims 5 and 18, taking claim 5 as representative, Ishii, as modified, discloses the elements of claim 2, as discussed above. Ishii also discloses:
the prefetcher is further configured to: determine a demand mis-confirmation when a demand request misses a prefetch map (Ishii discloses, at Table 1 and related description, determining a prefetch accuracy, which discloses determining demand mis-confirmations.); and
retrain a prefetch engine with another pattern when a number of demand mis-confirmations meets a threshold (Ishii discloses, at Table 1 and related description, adjusting the prefetch based on the metrics, which discloses retraining based on a threshold number of misses.).
Regarding claims 6 and 13, taking claim 6 as representative, Ishii, as modified, discloses the elements of claim 1, as discussed above. Ishii also discloses:
the prefetcher is further configured to: allocate a prefetch engine and a subzone for a first demand request, wherein the first demand request is an anchor point for an associated access map (Ishii discloses, at Figure 4 and related description, determining a first access in a first zone, which discloses allocating a prefetch engine and subzone and that the first demand request is an anchor point for the associated map.);
identify a direction of a demand request stream based on a second demand request and the anchor point (Ishii discloses, at Figure 4 and related description, determining second and third accesses are at higher addresses than the first access, which discloses determining a direction based on a second demand request and the anchor point.); and
confirm the direction of the demand request stream based on a third demand request (Ishii discloses, at Figure 4 and related description, determining second and third accesses are at higher addresses than the first access, which discloses confirming the direction.).
Regarding claims 7 and 14, taking claim 7 as representative, Ishii, as modified, discloses the elements of claim 6, as discussed above. Ishii also discloses:
the prefetcher is further configured to: determine a leading edge pointer based on a most recent demand request in the direction of the demand request stream (Ishii discloses, at p. 13, determining the edge of the memory map.);
shift subzone associated with the leading edge pointer to align the leading edge pointer in a match register (Ishii discloses, at p. 13, aligning at the edge, which discloses shifting, and, at p. 12, a three zone concatenated map, which discloses a match register.);
divide the match register evenly (Ishii discloses, at p. 13, employing a copy of pattern matching logic, which discloses dividing the match register evenly.);
compare one half to the other half to find a pattern (Ishii discloses, at p. 13, generating forward and backward versions of addresses, which discloses comparing one half to the other.); and
repeat the divide and compare for a decremented number of bits (Ishii discloses, at p. 9, pattern matching involves checking addresses between a requested address and a maximum, which discloses comparing for a decremented number of bits.).
Regarding claims 8 and 15, taking claim 8 as representative, Ishii, as modified, discloses the elements of claim 1, as discussed above. Ishii also discloses:
the bit position in the access map is updated when the demand request is a cache miss (Ishii discloses, at Table 1 and related description, updating the state in response to a cache miss.).
Regarding claims 9 and 16, taking claim 9 as representative, Ishii, as modified, discloses the elements of claim 1, as discussed above. Ishii also discloses:
the bit position in the access map is updated when the demand request is a cache hit and a matching prefetch engine is trained, where a trained prefetch engine is prefetching based on a determined pattern (Ishii discloses, at Table 1 and related description, updating the state in response to a good prefetch, which discloses a hit on a prefetched, i.e., trained, value.).
Regarding claims 10 and 19, taking claim 10 as representative, Ishii, as modified, discloses the elements of claim 1, as discussed above. Ishii also discloses:
the prefetcher is further configured to process out-of-order demand requests (Ishii discloses, at p. 3, operating in an optimized environment, which discloses processing out-of-order demand requests.).
Response to Arguments
On pages 12-13 of the response filed December 8, 2025 (“response”), the Applicant argues, “Applicant submits that the newly added features in claim 1 are not taught by Ishii and Hasbun, considered individually or in combination. The Examiner's rejection is based on interpreting the "prefetch engine" of Applicant's claim 1 as being taught by the "prefetch counter" of Hasbun. The Examiner argues that Applicant's specification is not read into the claims and that the "plain meaning of a prefetch engine is subject to broad interpretation, encompassing any element used to 'drive' prefetch". Applicant has amended the claims to explicitly recite the functional limitations of the "prefetch engine", thereby distinguishing it from a passive "counter" and overcoming the Examiner's interpretation. The amended claims require that the "prefetch engine" itself is the active hardware unit configured to (1) manage its subzones, (2) determine a pattern from its subzones' access maps, and (3) generate a prefetch request. This is not taught by the cited art. Hasbun's "prefetch counter" is a passive data value or parameter that is read by a controller. The counter itself performs no actions. It does not "manage" subzones, "determine" patterns, or "generate" requests, as the amended claims now require the "engine" to do. In Hasbun, a central "controller" performs these functions based on the value of the counter. Ishii, the primary reference, teaches a single, centralized "prefetch generator" that processes all the maps. Ishii does not teach a "plurality of prefetch engines" where each engine independently manages its own zone and performs the pattern matching and generation functions for that zone, as now recited. Thus, the combination of Ishii's centralized logic with Hasbun's passive counter fails to teach or suggest the claimed invention. The combination does not teach a "plurality of prefetch engines" where each engine is an active, functional hardware unit that manages its own subzones, determines patterns from those subzones' maps, and generates prefetch requests.”
These remarks have been fully considered and, in light of the claim amendments presented in the response, are deemed persuasive. Please see above for new grounds of rejection of the amended claims. Pusderis discloses multiple prefetch engines associated with particular regions, which discloses the newly amended limitations.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure.
US 20230063123 by Hyun discloses a plurality of prefetchers corresponding to respective zones, cache rows.
US 20060112229 by Moat discloses a plurality of prefetch address generators corresponding to sub-regions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAWN DOMAN whose telephone number is (571)270-5677. The examiner can normally be reached on Monday through Friday 8:30am-6pm Eastern Time.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta can be reached on 571-270-3995. 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.
/SHAWN DOMAN/Primary Examiner, Art Unit 2183
Prosecution Insights