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 .
Claims 1, 3-11, 13-19, and 21-26 have been examined.
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, 3, 9-11, 13, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 20130339699 by Blasco et al. (hereinafter referred to as “Blasco”) in view of US Publication No. 2024/0020127 by Tran (hereinafter referred to as “Tran”).
Regarding claims 1, 10, 11, and 19, taking claim 1 as representative, Blasco discloses:
a processor-based device, comprising: an instruction processing circuit configured to process an instruction stream in an instruction pipeline (Blasco discloses, at Figure 2 and related description, a core, which discloses an instruction processing unit configured to process an instruction stream in an instruction pipeline.); and
the instruction processing circuit comprising an instruction fetch circuit …the instruction fetch circuit configured to: generate a fetch bundle comprising a plurality of fetched instructions from the instruction stream, wherein a last fetched instruction of the plurality of fetched instructions is a predicted-taken branch instruction (Blasco discloses, at Figure 2 and related description, a fetch circuit having a loop buffer, which discloses generating a fetch bundle comprising a plurality of fetched instructions from the instruction stream. Blasco also discloses, at ¶ [0052], identifying a loop based on a backward branch. As disclosed at ¶ [0036], the fetch unit includes branch prediction hardware, which discloses that the backward branch is a predicted taken branch instruction.);
identify the plurality of fetched instructions as a loop iteration… (Blasco also discloses, at ¶ [0052], identifying a loop.);
determine that at least one loop iteration copy fits within the fetch bundle (Blasco discloses, at Figure 7 and related description, packing multiple iterations into the loop buffer, which discloses determining that at least one loop iteration copy fits within the fetch bundle.); and
responsive to determining that the at least one loop iteration copy fits within the fetch bundle, store the at least one loop iteration copy within the fetch bundle (Blasco discloses, at Figure 7 and related description, packing multiple iterations into the loop buffer, which discloses storing at least one loop iteration copy within the fetch bundle.).
Blasco does not explicitly disclose
the instruction processing circuit further comprises a branch target buffer (BTB); and the aforementioned identifying involves determining that a program counter (PC) of the fetch bundle results in a hit in the BTB; and determining that a target address of the predicted-taken branch instruction corresponds to the PC of the fetch bundle.
However, in the same field of endeavor (e.g., loops) Tran discloses:
a branch target buffer (BTB) (Tran discloses, at Figure 1 and related description, a branch target buffer (BTB).); and
determine that a program counter (PC) of the fetch bundle results in a hit in the BTB (Tran discloses, at ¶ [0026], the BTB stores entry-point addresses, which discloses a PC of the fetch bundle. Tran also discloses, at ¶ [0038], using an entry point address to perform look ups into the BTB, which discloses hitting in the BTB.); and
determine that a target address of the predicted-taken branch instruction corresponds to the PC of the fetch bundle (Tran discloses, at ¶ [0032], determining that the target of the branch is the same as the start address of the loop, i.e., the entry point address, which discloses determining that the target address corresponds to the PC of the fetch bundle.).
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 Blasco to include using a BTB, as disclosed by Tran, in order to provide efficient loop execution that consumes less power, has a simpler design, and is scalable with consistently high performance. See Tran, ¶ [0006].
Claims 4, 6-8, 14, 16-18, 22, and 24-26 are rejected under 35 U.S.C. 103 as being unpatentable over Blasco in view of Tran in view of US Publication No. 2014/0075156 by Blasco et al. (hereinafter referred to as “Blasco ‘156”).
Regarding claims 4, 14, and 22, taking claim 4 as representative, Blasco, as modified, discloses the elements of claim 1, as discussed above. Blasco also discloses:
the instruction processing circuit further comprises a conditional branch predictor (CBP) (Blasco discloses, at ¶ [0036], branch prediction hardware, which discloses a conditional branch predictor.); and
the instruction fetch circuit is further configured to… access the CBP… (Blasco discloses, at ¶ [0036], branch prediction hardware, which discloses accessing the conditional branch predictor.).
Blasco does not explicitly disclose generating a modified program counter (PC) for a branch instruction within each loop iteration copy of the at least one loop iteration copy based on an original PC of the branch instruction; and using the modified PC of the branch instruction.
However, in the same field of endeavor (e.g., instruction processing) Blasco ‘156 discloses:
generate a modified program counter (PC) based on an original PC of the branch instruction and using he modified PC (Blasco ‘156 discloses, at ¶ [0038] et seq., modifying an address of a branch instruction and using the modified address to access a branch predictor.).
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 Blasco to include accessing a branch predictor using a modified PC, as disclosed by Blasco ‘156 in order to improve performance by providing efficient access to branch prediction data.
Regarding claims 6, 16, and 24, taking claim 6 as representative, Blasco, as modified, discloses the elements of claim 4, as discussed above. Blasco does not explicitly disclose the instruction fetch circuit is configured to access the CBP using the modified PC of the branch instruction by being configured to use the modified PC of the branch instruction as one of an index and a tag for a branch prediction structure of the CBP.
However, in the same field of endeavor (e.g., instruction processing) Blasco ‘156 discloses:
using a modified program counter (PC) as an index and/or tag (Blasco ‘156 discloses, at ¶ [0073], using the modified address as an index and/or tag.).
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 Blasco to include accessing a modified PC as an index and/or tag, as disclosed by Blasco ‘156 in order to improve performance by providing efficient access to branch prediction data.
Regarding claims 7, 17, and 25, taking claim 7 as representative, Blasco, as modified, discloses the elements of claim 6, as discussed above. Blasco does not explicitly disclose the branch prediction structure of the CBP comprises one of a branch predictor table and the branch target buffer (BTB).
However, in the same field of endeavor (e.g., instruction processing) Tran discloses:
a branch target buffer (BTB) (a branch target buffer (BTB) (Tran discloses, at Figure 1 and related description, a branch target buffer (BTB).).
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 Blasco to include a BTB, as disclosed by Tran in order to improve performance by providing efficient access to branch prediction data.
Regarding claims 8, 18, and 26, taking claim 8 as representative, Blasco, as modified, discloses the elements of claim 4, as discussed above. Blasco does not explicitly disclose the instruction fetch circuit is further configured to, for each predicted-taken branch instruction within the fetch bundle, update one or more of a history register and a branch prediction structure of the CBP.
However, in the same field of endeavor (e.g., instruction processing) Blasco ‘156 discloses:
a pattern history table (PHT) (Blasco ‘156 discloses, at ¶ [0039], a pattern history table, which disclose updating one or more of a history register and a branch prediction structure of the CBP.).
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 Blasco to include updating history, as disclosed by Blasco ‘156 in order to improve performance by providing accurate branch prediction.
Claims 5, 15, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Blasco in view of Tran in view of Blasco ‘156 in view of US Publication No. 2007/0011406 by Takase et al. (hereinafter referred to as “Takase”).
Regarding claims 5, 15, and 23, taking claim 5 as representative, Blasco, as modified, discloses the elements of claim 4, as discussed above. Blasco does not explicitly disclose the instruction fetch circuit is configured to generate the modified PC for the branch instruction by being configured to invert one or more bits of the original PC of the branch instruction.
However, in the same field of endeavor (e.g., addressing) Takase discloses
inverting one or more bits of an address (Takase discloses, at ¶ [0059] et seq., inverting one or more bits of an address.).
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 Blasco to include inverting bits, as disclosed by Takase, in order to improve performance by enabling flexible modification of which entries correspond to which addresses.
Response to Arguments
On page 9 of the response filed August 6, 2026 (“response”), the Applicant argues, “In rejecting claim 1, the Office Action on page 3 acknowledges that Blasco "does not explicitly disclose" "a branch target buffer (BTB)" or that the recited identifying "involves determining that a program counter (PC) of the fetch bundle results in a hit in the BTB; and determining that a target address of the predicted-taken branch instruction corresponds to the PC of the fetch bundle," but contends that Tran provides these missing disclosures. However, Applicant respectfully submits that the combination of Blasco and Tran fails to establish a prima facie case of obviousness with respect to claim 1. Applicant first respectfully submits that the Office Action fails to provide the requisite articulated reasoning with rational underpinning to support the proposed combination of Blasco and Tran. The Office Action states on page 4 that it would have been obvious to modify Blasco to use a "BTB" "in order to provide efficient loop execution that consumes less power, has a simpler design, and is scalable with consistently high performance," citing paragraph 0006 of Tran. Applicant respectfully notes, however, that Tran achieves those benefits through a fundamentally different mechanism than claim 1 requires. Tran is directed to out-of-order (OOO) execution of loop instructions, in which a detected loop is "broken into 2 smaller loops, one to load data, and one to process data" so that iterations may execute out of order. Tran, 0011. Tran expressly provides that a detected loop "causes the instruction loop buffer in the instruction queue to issue only one iteration." Tran, 0031 (emphasis added). In contrast, claim 1 requires that, responsive to determining that "at least one loop iteration copy fits within the fetch bundle," the "instruction fetch circuit" "store the at least one loop iteration copy within the fetch bundle" (i.e., that more than one iteration of the loop be stored within the fetch bundle). Applicant respectfully submits that a person of ordinary skill in the art would have had no reason to incorporate Tran's single-iteration, OOO loop-handling scheme into Blasco, and further that doing so would run counter to Tran's own express operation of issuing only a single iteration. Moreover, because the combination would not yield the subject matter of claim 1, Applicant respectfully submits that the rejection rests on impermissible hindsight.”
Though fully considered, the Examiner respectfully disagrees. The limitations in question describe a specific way of identifying a loop iteration, i.e., determining a hit in a BTB, which indicates a branch, and determining a target address corresponds to the PC, which indicates branching back to a previously executed instruction, which discloses a loop. Blasco also discloses, e.g., at ¶ [0052], identifying a loop iteration. Blasco similarly identifies a backward branch and similarly uses a data structure to do so, i.e., a branch tracking table. See, e.g., ¶ [0054]. So the difference between Blasco’s disclosure and the claimed invention is the precise manner in which the loop iteration is detected. Blasco uses a branch tracking table instead of a branch target buffer.
Tran also discloses loop detection. See, e.g., ¶ [0031]. In doing so, Tran discloses keeping track of an entry point address, i.e., the PC of the fetch bundle, for comparison with the branch target address. As disclosed at ¶ [0023], entry point addresses and branch target addresses are stored in the BTB, which discloses that the comparison involves detecting that there is a hit in the BTB. As noted, Blasco’s loop detection requires a dedicated data structure, i.e., the branch tracking table. Tran, on the other hand, uses the BTB, which already exists for branch prediction. Therefore, Tran’s technique for identifying loop iterations provides an improvement resulting in an increase of efficiency for loop execution. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On pages 10-11 of the response the Applicant argues, “Applicant further respectfully submits that Tran does not disclose identifying a "plurality of fetched instructions" of a "fetch bundle" "as a loop iteration" "by being configured to" "determine that a program counter (PC) of the fetch bundle results in a hit in the BTB" and "determine that a target address of the predicted-taken branch instruction corresponds to the PC of the fetch bundle," as recited by claim 1. In the Response to Arguments section on page 7, the Office Action cites paragraphs 0031 and 0038 of Tran in contending that because Tran's loop- detecting steps are performed "the first time the loop is to be executed," "subsequent executions can use the information that has been entered into the BTB," such that Tran allegedly discloses "using the BTB to identify loops in the case when the entry point hits and the target address matches the entry point." However, Applicant respectfully notes that paragraph 0038 of Tran describes using an "entry point address" to "look up in a branch target buffer 26 ... to predict the target address of the branch instruction at the exit point of the basic block." In other words, Tran uses the "BTB" to perform branch target prediction and, once a loop is predicted, to launch 000 loop execution. See Tran, 0038, 0040. Applicant respectfully notes that Tran does not describe conditioning identification of a "fetch bundle" as a "loop iteration" on both (i) a hit of the "fetch bundle's" "PC" in the "BTB" and (ii) a determination that the "target address" of the "predicted- taken branch instruction" corresponds to that same "PC," as claim 1 requires. Applicant respectfully submits that the Examiner's characterization of Tran as "using the BTB to identify loops in the case when the entry point hits and the target address matches the entry point" is not disclosed by Tran but rather appears reconstructed from the language of claim 1 itself. Applicant additionally respectfully submits that neither reference, alone or in combination, discloses performing both claimed determinations to "identify the plurality of fetched instructions as a loop iteration." As noted above, the Office Action acknowledges that Blasco does not disclose the recited "BTB" or the two-part identification. Tran, for its part, writes loop information into its "BTB" as a result of detecting a loop and uses that "BTB" to predict branch targets and launch 000 execution (see Tran, 0032, 0038, 0040) rather than performing the claimed determinations on the "PC" of a generated "fetch bundle." Accordingly, Applicant respectfully submits that, even if combined, Blasco and Tran would not disclose or suggest at least claim l's recitation that the "instruction fetch circuit" "identif[ies] the plurality of fetched instructions as a loop iteration by being configured to" "determine that a program counter (PC) of the fetch bundle results in a hit inPage 10 of the BTB," and "determine that a target address of the predicted-taken branch instruction corresponds to the PC of the fetch bundle."”
Though fully considered, the Examiner respectfully disagrees. As discussed above, Tran discloses comparing entry point addresses and target addresses, which discloses determining that a given entry point address hits in the BTB. Using the BTB in this way enables efficient loop detection. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 12-13 of the response the Applicant argues, “In rejecting claim 5, the Office Action on page 6 relies on Takase as allegedly disclosing "inverting one or more bits of an address," citing paragraph 0059 et seq. of Takase, and asserts that it would have been obvious to modify Blasco "to include inverting bits, as disclosed by Takase, in order to improve performance by enabling flexible modification of which entries correspond to which addresses." However, Applicant respectfully submits that Takase fails to disclose or suggest this feature, and further that the Office Action has not articulated a proper basis for the proposed combination. Applicant first respectfully submits that Takase does not disclose or suggest generating a "modified PC" "for the branch instruction by being configured to invert one or more bits of the original PC of the branch instruction," as recited by claim 5. Applicant respectfully notes that Takase is not concerned with branch instructions, program counters, or branch prediction, but rather is directed to increasing the manufacturing yield of set-associative cache memories by selectively avoiding the use of defective cache entries. See Takase, Abstract. To that end, Takase describes an "index translation" circuit that inverts one or more bits of a cache index value (derived from a data-access address) before the index is used to select entries in the cache, so as to redistribute defective ("failed") entries among the cache indices. See Takase, 0058-0059. The bits that Takase inverts are thus bits of a cache index used to address a data cache for defect avoidance, not bits of an "original PC of [a] branch instruction" used to generate a "modified PC" for accessing a "conditional branch predictor," as recited by claim 5. Applicant thus respectfully submits that Takase does not disclose or suggest the feature for which it is cited. Applicant further respectfully submits that the Office Action fails to provide the requisite articulated reasoning with rational underpinning for combining Takase with Blasco, Tran, and Blasco '156. Takase's index-bit inversion exists solely to address a problem unrelated to claim 5 (namely, tolerating manufacturing defects in a set-associative data cache by changing which entries map to which indices). See Takase, 0057-0059. Applicant respectfully submits that a person of ordinary skill in the art seeking to generate a "modified PC" for a branch instruction in order to access a branch predictor would have had no reason to look to Takase's defect-avoidance index translation, and the Office Action's stated rationale ("enabling flexible modification of which entries correspond to which addresses") merely restates Takase's cache-defect purpose while divorcing it from the branch-prediction context of claim 5. Applicant respectfully submits that the proposed combination therefore rests on impermissible hindsight rather than any proper articulated reasoning.”
Though fully considered, the Examiner respectfully disagrees. The Applicant is arguing references individually. Takase is not cited as generating a modified PC. Instead, Blasco ‘156 discloses various functions for modifying a PC. See, e.g., Blasco ‘159 at ¶ [0038] et seq. Blasco ‘156 does not explicitly disclose one of the functions involves inverting a bit. However, Takase explicitly discloses modifying an address using bit inversion. See, e.g., ¶ [0059]. Together the references disclose the elements in question. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 13 of the response the Applicant argues, “Applicant further respectfully submits that the Office Action fails to provide the requisite articulated reasoning with rational underpinning for combining Takase with Blasco, Tran, and Blasco '156. Takase's index-bit inversion exists solely to address a problem unrelated to claim 5 (namely, tolerating manufacturing defects in a set-associative data cache by changing which entries map to which indices). See Takase, 0057-0059. Applicant respectfully submits that a person of ordinary skill in the art seeking to generate a "modified PC" for a branch instruction in order to access a branch predictor would have had no reason to look to Takase's defect-avoidance index translation, and the Office Action's stated rationale ("enabling flexible modification of which entries correspond to which addresses") merely restates Takase's cache-defect purpose while divorcing it from the branch-prediction context of claim 5. Applicant respectfully submits that the proposed combination therefore rests on impermissible hindsight rather than any proper articulated reasoning.”
Though fully considered, the Examiner respectfully disagrees. While Blasco ‘156 teaches various functions for address modification, Blasco ‘156 does not explicitly recite bit inversion. Bit inversion is an exceedingly simple mechanism to modify an address. It is all but inherent that modifying an address involves bit inversion. Without inverting at least some bits, the only possible modification is to change the length of the address. Nevertheless, in order to expedite prosecution, the Examiner chose to rely on the explicit teaching of Takase regarding inverting bits rather than Blasco ‘156’s implicit disclosure. It would be obvious to include Takase’s bit inversion in Blasco ‘156’s address modification because doing so dramatically increases the useful possibilities available for Blasco ‘156’s address modification. Accordingly, the Applicant’s arguments are deemed unpersuasive.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
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 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