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 Arguments
Applicant’s arguments, filed 01/16/2026 with respect to the 112 rejection have been fully considered and are persuasive. The 112 rejection of claims 1-21 has been withdrawn.
Applicant’s arguments otherwise with respect to claims 1-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specification
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract contains the legal terms “embodiment” and “embodiments” and should be removed/replaced.
Claim Objections
Claims 1, 3-8, 10, and 15-21 are objected to because of the following informalities: The claims contain intended use language and needs to be changed to active language. For example, several claims states “to perform,” “to comprise,” to write,” “to be based,” “to selectively,” “to adjust” appropriate correction is required.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-21 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Hooker et. al. (TW 201631479 A published 2016-09-01) and filed 11-25-2015), hereinafter “Hooker.”
As to claims 1, 8, and 15, Hooker discloses:
receiving respective values of first parameters during a runtime of a processor comprising multiple prefetchers (Hooker: processor includes two prefetchers (prefetcher 0 120-0 and prefetcher 1 120-1), and describes embodiments with more than two prefetchers. (Fig. 1; ¶ “Processor 100 includes two prefetchers, prefetcher 0 120-0 and prefetcher 1 102-1”);
and multiple model specific registers (MSRs), (Hooker: explicitly lists model-specific registers (MSRs) as an interface for changing parameters: “the foregoing coefficients may include … change with operation, such as by the processor’s microcode, system software (eg, mode-specified register (model-specific) Registers, MSRS) wherein respective values of the first parameters are received from a software process which is executed with the processors (Hooker: system/software driven provisioning of scores/configuration at runtime — Fig. 11 step 1102–1104: “system … detects a new process … The system software may provide information to the processor … prefetcher 102 fills the score … previously generated based on offline analysis of the program …” Also: processor may obtain program-specific values from memory when PCID/process context changes (Fig.11 description). Hooker expressly discloses software (device driver/system software) providing parameter values at runtime tied to processes/phase identifiers) wherein the first parameters each correspond to a different respective prefetch control of a plurality of prefetch controls which each correspond to a different respective one of the multiple prefetchers; (Hooker: Per-prefetcher scores and per-entry control: memory access type score table 106 is organized per prefetcher (two-dimensional array: columns for each prefetcher; rows for MATs) (Fig.1 and description). Each prefetcher has entry state with active level register 212 controlling aggressiveness and other control fields (Fig.2: active level register 212, MAT bit mask 216, prefetch state 218). The grouping MATs and per-group parameters (per-prefetcher parameters). The per-prefetcher control parameters (scores / active level / MAT groups) that correspond to “prefetch controls” per prefetcher);
storing the respective values of the first parameters to the multiple MSRs during the runtime; (Hooker: that system software / microcode can update prefetch parameters and identifies MSRs as a configuration channel (see paragraph referencing MSRs). Fig. 11/14: MAT score update unit 1416 is updated when a process/phase is detected and “prefetcher 102 fills the score into memory access type score table 106” — and text states configuration values can be loaded from system software/drivers (runtime) and
based on the respective values of the first parameters, configuring each prefetch control of the plurality of prefetch controls; (Hooker: Active level register 212 of an entry is set from the score (Fig.3 step 318; Fig.9 steps 912 / 316 / 318; Fig.10 steps 1018/1019), score values determine active level (aggressiveness) and other prefetcher parameters. The score table 106 maps scores to MATs and is used to set per-entry active levels and behavior. Direct mapping: Hooker teaches using software/system-supplied or dynamically computed scores to configure prefetcher control state) to be applied only to respective operations of the multiple prefetchers which are to be based on a first workload of one or more other software processes,(Hooker: Fig.11 step 1102–1104: system detects new process and provides program-specific score values; Fig.13-14: phase detector 1414 and MAT score update unit 1416 load new MAT scores for a detected phase/program; Fig.12 MAT bit-mask and entry allocation allow selective application per memory access type and per memory region);
wherein configuring each of the plurality of prefetch controls comprises adjusting the multiple prefetchers during the runtime, based on respective values of the first parameters; (Hooker:(continuous scoring in Fig.10; score updates on entry eviction in Fig.8 step 804–806). Fig.9 shows MAT counters triggering updates to active level. Fig.10 shows continuously generated scores used to set active level. Fig.8 shows runtime generation of scores from counters and updating table 106 wherein the runtime adjustments of the prefetcher are based on parameter values).
As to claims 2, 9, and 16, Hooker discloses:
wherein the circuitry is further to: limit access of the multiple MSRs based on a most trusted privilege level (Hooker: claim 10, The processor of claim 9, the source of the memory access associated with the plurality of memory access types includes at least three of the following: an integer instruction, a symbol instruction, a seek, a fusion instruction , load instruction, store instruction, segment descriptor load, media instruction, non-transient access instruction, stack access instruction, multiple prefetch from different sources, bit address correction load/store instruction, multiple different Processor privilege level instructions, asymmetric check load instructions, zero fill load instructions, and non-transitory store instructions generated by mask transfer instructions).
As to claims 3, 10, and 17, Hooker discloses:
wherein the multiple prefetchers comprise a first prefetcher and a second prefetcher; and
the plurality of prefetch controls comprise: ,(Hooker: Fig.11 step 1102–1104: system detects new process and provides program-specific score values; Fig.13-14: phase detector 1414 and MAT score update unit 1416 load new MAT scores for a detected phase/program; Fig.12 MAT bit-mask and entry allocation allow selective application per memory access type and per memory region);
a first prefetch control to selectively enable or disable prefetches by the first prefetcher based on the first workload; (Hooker: Fig. 3, step 312; per-prefetcher control (scores, thresholds, active level, and flags), which selectively disables or enables the first prefetcher’s prefetches based on workload (MAT / program/phase) and
a second prefetch control to selectively enable or disable prefetches by the second prefetcher based on the first workload (Hooker: Fig. 3, steps 314–318; Fig. 4, step 404: the same mechanisms are disclosed for the second prefetcher via its own column in the score table; Fig. 3, steps 306, 308; “disable” as suppression/deference (not allocating an entry and “listening” to the other prefetcher) and via explicit flags (e.g., disabling next-line prefetch).
As to claims 4, 11, and 18, Hooker discloses:
adjust a throttle (Hooker: active level/aggressiveness, 212) of a first prefetcher at runtime based on one of the value respective values of the first parameters;(Hooker: (Fig. 2 description; paragraphs describing active level 212 and examples such as prefetch number, max distance, and resource-aware thresholds. The active-level/“aggressiveness” setting that controls how much a prefetcher issues (e.g., number of prefetches, maximum prefetch distance, or resource-sensitive behavior); Fig. 11, Fig. 13–14 and the paragraph describing MSRs), so the active level can be adjusted based on a software-provided parameter value during execution).
As to claims 5, 12, and 19, Hooker discloses:
adjust a filter (Hooker: bit mask, 216) of a first prefetcher at runtime based on one of the respective values of the first parameters; (Hooker: control logic 222 fills MAT bit mask 216 on allocation and that the control logic can “dynamically update the MAT bit mask 216” while the prefetcher is operating (Fig. 12 description; Scores can be updated continuously from runtime counters (MYHIT/NOTUSED/OTHERHIT — Fig. 8, Fig. 10) or provided by system software/microcode/MSRs (Fig. 11, Fig. 13–14).
As to claims 7, 14, and 21, Hooker discloses:
adjust an internal queue threshold (Hooker: resource usage) of a first prefetcher at runtime (Hooker: (runtime: software/MSR or dynamic counters) based on one of the respective values of the first parameters (Hooker: (parameters: scores/flags)); (Hooker: Fig.3 step 318; Fig.9 steps 912/316; Fig.10 steps 1018/1019; (Fig.8 steps 804–806; Fig.11 steps 1102–1104; Fig.13–14 MAT score update unit 1416)).
As to claims 6, 13, and 20, Hooker discloses:
adjust a threshold of a first prefetcher at runtime based on one of the respective values of first parameters; (Hooker: (parameters: scores/flags); claims 7, 14, and 21 claim a specific threshold (“an internal queue threshold”) while this claim 6 is a broad threshold, therefore the responses to claim 7, 14, and 21 are deemed to apply to claims 6, 13, and 20).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES RONES whose telephone number is (571)272-4085. The examiner can normally be reached M-F 9-5:30pm.
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, Cordelia Zecher can be reached at 571-272-7771. 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.
CHARLES RONES
Supervisory Patent Examiner
Art Unit 2136
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168