DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is filed in response to Applicant’s Request for Continued Examination dated February 20, 2026. Claims 1, 10, and 16 are currently amended and claims 1, 3-4, 6, 8-10, 12-16, and 18-20 remain pending in the application and have been fully considered by Examiner.
The 35 USC 112 deficiencies suffered by claims 10 and 12-15 have been corrected and the rejections are withdrawn.
Applicant's arguments with respect to the prior art rejections have been considered, but are moot and/or not persuasive, as detailed below in the Prior Art Argument - Rejections section.
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 January 23, 2026, has been entered.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Prior Art Arguments – Rejections
Applicant’s arguments have been fully considered by Examiner, but are not persuasive, as follows:
With respect to claim 1, 10, and 16, Applicant’s argument that McFarling, Nexus, and Zeinolabedin do not teach “clearing” is moot in view of the new grounds of rejection presented herein. Specifically, Soundararajan teaches this limitation1.
Applicant also argues that “Clearing the buffer [of McFarling] (e.g., resetting to all zeros) would destroy this history and degrade the predictor's accuracy”2 and “Modifying McFarling to ‘clear the history buffer’ as claimed would render McFarling unsuitable for its intended purpose of accurate branch prediction, as it would erase the history data needed for subsequent predictions.”3 Examiner respectfully disagrees. McFarling discloses a branch history buffer that switches between two modes: (1) A shift mode where the branch history entry consists of a shift mode bit and a shift field storing “1”s and “0”s representing taken and not-taken branches; and (2) a count mode where the branch history entry consists of a count mode bit, a branch bias bit indicating the direction of the repeating branch pattern, and a count field storing the count of repeating branches4. When the repeating branch pattern ends, it changes from the count mode entry to the shift mode entry, which is set to the value one would expect if the encoder had stayed in shift mode5. Examiner acknowledges that McFarling does not appear to disclose “clearing” the count mode entry when the branch pattern ends and the branch history changes to the shift mode entry. However, Soundararajan teaches “clearing” a repeating branch history count when the repeating branch pattern ends6.
Modifying McFarling with Soundararajan, such that it clears the branch history count mode entry when the branch pattern ends, would not “render McFarling unsuitable for its intended purpose of accurate branch prediction”,7 because rather than erasing “the history data needed for subsequent predictions”8, as argued by Applicant, the combination would simply clear the branch history count mode entry, which the invention of McFarling does not require to be maintained. As recognized by Applicant at p. 8 of the Remarks, it is the expected shift mode value that is required9, which is not what is cleared responsive to the pattern ending. Examiner also notes that clearing the branch history count mode entry and switching to storing individual branch results (shift mode), as disclosed by the combination of McFarling and Soundararajan, is consistent with Applicant’s specification, which describes the history buffer as storing only the branch count when the history buffer is cleared responsive to an opposite branch result and then storing individual results of executed branches in the history buffer10.
Examiner further notes that modifying McFarling to clear the count mode entry would not inhibit switching from the count mode to the shift mode entry storing the expected shift value. On the contrary, clearing the count mode entry when the repeating branch pattern ends would help to prevent stale count mode entry data from carrying over when the branch history switches from the count mode to the shift mode.
For the above reasons, Applicant’s arguments are moot and/or not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claim 6, lines 1-2 recite “wherein the count is greater than the number of bits in the history buffer.” There is no previous recitation of a “number of bits in the history buffer.” Furthermore, parent claim 1 recites “the history buffer filling with bits indicating branches were consecutively taken” and later recites “clear the history buffer”. Thus, it is unclear whether “the number of bits in the history buffer” means the number of bits in the history buffer upon filling with bits indicating branches were consecutively taken, or after the history buffer is cleared, or the number of bits in the history buffer at some other point in time. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claim 6 as reciting “wherein the count is greater than a number of the bits indicating branches were consecutively taken”.
With respect to claim 19, lines 1-2 recite, with emphasis added, “wherein the trace encoder comprises a history buffer that stores results of branches being taken or not-taken” and parent claim 16 recites, with emphasis added, “a trace encoder comprising a history buffer”. It is unclear whether “a history buffer”, as recited in claim 19, is the same a “a history buffer”, as recited in parent claim 16, which renders the scope of the claim indefinite. For purposes of compact prosecution only, Examiner has interpreted claim 19 as reciting “wherein the history buffer stores results of branches being taken or not-taken”.
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 of this title, 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.
Claim 1, 3, 4, 6, 8-10, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over McFarling et al. (US 20010056531, hereinafter McFarling) in view of IEEE-ISTO, “The Nexus 5001 Forum™ Standard for a Global Embedded Processor Debug Interface Version 3.0” (hereinafter Nexus), Soundararajan et al. (US 20180285115, hereinafter Soundararajan), and Zeinolabedin et al., “Real-Time Hardware Implementation of ARM CoreSight Trace Decoder” (hereinafter Zeinolabedin).
With respect to claim 1, McFarling discloses An apparatus comprising (e.g., Fig. 9 along with associated text, e.g., Abstract, System for accurately predicting the outcome of conditional branch instructions subject to execution in a pipelined processor digital computer):
a processor core (Id.; [0062], As the branch continues to execute in the same direction, the count is incremented; Examiner notes that a processor core is necessary to execute branches as disclosed.); and
a encoder the processor core and comprising a history buffer, wherein the encoder is configured to (e.g., Fig. 9 and associated text, e.g., [0061-62], FIG. 9 illustrates a method known as shift-or-count encoding … the branch history entry is encoded with a count of how many times the branch has gone in the same direction … A mode bit 90 is reserved to switch between the conventional history storage (shift register) mode and the new counter mode … The following table illustrates the entries that toggle the shift-or-count encoder [encoder] from one mode to the other.):
start and maintain a count of branches that are consecutively taken when executed by the processor core responsive to the history buffer filling with bits indicating branches were consecutively taken, (e.g., Fig. 9 and associated text, e.g., [0061], For very long iteration loops, such as loops having an iteration count of 100, the branch history pattern is very long (e.g. TTTTTT [branches that are consecutively taken] . . . N); [0062], If the shift field 92 is either all zeroes or all ones, and the addressed branch goes the same direction again, the mode bit 90 and the count field 94 are set and the branch history table moves to count mode [start a count of branches that are consecutively taken when executed by the processor core responsive to the history buffer filling with bits indicating branches were consecutively taken]. In count mode, the branch history entry operates as a saturating counter, with one branch bias bit 96 showing the direction the branch usually goes (in this example, T [taken]), plus a count field 94. As the branch continues to execute in the same direction, the count is incremented [maintain a count of branches that are consecutively taken when executed by the processor core].);
determine that a subsequent branch executed by the processor core is not-taken (e.g., Fig. 9 and associated text, e.g., [0062], Finally, when the branch goes in the unusual direction [determine that a subsequent branch executed by the processor core is not-taken] … The following table illustrates the entries that toggle the shift-or-count encoder from one mode to the other … Count, direction=1 [branches that are consecutively taken] N [a subsequent branch executed by the processor core is not-taken] Shift: 11 . . . 10.); and
responsive to determining that the subsequent branch executed by the processor core is not-taken, and the history buffer (e.g., Fig. 9 and associated text, e.g., [0062], Finally, when the branch goes in the unusual direction, the mode bit 90 is set back to shift mode and the shift field 92 is set to the value one would expect if the encoder had stayed in shift mode … The following table illustrates the entries that toggle the shift-or-count encoder from one mode to the other … Count, direction=1 [branches that are consecutively taken] N [subsequent branch executed by the processor core is not-taken] Shift: 11 . . . 10 [switch to shift mode at the end of the loop, i.e., responsive to determining that the subsequent branch executed by the processor core is not-taken].).
Although McFarling discloses an encoder configured to maintain a count of consecutive taken branches, determine an opposite branch result, and responsive to the not-taken branch (see above), it does not appear to disclose the following, which is taught in analogous art, Nexus: trace … trace … without sending any message indicating the count … send a message including the count and a trace identifier associated with the processor core (e.g., Figure 3-2 and Figure 6-7 along with associated text, e.g., p. 2 § 1.2.3, multiple clients (processor cores …) on the embedded processor; p. 12, § 3.3, The Program Trace feature implements a Program Flow Change Model… The messages generated using this model are referred to as Branch Trace Messages [Program Trace feature, i.e., trace encoder]11; pp. 47-48, §4.3.13, the Repeat Branch Message may be transmitted to indicate how many times a branch repeated [send a message including the count] … The original branch message is only transmitted once, followed by the Repeat Branch Message … SRC…Client [processor core] that is source of message [trace identifier associated with the processor core]; Examiner notes that transmitting the original branch message followed by the Repeat Branch Message means that the count is not sent while the branch is repeating, i.e., without sending any message indicating the count, and the Repeat Branch Message is only sent once the branch stops repeating, i.e., responsive to determining that the subsequent branch executed by the processor core is not-taken.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus, such that a message with the count of repeated loop branches and a processor source identifier are sent for debugging, because it would allow developers “To assess whether embedded software is meeting the required performance level with acceptable impact to the system under development,” as suggested by Nexus (see p. 2, § 1.2.2).
Although McFarling discloses the history buffer (see above), it does not appear to disclose the following, which is taught in analogous art, Soundararajan: clear (e.g., Figs. 1, particularly, current pattern table (CPT) 130, and Fig. 3, along with associated text, e.g., Figs. 1, particularly, current pattern table (CPT) 130, and Fig. 3, along with associated text, e.g., [0020], CPT 130, in which each entry includes … a current pattern field (Curr Pattern) to track a current pattern … a counter and a flag may be associated with each CPT entry. The counter may keep a running count of the pattern length and the flag may indicate a terminating condition. Thus, the current pattern field may be used to store a count and a flag; [0022], A pattern may be terminated in response to the branch direction flipping from T to N or from N to T; therefore, such flips may be referred to as terminating conditions and the flags associated with CPT entries may be referred to as flip flags ... Finally, in response to the actual branch direction matching the flip flag, the current pattern may be terminated, which may include clearing or otherwise releasing the corresponding CPT entry [responsive to determining that the subsequent branch executed by the processor core is not-taken … clear].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of McFarling with the invention of Soundararajan, such that the branch history is cleared when the branch pattern ends and switches from count mode to shift mode, because this would help ensure that stale count mode data is not carried over to the shift mode.
Although McFarling as modified discloses a trace encoder and a processor core (see above), it does not appear to explicitly disclose the following, which is taught in analogous art, Zeinolabedin: connected to (e.g., Fig. 1 and Fig. 2, particularly the depiction of an ETM [trace encoder] with arrows from Arm Processor 1 [trace encoder connected to the processor core], along with associated text, e.g., p. 70, right col., CoreSight technology provides powerful standardized units to design and analyze complex SoCs by generating trace streams for various sources. As conceptually drawn in Figure 2a, there are two main trace-generating sources which are processor trace units (e.g., ETM) [trace encoder]; see also Table 1 on p. 70, which lists various ARM processor cores, such as the Cortex-M7.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trace data compression/decompression invention of Zeinolabedin because this would reduce trace overhead by generating “highly compressed” trace data that is decoded “in realtime to get meaningful messages,” as suggested by Zeinolabedin (see p. 69).
With respect to claim 10, McFarling discloses A method comprising:
starting, by a encoder comprising a history buffer, a count of branches that are consecutively taken when executed by a processor core responsive to the history buffer filling with bits indicating branches were consecutively taken (e.g., Fig. 9 and associated text, e.g., [0061], FIG. 9 illustrates a method known as shift-or-count encoding … For very long iteration loops, such as loops having an iteration count of 100, the branch history pattern is very long (e.g. TTTTTT [branches that are consecutively taken] . . . N); [0062], If the shift field 92 is either all zeroes or all ones, and the addressed branch goes the same direction again, the mode bit 90 and the count field 94 are set and the branch history table moves to count mode [starting a count of branches that are consecutively taken when executed by the processor core responsive to the history buffer filling with bits indicating branches were consecutively taken responsive to the history buffer filling with bits indicating branches were consecutively taken].);
maintaining the count of branches that are consecutively taken when executed by the processor core direction, the count is incremented [maintaining the count of branches that are consecutively taken when executed by a processor core].);
determining that a subsequent branch executed by the processor core is not-taken (e.g., Fig. 9 and associated text, e.g., [0062], Finally, when the branch goes in the unusual direction [determining that a subsequent branch executed by the processor core is not-taken] … The following table illustrates the entries that toggle the shift-or-count encoder from one mode to the other … Count, direction=1 [branches that are consecutively taken] N [branch executed by the processor core is not-taken] Shift: 11 . . . 10.); and
responsive to determining that the subsequent branch executed by the processor core is not-taken, and by the encoder, the history buffer (e.g., Fig. 9 and associated text, e.g., [0062], Finally, when the branch goes in the unusual direction, the mode bit 90 is set back to shift mode and the shift field 92 is set to the value one would expect if the encoder had stayed in shift mode … The following table illustrates the entries that toggle the shift-or-count encoder from one mode to the other … Count, direction=1 [branches that are consecutively taken] N [branch executed by the processor core is not-taken] Shift: 11 . . . 10 [switch to shift mode at the end of the loop, i.e., responsive to determining that the subsequent branch executed by the processor core is not-taken].).
Although McFarling discloses an encoder configured to maintain a count of consecutive taken branches, determine an opposite branch result, and responsive to the not-taken branch (see above), it does not appear to disclose the following, which is taught in analogous art, Nexus: trace … trace … without sending any message indicating the count … sending, by the trace encoder, a message including the count and a trace identifier associated with the processor core … trace (e.g., Figure 3-2 and Figure 6-7 along with associated text, e.g., p. 2 § 1.2.3, multiple clients (processor cores …) on the embedded processor; p. 12, § 3.3, The Program Trace feature implements a Program Flow Change Model… The messages generated using this model are referred to as Branch Trace Messages [Program Trace feature, i.e., trace encoder]12; pp. 47-48, §4.3.13, the Repeat Branch Message may be transmitted to indicate how many times a branch repeated [send a message including the count] … The original branch message is only transmitted once, followed by the Repeat Branch Message … SRC…Client [processor core] that is source of message [trace identifier associated with the processor core]; Examiner notes that transmitting the original branch message followed by the Repeat Branch Message means that the count is not sent while the branch is repeating, i.e., without sending any message indicating the count, and the Repeat Branch Message is only sent once the branch stops repeating, i.e., responsive to determining that the subsequent branch executed by the processor core is not-taken, sending, by the trace encoder, a message including the count and a trace identifier associated with the processor core).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus, such that a message with the count of repeated loop branches and a processor source identifier are sent for debugging, because it would allow developers “To assess whether embedded software is meeting the required performance level with acceptable impact to the system under development,” as suggested by Nexus (see p. 2, § 1.2.2).
Although McFarling discloses the history buffer (see above), it does not appear to disclose the following, which is taught in analogous art, Soundararajan: clearing (e.g., Figs. 1, particularly, current pattern table (CPT) 130, and Fig. 3, along with associated text, e.g., [0020], CPT 130, in which each entry includes … a current pattern field (Curr Pattern) to track a current pattern … a counter and a flag may be associated with each CPT entry. The counter may keep a running count of the pattern length and the flag may indicate a terminating condition. Thus, the current pattern field may be used to store a count and a flag; [0022], A pattern may be terminated in response to the branch direction flipping from T to N or from N to T; therefore, such flips may be referred to as terminating conditions and the flags associated with CPT entries may be referred to as flip flags … Finally, in response to the actual branch direction matching the flip flag, the current pattern may be terminated, which may include clearing or otherwise releasing the corresponding CPT entry [responsive to determining that the subsequent branch executed by the processor core is not-taken … clearing].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of McFarling with the invention of Soundararajan, such that the branch history is cleared when the branch pattern ends and switches from count mode to shift mode, because this would help ensure that stale count mode data is not carried over to the shift mode.
Although McFarling as modified discloses a trace encoder and a processor core (see above), it does not appear to explicitly disclose that the processor core is connected to the trace encoder. However, this is taught in analogous art, Zeinolabedin (e.g., Fig. 1 and Fig. 2, particularly the depiction of an ETM [trace encoder] with arrows from Arm Processor 1 [processor core connected to the trace encoder], along with associated text, e.g., p. 70, right col., CoreSight technology provides powerful standardized units to design and analyze complex SoCs by generating trace streams for various sources. As conceptually drawn in Figure 2a, there are two main trace-generating sources which are processor trace units (e.g., ETM) [trace encoder]; see also Table 1 on p. 70, which lists various ARM processor cores, such as the Cortex-M7.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trace data compression/decompression invention of Zeinolabedin because this would reduce trace overhead by generating “highly compressed” trace data that is decoded “in realtime to get meaningful messages,” as suggested by Zeinolabedin (see p. 69).
With respect to claim 16, McFarling discloses An apparatus (e.g., Fig. 9 along with associated text, e.g., Abstract, System for accurately predicting the outcome of conditional branch instructions subject to execution in a pipelined processor digital computer.) comprising:
a processor core (Id.; [0062], As the branch continues to execute in the same direction, the count is incremented; Examiner notes that a processor core is necessary to execute branches as disclosed.); and
a encoder comprising a history buffer and the processor core, wherein the encoder is configured to (e.g., Fig. 9 and associated text, e.g., [0061-62], FIG. 9 illustrates a method known as shift-or-count encoding … the branch history entry is encoded with a count of how many times the branch has gone in the same direction … A mode bit 90 is reserved to switch between the conventional history storage (shift register) mode and the new counter mode … The following table illustrates the entries that toggle the shift-or-count encoder [encoder] from one mode to the other.):
start and maintain a count of branches that are consecutively not-taken when executed by the processor core responsive to the history buffer filling with bits indicating branches were consecutively not-taken, ;
determine that a subsequent branch executed by the processor core that is taken (e.g., Fig. 9 and associated text, e.g., [0062], Finally, when the branch goes in the unusual direction [determine that a subsequent branch executed by the processor core that is taken] … The following table illustrates the entries that toggle the shift-or-count encoder from one mode to the other … Count, direction=0 [consecutively not-taken] T [branch that is taken] Shift: 00 . . . 01.); and
responsive to determining that the subsequent branch executed by the processor core is taken, and the history buffer (e.g., Fig. 9 and associated text, e.g., [0062], Finally, when the branch goes in the unusual direction [determining that the subsequent branch executed by the processor core is taken], the mode bit 90 is set back to shift mode and the shift field 92 is set to the value one would expect if the encoder had stayed in shift mode …. Count, direction=0 [consecutively not-taken] T [determining that the subsequent branch executed by the processor core is taken] Shift: 00 . . . 01 [switch back to shift mode at the end of the loop, i.e. responsive to determining that the subsequent branch executed by the processor core is taken].).
Although McFarling discloses an encoder configured to maintain a count of consecutive not-taken branches, determine an opposite branch result, and responsive to the not-taken branch (see above), it does not appear to disclose the following, which is taught in analogous art, Nexus: trace … trace … without sending any message indicating the count … send a message including the count and a trace identifier associated with the processor core (e.g., Figure 3-2 and Figure 6-7 along with associated text, e.g., p. 2 § 1.2.3, multiple clients (processor cores …) on the embedded processor; p. 12, § 3.3, The Program Trace feature implements a Program Flow Change Model… The messages generated using this model are referred to as Branch Trace Messages [Program Trace feature, i.e., trace encoder]13; pp. 47-48, §4.3.13, the Repeat Branch Message may be transmitted to indicate how many times a branch repeated [send a message including the count] … The original branch message is only transmitted once, followed by the Repeat Branch Message … SRC…Client [processor core] that is source of message [trace identifier associated with the processor core]; Examiner notes that transmitting the original branch message followed by the Repeat Branch Message means that the count is not sent while the branch is repeating, i.e., without sending any message indicating the count, and the Repeat Branch Message is only sent once the branch stops repeating, i.e., responsive to determining that the subsequent branch executed by the processor core is taken, send a message including the count and a trace identifier associated with the processor core.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus, such that a message with the count of repeated loop branches and a processor source identifier are sent for debugging, because it would allow developers “To assess whether embedded software is meeting the required performance level with acceptable impact to the system under development,” as suggested by Nexus (see p. 2, § 1.2.2).
Although McFarling discloses the history buffer (see above), it does not appear to disclose the following, which is taught in analogous art, Soundararajan: clear (e.g., Figs. 1, particularly, current pattern table (CPT) 130, and Fig. 3, along with associated text, e.g., [0020], CPT 130, in which each entry includes … a current pattern field (Curr Pattern) to track a current pattern … a counter and a flag may be associated with each CPT entry. The counter may keep a running count of the pattern length and the flag may indicate a terminating condition. Thus, the current pattern field may be used to store a count and a flag; [0022], A pattern may be terminated in response to the branch direction flipping from T to N or from N to T; therefore, such flips may be referred to as terminating conditions and the flags associated with CPT entries may be referred to as flip flags … Finally, in response to the actual branch direction matching the flip flag, the current pattern may be terminated, which may include clearing or otherwise releasing the corresponding CPT entry [responsive to determining that the subsequent branch executed by the processor core is taken … clear].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of McFarling with the invention of Soundararajan, such that the branch history is cleared when the branch pattern ends and switches from count mode to shift mode, because this would help ensure that stale count mode data is not carried over to the shift mode.
Although McFarling in view of Nexus discloses a trace encoder and a processor core (see above), it does not appear to explicitly disclose the trace encoder connected to the processor core. However, this is taught in analogous art, Zeinolabedin (e.g., Fig. 1 and Fig. 2, particularly the depiction of an ETM [trace encoder] with arrows from Arm Processor 1 [trace encoder connected to the processor core], along with associated text, e.g., p. 70, right col., CoreSight technology provides powerful standardized units to design and analyze complex SoCs by generating trace streams for various sources. As conceptually drawn in Figure 2a, there are two main trace-generating sources which are processor trace units (e.g., ETM) [trace encoder]; see also Table 1 on p. 70, which lists various ARM processor cores, such as the Cortex-M7.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trace data compression/decompression invention of Zeinolabedin because this would reduce trace overhead by generating “highly compressed” trace data that is decoded “in realtime to get meaningful messages,” as suggested by Zeinolabedin (see p. 69).
With respect to claim 3, Nexus further teaches wherein the branches include a direct branch, and wherein the direct branch is associated with a target address that is inferable from a program executed by the processor core (e.g., pp. 14-15, § 3.3.4, Because BTM for taken direct branches does not provide the target address, program trace for these application programs must be accomplished in a relative manner; p.38, § 4.3.4, The Direct Branch Message is output whenever there is a change of program flow and the target address is statically known caused by a branch [direct branch is associated with a target address that is inferable from a program executed by the processor core].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus for the same reason set forth above.
With respect to claim 4, McFarling also discloses encoder is configured to maintain a second count of branches that are consecutively not-taken when executed by the processor core, Count, direction=0 N [branch outcome, i.e., consecutively not-taken] Increment counter to limit [maintain a count].) and Nexus further teaches wherein the message is a first message, and wherein the trace encoder … and wherein the trace encoder is configured to send a second message indicating the second count (e.g., p. 47, § 4.3.13 Program Trace - Repeat Branch Message, When a series of instructions are executed instead of a single instruction (e.g. hardware loop), the Repeat Branch Message may be transmitted to indicate how many times a branch repeated [wherein the message is a first message, and wherein the trace encoder … and wherein the trace encoder is configured to send a second message indicating the second count].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus, such that messages are sent for both loops with repeating taken branches and loops with repeating not-taken branches, for the same reason set forth above.
With respect to claim 6, McFarling also discloses wherein the count is greater than the number of bits in the history buffer (e.g., Fig. 9 and associated text, e.g., [0061-62], High loop counts require too much branch history storage. For very long iteration loops, such as loops having an iteration count of 100, the branch history pattern is very long (e.g. TTTTTT . . . N) … Local branch information can be encoded by a new method that reduces the memory required by a local predictor stage… In count mode, the branch history entry operates as a saturating counter, with one branch bias bit 96 showing the direction the branch usually goes (in this example, T), plus a count field 94. As the branch continues to execute in the same direction, the count is incremented, up to the maximum count value that can be represented [wherein the count is greater than the number of bits in the history buffer].).
With respect to claims 8, 14, and 20, Zeinolabedin further teaches a trace decoder, wherein the trace decoder is configured to use the message to determine instructions that were executed by the processor core (e.g., Figs. 1-2 and 9 along with associated text, e.g., p. 69, right col., A new approach addresses these issues by realizing the debug platform consisting of “trace decoder” ... A trace decoder unit receives highly compressed trace data [use the message] and performs decoding in realtime to get meaningful messages [to determine instructions that were executed by the processor core]; see also pp. 70-76 for in-depth details of the decoder.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trace data compression/decompression invention of Zeinolabedin for the same reason set forth above.
With respect to claim 9, McFarling also discloses wherein the encoder is further configured to: receive, based on execution of a program by the processor core, instruction trace information of the processor core (e.g., Fig. 9 and associated text e.g., [0062], Local branch information can be encoded by a new method that reduces the memory required by a local predictor stage [receive, based on execution of a program by the processor core, instruction trace information of the processor core].), wherein: the instruction trace information of the processor core includes instruction type information (e.g., Fig. 9 and associated text e.g., [0062], When the mode bit is set, the remaining bits in the branch history entry are just the shifted branch history as previously described. If the shift field 92 is either all zeroes or all ones [receiving outcomes of executed branch instructions, i.e., the instruction trace information of the processor core includes instruction type information].); and the count is maintained based on the instruction trace information (e.g., Fig. 9 and associated text e.g., [0062], If the shift field 92 is either all zeroes or all ones, and the addressed branch goes the same direction again, the mode bit 90 and the count field 94 are set and the branch history table moves to count mode…As the branch continues to execute in the same direction, the count is incremented [count is maintained based on the instruction trace information].) and Nexus further teaches trace (e.g., Figure 3-2 and Figure 6-7 along with associated text, e.g., p. 12, § 3.3, The Program Trace feature [trace encoder] implements a Program Flow Change Model… The messages generated using this model are referred to as Branch Trace Messages.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus for the same reason set forth above.
With respect to claim 12, Nexus further teaches wherein the branches include direct branches, and wherein a direct branch is associated with a target address that is inferable from a program executed by the processor core (e.g., pp. 14-15, § 3.3.4, Because BTM for taken direct branches does not provide the target address, program trace for these application programs must be accomplished in a relative manner; p.38, § 4.3.4, The Direct Branch Message is output whenever there is a change of program flow and the target address is statically known caused by a branch [branches include direct branches, and wherein a direct branch is associated with a target address that is inferable from a program executed by the processor core].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus for the same reason set forth above.
With respect to claim 13, McFarling also discloses wherein the count is a first count (e.g., Fig. 9 and associated text, e.g., [0062], In count mode, the branch history entry operates as a saturating counter, with one branch bias bit 96 showing the direction the branch usually goes (in this example, T [taken]), plus a count field 94. As the branch continues to execute in the same direction, the count is incremented [wherein the count is a first count].), encoder is configured to maintain a second count of branches that are consecutively not-taken when executed by the processor core, wherein the message is a first message, wherein the trace … and wherein the trace encoder is configured to send a second message indicating the second count (e.g., p. 47, § 4.3.13 Program Trace - Repeat Branch Message, When a series of instructions are executed instead of a single instruction (e.g. hardware loop), the Repeat Branch Message may be transmitted to indicate how many times a branch repeated [wherein the message is a first message, wherein the trace encoder … and wherein the trace encoder is configured to send a second message indicating the second count].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus, such that messages are sent for both loops with repeating taken branches and loops with repeating not-taken branches, for the same reason set forth above.
With respect to claim 15, Zeinolabedin further teaches receiving, by the trace encoder from the processor core, instruction trace information based on execution of a program by the processor core (e.g., Fig. 1 and Fig. 2, particularly the depiction of an ETM [trace encoder] with arrows from Arm Processor 1 [receiving, by the trace encoder from the processor core, instruction trace information based on execution of a program by the processor core], along with associated text, e.g., p. 71, In ETMv4, there is a trace unit that monitors instruction [receiving, by the trace encoder from the processor core, instruction trace information based on execution of a program by the processor core] and data buses and generates separate instruction and data trace streams.); and compressing, by the trace encoder, the instruction trace information into the message (e.g., Figs. 1-2 and associated text, e.g., pp. 69-70, The recording trace combines an enormous amount of detailed debug information which is highly compressed …The first critical step to exploit debug trace stream, as shown in Figure 1, is to decode the compressed stream … CoreSight technology provides powerful standardized units to design and analyze complex SoCs by generating trace streams for various sources. As conceptually drawn in Figure 2a, there are two main trace-generating sources which are processor trace units (e.g., ETM) [compressing, by the trace encoder, the instruction trace information into the message]; p. 71, In ETMv4, there is a trace unit that monitors instruction [instruction trace information] and data buses and generates separate instruction and data trace streams … Each trace stream is a sequence of packets with unique headers [compressing, by the trace encoder, the instruction trace information into the message].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trace data compression/decompression invention of Zeinolabedin for the same reason set forth above.
With respect to claim 18, McFarling also discloses wherein the count is of branches, (e.g., Fig. 9 and associated text, e.g., [0062], As the branch continues to execute in the same direction, the count is incremented.) and Nexus further teaches direct … and wherein a direct branch is associated with a target address that is inferable from a program executed by the processor core (e.g., pp. 14-15, § 3.3.4, Because BTM for taken direct branches does not provide the target address, program trace for these application programs must be accomplished in a relative manner; p.38, § 4.3.4, The Direct Branch Message is output whenever there is a change of program flow and the target address is statically known caused by a branch [a direct branch is associated with a target address that is inferable from a program executed by the processor core].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus for the same reason set forth above.
With respect to claim 19, McFarling also disclose wherein the encoder comprises a history buffer that stores results of branches being taken or not-taken (e.g., [0062], A mode bit 90 is reserved to switch between the conventional history storage (shift register) mode and the new counter mode. When the mode bit is set, the remaining bits in the branch history entry are just the shifted branch history as previously described.) and Nexus teaches trace (e.g., Figure 3-2 and Figure 6-7 along with associated text, e.g., p. 12, § 3.3, The Program Trace feature [trace encoder] implements a Program Flow Change Model… The messages generated using this model are referred to as Branch Trace Messages; see also p. 14, § 3.3.2.2, BTM Using Branch History Messages, Each bit is logged in a history buffer where a value of 1 indicates taken and a value of 0 indicates not taken.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the shift-or-count encoder invention of McFarling with the trace message debugging invention of Nexus for the same reason set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Hu et al. “TraceDo: An On-Chip Trace System for Real-Time Debug and Optimization in Multiprocessor SoC” teaches trace messages with compression.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571)272-7206. The examiner can normally be reached on M-F, 9-6 Eastern.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on 571-272-6799. 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 http://pair-direct.uspto.gov. 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.
/STEPHEN D BERMAN/Examiner, Art Unit 2192
1 See Soundararajan, e.g., Figs. 1, particularly, current pattern table (CPT) 130, and Fig. 3, along with associated text, e.g., [0020], CPT 130, in which each entry includes … a current pattern field (Curr Pattern) to track a current pattern … a counter and a flag may be associated with each CPT entry. The counter may keep a running count of the pattern length and the flag may indicate a terminating condition. Thus, the current pattern field may be used to store a count and a flag; [0022], A pattern may be terminated in response to the branch direction flipping from T to N or from N to T; therefore, such flips may be referred to as terminating conditions and the flags associated with CPT entries may be referred to as flip flags … Finally, in response to the actual branch direction matching the flip flag, the current pattern may be terminated, which may include clearing or otherwise releasing the corresponding CPT entry [responsive to determining that the subsequent branch executed by the processor core is not-taken … clear].
2 See Remarks at p. 8.
3 See Remarks at p. 9.
4 See McFarling, e.g., Fig. 9 and associated text, e.g., [0061-62].
5 Id.
6 See footnote 1 above.
7 See Remarks at p. 9.
8 See Remarks at p. 9.
9 See Remarks at p. 8, “When McFarling switches back from count mode to shift mode, it does not clear the history buffer. On the contrary, McFarling explicitly teaches that ‘the shift field 92 is set to the value one would expect if the encoder had stayed in shift mode’…”.
10 See Applicant’s specification at [0042-43], “the trace encoder 400 may clear the history buffer 440 of the individual branch results, store the branch count in the history buffer 440, and continue to update (e.g., maintain) the branch count stored in the history buffer 440 when a next branch generates the same result (e.g., increment the count). The trace encoder 400 may continue in this way, updating the count when a next branch generates the same result, until a next branch is executed by the processor core with an opposite result … When this opposite result occurs … the trace encoder 400 may send an RFM indicating the branch count (e.g., stored as a count in the history buffer 440) … after the RFM including the branch count is sent, the encoder logic 410 may clear the history buffer 440 and may continue to store the results of branches being executed in the history buffer 440.” (Emphasis added)
11 Applicant’s specification describes a “trace encoder” in accordance with the Nexus standard cited here by Examiner (e.g., Applicant’s specification at [0014] recites, “In a mode referred to as branch trace messaging (BTM) (also referred to as BTM mode), a trace encoder may limit the messages being sent … For example, BTM is described in ‘The Nexus5001 ForumTM Standard for a Global Embedded Processor Debug Interface,’ Version 3.0, dated 01 June 2012”; see also [0034].)
12 Id.
13 Id.