Bicameral LLC v. NXP USA, Inc. et al

Western District of Texas, txwd-6:2018-cv-00294

RESPONSE Claim Construction Brief to {{44}} Brief, by NXP B.V., NXP Semiconductors N.V., NXP USA, Inc.

Interested in this case?

Current View

Full Text

7 IN THE UNITED STATES DISTRICT COURT FOR THE WESTERN DISTRICT OF TEXAS WACO DIVISION § Bicameral LLC, § § Plaintiff § § v. § Case No. 6:18-cv-00294-ADA § NXP USA, Inc., NXP Semiconductors N.V., § Jury Trial Demanded and NXP B.V., § § Defendants. § § § § DEFENDANTS' RESPONSIVE CLAIM CONSTRUCTION BRIEF 7 TABLE OF CONTENTS I. INTRODUCTION ................................................................................................................ 1 II. CONSTRUCTION OF CLAIM TERMS FOR THE '331 PATENT ................................... 2 A. Term 1: "program counter means [directly coupled to said instruction memory means] for indexing said instructions" (Claims 1, 21) ............................................. 2 1. Bicameral's Construction Violates the "Clearly Links" Standard Required by the Federal Circuit. .................................................................................. 2 2. Bicameral's Explanation of the Specification Is Unavailing........................ 5 B. Term 2: "cause register means for indicating [cause] information regarding interrupts and exceptions" (Claims 1, 21)................................................................. 6 C. Term 3: "first decoder means for indicating information about an instruction executed by said processor during a clock cycle" (Claims 1, 21) .......................... 10 1. Bicameral's Position Relies upon General Language and Speculation about What Could Have Been Disclosed in the Specification – Not the Structure That Was Actually Disclosed. ..................................................... 10 2. The Three Bit Output As Specified In Table 1 Is the Only Structure Linked With the Claimed "Indicating Information…" Function............................ 11 D. Term 4: "first output" (Claims 1, 21)...................................................................... 13 E. Term 5: "interrupts / exceptions" (Claims 1, 21) .................................................... 14 1. The Dispute Is Whether The '331 Patent Provides Sufficient Ability to Distinguish Between Exceptions And Interrupts As Used In The '331 Claims – Not Whether Those Terms Can Defined in the Abstract. ............ 14 2. Bicameral's Alleged "Key Distinctions" Are Couched in Indefinite Hedge Language And Are Expressly Refuted by the '331 Specification................ 16 3. Bicameral's Remaining Arguments Are Irrelevant to the Dispute at Hand Specific to the '331 Claims Requiring a Distinction between Interrupts and Exceptions. .................................................................................................. 18 F. Term 6: "cause information" (Claim 21) ................................................................ 20 III. CONSTRUCTION OF CLAIM TERMS FOR THE '538 PATENT ................................. 21 A. Term: "dynamically computing" (Claims 1, 14, 21) .............................................. 21 IV. CONCLUSION ................................................................................................................... 23 ii 7 TABLE OF AUTHORITIES Cases B. Braun Med., Inc. v. Abbott Labs., 124 F.3d 1419 (Fed. Cir. 1997).......................................... 4, 5 Chi. Bd Options Exch., Inc. V Int'l Sec. Exch., LLC, 677 F.3d 1361 (Fed. Cir. 2012)..................... 3 Fonar Corp. v. GE, 107 F.3d 1543 (Fed. Cir. 1997) ...................................................................... 10 Halliburton Energy Servs., Inc. v. M-I LLC, 514 F.3d 1244 (Fed. Cir. 2008) ............................... 18 Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364 (Fed Cir. 2014) ............................................ 17 Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205 (Fed. Cir. 2003)... 1, 4, 11 Medtronic, Inc. v. Advanced Cardiovascular Sys., 248 F.3d 1303 (Fed. Cir. 2001) .................. 4, 11 Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120 (2014) ................................................. 16 iii 7 I. INTRODUCTION Pursuant to this Court's Amended Scheduling Order (Dkt. #41), Defendants NXP USA, Inc., NXP Semiconductors N.V., and NXP B.V. (collectively, "NXP" or "Defendants") hereby submit their Responsive Claim Construction Brief regarding claims asserted by Plaintiff Bicameral, LLC ("Plaintiff" or "Bicameral"). The parties' remaining disputes are limited to the '331 and '538 patents. With respect to the '331 patent, Bicameral's brief repeats the same mistake for each of the disputed means-plus-function terms. The specification clearly links certain structure to the functions recited in each term. Such structure must necessarily be part of the "corresponding structure" that is part of the claim constructions. NXP's constructions reflect the quid pro quo bargain that exists when means-plus-function language is used in the claims. "The requirement that structure must be clearly linked or associated with the claimed function is the quid pro quo for the convenience of claiming in functional terms." Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1219 (Fed. Cir. 2003). Bicameral seeks to renege on this quid pro quo bargain. In each instance, Bicameral merely strikes the words "means" from the claim term – a practice that is clearly erroneous. Similarly, in each instance, Bicameral also attempts to divert the Court to portions of the specification that are not "clearly linked" to the functions recited by the means-plus-function terms. It is not relevant that particular structure might be envisioned by an expert or might even be capable of performing the recited function. Rather, the specific analysis is limited to whether structure is "clearly linked" in the specification to the recited functions. Bicameral's proposed structures lack this clear linkage. The indefiniteness dispute is not whether interrupts and exceptions have meanings or definitions in an abstract context. Rather, in the context of the '331 patent claims, "interrupts" must be distinguishable from "exceptions." This requirement exists because of the specific statements 1 7 in the prosecution history that distinguished these events and that required the cause register to indicate both types of events. It is common sense that if the cause register must be able to indicate two types of events, and if those events are different, then there must be some "objective boundary" for distinguishing those events. In the absence of any distinguishing "objective boundary," the public would not ever be able to discern whether a particular accused "cause register" could indicate an "interrupt," an "exception," or both (as required by the claims). NXP respectfully requests that the Court adopt its constructions as being consistent with the intrinsic record and the relevant Federal Circuit law. II. CONSTRUCTION OF CLAIM TERMS FOR THE '331 PATENT A. Term 1: "program counter means [directly coupled to said instruction memory means] for indexing said instructions" (Claims 1, 21) Bicameral's Construction NXP's Construction Function: indexing said instructions. Function: indexing said instructions. Structure: program counter (such as 24a, Structure: program counter 24 which contains 24b, 24c) as described in Fig. 1, Abstract, (i) an index of the instructions in an associated col. 3:33-42, col. 4:7-7:10, and claims; and IRAM and (ii) pointer to the index as the equivalents. instructions are executed (and equivalents thereto) 1. Bicameral's Construction Violates the "Clearly Links" Standard Required by the Federal Circuit. Bicameral's construction omits the one specific structure that is "clearly linked" with the recited "indexing" function: the "index of the instructions in an associated IRAM." NXP Opening Br., 331EX1 at 4:16-19.1 Bicameral does not (and cannot) deny this clear linkage between the recited function and the "index" structure, but rather asks the Court to just ignore this "index" structure. Such an approach would be error as it ignores the only structure "clearly linked" with 1 Unless otherwise noted, all emphases added. 2 7 the "index" function. Bicameral's position has three fatal flaws. First, Bicameral asks the Court to replace the claimed "indexing the instructions" with a "pointing to the instructions" function. See Bicameral Opening Br. at 5. The specification does not equate the functions of "indexing" and "pointing to" and it would be error for the Court to do so. See Chi. Bd Options Exch., Inc. V Int'l Sec. Exch., LLC, 677 F.3d 1361 (Fed. Cir. 2012). In Chi. Bd. Options Exch., one party "argue[d] that 'store,' 'apply,' and 'contain' have similarly meanings." Id. at 1688. The Federal Circuit held that the District Court erred in ascribing the same meaning to these terms because the specification did not clearly link these terms of "[t]he general presumption that different terms have different meaning." Id. The '331 specification does not "clearly link" a bare "pointing" function to the claimed "indexing" function. Indeed, as is recited in the specification (and as is common sense), an "index" requires both a pointer to the index and the index itself. Otherwise, the pointer is just a pointer that could be pointing to anything – not necessarily an "index." Second, even Bicameral's specification citations show that a "program counter" by itself does not perform the "indexing" function of the "program counter means" structure. Bicameral cites to two passages that both recite "the program counter has incremented to the next instruction in the index." See Bicameral Opening Br. at 5 (citing 4:56-57, 4:64-67) (emphasis added). Notably, the bare "program counter" must be accompanied by an "index" to accomplish the "indexing" function. Absent the "index," these passages recite merely the express function of "incrementing" (and possibly an implied function of "pointing"). Third, Bicameral's argument (at 5) that a "program counter may also index the instructions by pointing to the instructions themselves" both re-writes the function (from "indexing" to "pointing") and falls squarely afoul of Federal Circuit law. It is irrelevant that a particular structure 3 7 "may" perform a function unless the specification clearly links the claimed function with particular structure. This was the specific holding in Medtronic, Inc. v. Advanced Cardiovascular Sys., 248 F.3d 1303 (Fed. Cir. 2001). In Medtronic, a disputed structure was "definitely capable of performing the function recited in the means-plus-function limitation." Id. at 1312. The Federal Circuit emphatically rejected this "capable of" standard as "insufficient … because … there is no clear link or association between the disclosed structures and the function…." Id. Thus, whether the program counter is "capable of" performing or "may" perform the indexing function by itself using merely a "pointer" (which is an unsupported proposition in the first place), the specification does not clearly link this bare "pointing" to the recited "indexing" function in the absence of the index structure itself. The Federal Circuit cannot be clearer on this requirement to "clearly link" the structure: If the specification is not clear as to the structure that the patentee intends to correspond to the claimed function, then the patentee has not paid that price but is rather attempting to claim in functional terms unbounded by any reference to structure in the specification. Such is impermissible under the statute. Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1211 (Fed. Cir. 2003). Elekta is instructive to the present dispute. The Elekta patentee argued that certain structure corresponded to the claimed function because one of skill in the art "could have" used that structure and would have been "capable of implementing that structure." Id. at 1211-12. See also id. at 1216-17 (rejecting argument that corresponding structure exists when one of skill in the art would "understand how the function … is performed and therefore enough to make the [undisclosed] structure"). However, the Federal Circuit rejected such an approach because the disputed structure was not "clearly linked" to the function by the specification. Bicameral's argument is also indistinguishable to the argument rejected in B. Braun Med., Inc. v. Abbott Labs., 124 F.3d 1419 (Fed. Cir. 1997). In Braun, the patentee acknowledged that one 4 7 structure performed the recited function but argued that the specification "also discloses an alternative structure for performing [the recited] function." Id. at 1424. The Federal Circuit rejected this alternative structure argument because "neither the specification nor the prosecution history contains any indication that the [alternative] structure corresponds to the recited function." Id. at 1425. "This lack of association between [the alternative structure] and the recited function is especially striking given the explicitly clear association provided between the [acknowledged structure] and the recited function." Id. As in Braun, Bicameral points to an alleged alternative structure that is not clearly linked to the recited function. Similarly, as in Braun, there is a "explicitly clear association provided between the [index structure] and the recited function [indexing]." Indeed, it is difficult to envision a clearer linkage between a verb reciting a function (indexing) and a noun (index) exactly matching the structure for that verb. The Court should reject Bicameral's argument for the same reasons that the Federal Circuit rejected Braun's. Finally, Bicameral's attempt to just strike the word "means" from the claim is clearly erroneous. Each claim term presumptively has meaning. 2. Bicameral's Explanation of the Specification Is Unavailing. The specification is extremely explicit in stating that "[e]ach program counter contains an index of the instructions in an associated IRAM and a pointer to the index as the instructions are executed by the processor." NXP Opening Br., 331EX1 at 4:16-18 (emphasis added). Bicameral attempts to excuse this language by stating that it merely points to a "preferred embodiment." Bicameral Opening Br. at 4. However, all of the embodiments contain the "index" structure – as shown above, Bicameral's citations always include an "index." Bicameral cannot point to any embodiment that does not contain an index. 5 7 More fundamentally, even if there were an embodiment of a program counter that did not "contain[] an index" (there is no such embodiment in the '331), such a program counter would not be the claimed "program counter means" because it would not perform the recited "indexing" function of the specification. The "program counter means" must necessarily correspond to the structure in the specification that performs the recited function. B. Term 2: "cause register means for indicating [cause] information regarding interrupts and exceptions" (Claims 1, 21) Bicameral's Construction NXP's Construction Function: indicating [cause] information Function: indicating [cause] information regarding interrupts and exceptions regarding interrupts and exceptions. Structure: cause register (such as 26a, 26b, Structure: cause register 26 that may store and 26c) as described in Fig. 1, Abstract, col. information about both (a) exception 3:13-42, col. 4:7-7:10, and claims; and conditions; and (b) the pending interrupts equivalents. simultaneously (and equivalents thereto) Bicameral ignores the specific structure in the claims, specification, and prosecution history. Bicameral does not dispute that the claims require the cause register to store both exceptions and interrupts in the cause register, yet Bicameral's construction fails to account for the extensive statements in the prosecution history that define the "cause register" and provide specific disavowals of claim scope. Those statements must necessarily be part of the construction. Bicameral's primary argument, regarding "simultaneously" indicating information regarding exceptions and interrupts ignores the claims, specification, and prosecution history. The dispute on "simultaneously" is actually about whether the cause register must have the capability to store multiple indications at the same time during operation. NXP's position does not require that the cause register must (or must always) have multiple indications simultaneously. Rather, there must be one or more situations in normal operation that can lead to the cause register containing multiple indications. This requirement is found in the claims, specification and 6 7 prosecution history. First, the claims all specifically recite "indicating information regarding interrupts and exceptions." The use of the plural form of "interrupts" and "exceptions" and the unqualified "and" indicates that the cause register must, at a minimum, have the capability to store multiple indications at the same time. Indeed the only situation in which the plural of "exceptions" or "interrupts" can be met is when multiple indications are present in the cause register at the same time. Second, the specification also dictates that the cause register structure indicates multiple interrupts / exceptions. To begin with, the "cause register" structure contains separate bits for different interrupts and exceptions. As stated by Bicameral during the reexamination, in the '331 patent "bit locations 39 through 35 are used to store processor related exception conditions" and "[b]it locates 34 through 18 are used to store an indication of all pending interrupts (external, software, co-processor)." NXP Opening Br, Ex. 331EX3, 9/27/2011 Amendment at 25-26 (citing Ex. 331EX4, Barr Decl.) (citing '331 patent at 6:66-7:3). Thus, the specific structure in the specification requires different bits (the actual structure) for the different types of exceptions and interrupts. The specification requires that this structure must be able to store multiple indications at the same time. The specification states that "[b]it locations 34 through 18 are used to store an indication of all pending interrupts (external, software, co-processor)." This statement unequivocally requires that the cause register must be able to store multiple indications at the same time (of "all" pending "interrupts"). The fact that these "pending interrupts" bits can be zero also "indicat[es] information regarding interrupts and exceptions" as required by the claims. The "0" bit indicates that there is not a pending interrupt of the type corresponding to a particular bit (e.g., "external, software, co- processor"). Thus, in every situation in the specification, the cause register always has multiple 7 7 indications regarding interrupts and exceptions. See also NXP Opening Br., 331EX1 at 4:18-20 ("The cause registers store current information about interrupts, exceptions, and other processor functions."). Finally, the prosecution history is similarly unambiguous about the requirement to store multiple indications simultaneously. For example, the patentee stated: "the cause register performs at least two important functions, namely, it stores cause information about (a) exception conditions; and (b) the pending interrupts." NXP Opening Br., Ex. 331EX3, 9/27/2011 Amendment at 25-26 (citing Ex. 331EX4, Barr Decl.). The patentee's reiteration of the requirement that one of the "functions" was to store "the pending interrupts" (using the plural) reiterates the requirement from the specification that the cause register is required to store multiple indications when, for example, there are multiple pending interrupts. Similarly, the Examiner confirmed this requirement in stating that "[t]he Examiner agrees with Patent Owner that, neither the machine state register (MSR) nor the external interrupt status register (EXISR) of the PowerPC 403GA is a cause register, because neither stores both interrupts and exception conditions as required by the claims." NXP Opening Br., 331EX2 at. 4 (bolded emphasis in original). Consistent with the specification, claims and patentee's statements, the examiner used the plural ("interrupts") and the bolded word "and." Both usages confirm that the cause register must be able to store multiple indications at the same time. Bicameral points to a statement in the specification stating "the contents of the cause register indicates an exception, a jump register instruction, or a change in the status of an interrupt line." Bicameral Opening Br. at 6 (quoting '331 patent at 3:19-22). The "or" in this sentence merely reflects that these are the different events that cause the "decoder" to take action – it does not impart any information about whether the structure of the cause register requires the ability to contain 8 7 multiple indications during normal operation. Nor does this statement negate the "and" statements and the plural statements found in the claims, specification, and prosecution history. Bicameral's construction would re-write the claims. Rather than having a "cause register means for indicating information regarding interrupts and exceptions," Bicameral would rewrite the claims to recite "cause register means for indicating information regarding [one or more of] interrupts and exceptions." Such a rewrite is error – particularly in light of the extensive prosecution history. Bicameral also quibbles about NXP's use of the term "store information" rather than "indicates information." Bicameral Opening Br. at 6-7. NXP used the exact word ("store") used by both the patentee and the Examiner during the reexamination. See NXP Opening Br., 331EX3, 9/27/2011 Amendment at 25-26 (the patentee stated: "the cause register performs at least two important functions, namely, it stores cause information about (a) exception conditions; and (b) the pending interrupts"); 331EX2 at 4 (bolded emphasis in original) ("Examiner agrees with Patent Owner that, neither the machine state register (MSR) nor the external interrupt status register (EXISR) of the PowerPC 403GA is a cause register, because neither stores both interrupts and exception conditions as required by the claims. The "cause register means" term should be construed by the language chosen by the patentee and Examiner in distinguishing the prior art and thus "stores" is that term. Finally, even setting aside the dispute over exceptions and interrupts being simultaneously indicated by the cause register, as noted above, the cause register must indicate all pending interrupts (plural) consistent with the unambiguous statements of the Examiner, patentee, and patentee's expert. 9 7 C. Term 3: "first decoder means for indicating information about an instruction executed by said processor during a clock cycle" (Claims 1, 21) Bicameral's Construction NXP's Construction Function: indicating information about an Function: indicating information about an instruction executed by said processor during a instruction executed by said processor during a clock cycle clock cycle. Structure: first decoder (such as 28a, 28b, Structure: decoder 28 with three bit output 28c) as described in Fig. 1, Abstract, col. 2:62- (elements 30a, 30b, 30c) on a cycle by cycle 3:32, col. 3:43-58, col. 4:20-6:39, col. 7:21- basis which is indicative of the processor 8:10, and claims; and equivalents. activity during the last clock cycle indicating the outputs as interpreted in Table 1 by decoding the instruction in IRAM and the contents of the cause register (and equivalents thereto) 1. Bicameral's Position Relies upon General Language and Speculation about What Could Have Been Disclosed in the Specification – Not the Structure That Was Actually Disclosed. Bicameral does not dispute that the only structure in the specification that is "clearly linked" with the function of "indicating information about an instruction executed by said processor during a clock cycle" is the "Decoder 28 with three bit output ..." as required by NXP's construction. However, Bicameral would have the Court remove the exact structure (three bit output) that performs the recited function. As an initial matter, Bicameral's primary argument has been expressly rejected by the Federal Circuit. Bicameral argues that additional structure is disclosed by general boilerplate language that "other configurations could be used as well …" Bicameral Opening Br. at 17. The Federal Circuit expressly rejects such an approach: Although [the patent] states that other waveforms [structures] may be used, it fails to specifically identify those waveform [structures.] Thus, under Section 112, P. 6, [the claim] is limited to the use of [disclosed structure] and its equivalents. Fonar Corp. v. GE, 107 F.3d 1543, 1551-52 (Fed. Cir. 1997). 10 7 Similarly, Bicameral speculates that a "4-bit output" could have been disclosed (although it was not so disclosed). It is irrelevant to a means-plus-function argument about what could have been disclosed. It only matters what was disclosed and clearly linked to the function. Bicameral's "could have been" approach was discussed at length, and rejected, by the Federal Circuit in Elekta. See 334. F.3d at 1211-17. The Elekta court rejected the patentee's argument that certain structure corresponded to the claimed function because one of skill in the art "could have" used that structure and would have been "capable of implementing that structure." Id. at 1211-12. See also id. at 1216-17 (rejecting argument that corresponding structure exists when one of skill in the art would "understand how the function … is performed and therefore enough to make the [undisclosed] structure"). See also e.g., Medtronic, 248 F.3d at 1312 (structure that was merely "capable of" performing the function but which is not clearly linked to the function in the specification is not corresponding structure). Whether the specification "contemplates" other versions of Table 1 or other types of outputs is irrelevant. Bicameral Opening Br. at 18. The only corresponding structure is what is actually disclosed in the specification. 2. The Three Bit Output As Specified In Table 1 Is the Only Structure Linked With the Claimed "Indicating Information…" Function. Bicameral does not, and cannot, challenge that the specification repeatedly and unequivocally states that it is the 3-bit output which "indicates" and is "indicative" of information. While Bicameral seeks to construe the "first decoder means" as just the "first decoder" (without the 3-bit output), such a construction is incorrect because the "first decoder" merely decodes the information … it does not completely perform the recited function of "indicating information…." In contrast, as noted in NXP's Opening Brief at 13-14, the specification repeatedly "clearly links" the three bit output with the function of indicating information about the processor. E.g., 11 7 The first decoder, according to the invention, provides a real time three bit output on a cycle by cycle basis which is indicative of the processor activity during the last clock cycle. According to a presently preferred embodiment, the three bit output indicates seven different conditions regarding processor activity. In particular, the three bit output indicates whether or not a new instruction has been executed since the last clock cycle, and if a new instruction has been executed, whether the last instruction executed by the processor was an immediate jump, a jump to register, or a branch taken. In addition, the three bit output will indicate whether execution of the instruction resulted in an exception. NXP Opening Br., 331EX1 at 2:67-3:10. See also id. at 4:27-29; 4:35-5:10. Table 1 is a necessary part of the construction because it is required for the "indicating" function. In the absence of Table 1, the three-bit output has no meaning because it is merely generic output signals without context and without connection to the "indicating" function. Table 1 provides the corresponding structure similar to situations in which software algorithms provide the specific algorithm for generic processors to be able to convey sufficient structure. Absent the programmed output reflected in Table 1, the "first decoder" is just a generic decoder without sufficient structure to perform the recited function. Thus, in the absence of Table 1 included in the construction, the claims would be indefinite for a lack of structure. For this same reason, Bicameral's criticism of the inclusion of the language "by decoding the instruction in IRAM and the contents of the cause register (and equivalents thereto)" in the construction is also not well taken. The '331 patent does not include specific structure for the decoder in its specification. Rather, that structure is defined by its algorithm – to decode the instruction and cause register. Thus, absent this inclusion, the claim would be indefinite. Tellingly, Bicameral does not address these express statements that repeatedly and clearly link the "indicating" function with the three bit output. 12 7 D. Term 4: "first output" (Claims 1, 21) Bicameral's Construction NXP's Construction no construction required/plain and ordinary 3-bit output interpreted as shown in Table 1 meaning The construction of "first output" is directly linked to the construction of "first decoder means." As shown above, "first decoder means" necessarily includes the three bit output shown in Figure 1. This corresponds to the first output because there is no other corresponding structure. Bicameral argues that dependent the recitation in claim 10 of an "n-bit parallel output" compels that first output is broader. The problem for Bicameral is that such a structure leads to indefiniteness. For the "first decoder means" that is required to have structure that is "indicating information about an instruction executed by said processor during a clock cycle," the only such structure disclosed is the 3-bit output as programmed in Table 1. There is no other "n-bit" output that performs the claimed "indicating" function. As discussed in Elekta and Medtronic, such generic language, in the absence of the specific "indicating" specified by Table 1, is not sufficient structure to perform the recited function. Thus, the expansion of the first output to anything other than 3-bits would result in the claim being indefinite. Moreover, dependent claims cannot expand the structure disclosed in the specification. See Laitram Corp. v. Rexnord, Inc., 939 F.2d 1533, 1538 (Fed. Cir. 1991). See also NOMOS Corp. v. BrainLAB USA, Inc., 357 F.3d 1364, 1368 (Fed. Cir. 2004) ("our interpretation of the corresponding structure comes from the written description, not from dependent claim 3 and, therefore, the "prohibition against reading limitations from a dependent claim into the independent claim is not violated." …. Second, claim differentiation, which is a "guide, not a rigid rule," does not override the requirements of § 112, P 6 when the "claim 13 7 will bear only one interpretation." … In this case, only one embodiment is described in the '026 patent, therefore, the corresponding structure is limited to this embodiment and its equivalents") (citations omitted). Even if the "n-bit parallel output" is arguably some structure required to perform the recited function of "indicating…," it is not the entire structure and the lack of the remaining necessary structure for the function for an "n-bit" output precludes it from being construed as part of the "first decoder means." Thus, even if "first output" encompasses an n-bit output, the "first decoder means cannot include such a broad, unsupported construction. E. Term 5: "interrupts / exceptions" (Claims 1, 21) Bicameral's Construction NXP's Construction Interrupt[s]: no construction required/plain Interrupts: indefinite and ordinary meaning Exceptions: no construction required/plain Exceptions: indefinite and ordinary meaning 1. The Dispute Is Whether The '331 Patent Provides Sufficient Ability to Distinguish Between Exceptions And Interrupts As Used In The '331 Claims – Not Whether Those Terms Can Defined in the Abstract. Bicameral's brief avoids the exact reason that these claim terms – as used in the '331 patent claims – are indefinite. The statements in the '331 prosecution history require that there be a known and understood distinction between "interrupts" and "exceptions" in the context of the '331 patent claims. The dispute is not whether "interrupts" or "exceptions" can be defined in the abstract or in a different context or whether the meaning of each term in isolation can be known. Rather, the dispute is whether the '331 patent provides sufficient ability to how an "interrupt" is sufficiently different from an "exception" such that the cause register can be understood to possibly indicate both types of events. 14 7 As shown in NXP's Opening Brief, it is absolutely indisputable that Bicameral's claims survived reexamination because the patentee stated – and the examiner reiterated – that the claims required the cause register to contain information about both interrupts and exceptions. See NXP Opening Br. at 9-12. Moreover, the patentee established that there must be differences between these types of events because the patentee successfully distinguished a reference that allegedly showed only one of the interrupt/exception events but did not (allegedly) show the other type of event in a particular register. Id. Thus, the cause register must be able to contain information about both interrupts and exceptions and those events are different in the context of the '331 patent claims. In this context, Bicameral's brief and supporting expert declaration merely confirm that the claims of the '331 patent are indefinite because there is no ability of a competitor to understand whether an accused alleged "cause register" contains both interrupts and exceptions. Bicameral's brief confirms the following similarities and overlaps between interrupts and exceptions as shown in the table below: Interrupts Exceptions Both interrupts and handled by "a sequence of handled by "a sequence of exceptions are "handled" instructions intended to instructions intended to by software appropriately handle the appropriately handle the interrupt." Bicameral Br. at exception." Id. at 11 10. Both interrupts and '331 patent teaches that "'exception'" refers to an exceptions can be caused "interrupts can be 'external, abnormal condition detected by by executing software software, [or] co-processor.'" the microprocessor in relation to Id. at 12-13 (quoting '331 the instructions it is executing." patent) Id. at 11. Both interrupts and "'interrupt' refers to a break in "Exception … a condition which exceptions are a break in the normal flow of a computer is out of the ordinary in normal the normal execution flow system." Id. at 10. task execution." Id. at 11. 15 7 The lack of any meaningful distinction even in Bicameral's analysis is telling. Bicameral's brief merely confirms that there are no "objective boundaries" between these terms as is required for definiteness of the '331 claims. 2. Bicameral's Alleged "Key Distinctions" Are Couched in Indefinite Hedge Language And Are Expressly Refuted by the '331 Specification. Even when Bicameral attempts to identify the "key distinctions" between "interrupts" and "exceptions," those attempts: (a) use hedge words that destroy the required differentiation; and (b) run afoul of the specific teachings of the '331 patent. See Bicameral Opening Br. at 12. Bicameral alleges that one "key distinction" is "interrupts often signal events independent of instruction execution." Id. at 12. This statement has two problems. First, the hedge word "often" is not sufficient to impart the Supreme Court's required standard of "clear notice." "[A] patent must be precise enough to afford clear notice of what is claimed, thereby 'appris[ing] the public of what is still open to them.'" Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120, 2129 (2014) (alteration in original) (citations omitted). "Otherwise there would be '[a] zone of uncertainty which enterprise and experimentation may enter only at the risk of infringement claims.'" Id. (alteration in original) (citation omitted). The public, including NXP, does not bear the risk of not knowing when infringement might occur because "often" (but not always) the standard for infringement might be met. Moreover, it is nonsensical to state that a "key distinction" is something that is only "often" met by computer systems. The word "often" itself imparts the exact indefiniteness that renders the claims invalid. Second, and more importantly, Bicameral's distinction is expressly refuted by the '331 patent itself because the '331 patent expressly teaches (and claims) that interrupts are caused by 16 7 "software." See NXP Openig Br., 331EX1 at 7:1-3 ("Bit locations 34 through 18 are used to store an indication of all pending interrupts (external, software, co-processor"; claim 25 ("indication of pending interrupts includes at least one of an indication of external, software, or co-processor interrupt."). If interrupts in the '331 patent can be invoked by "software," then those interrupts are not "independent of instruction execution" because the "software" is the instruction execution. This example from the '331 specification shows that asserting that interrupts are "often" "independent of instruction execution" is irrelevant when the patent specification clearly states that interrupts are sometimes directly dependent on instruction execution (i.e., "software interrupts"). It is like talking about the flag of the USA and saying 'Flags often omit the colors red, white, and blue.'" Thus, the interrupts in the '331 patent are not "independent of instruction execution" and Bicameral's alleged first "key distinction" is, in reality, not a distinction at all. Bicameral's second "key distinction" is similarly unavailing for the same reasons. Bicameral alleges that Another key distinction between interrupts and exceptions is that for interrupts, the code or program that was interrupted is generally resumed after the interrupt handler completes. In the case of an exception, while this may occur for certain classes of exceptions, there are other classes of exceptions for which the program that generated the exception may be aborted. Bicameral Opening Br. at 12. The speculative words "generally" and "may" highlight the indefiniteness. As with "often," the public is not required by risk infringement on a "generally" standard. See Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364, 1371 (Fed Cir. 2014) ("The claims, when read in light of the specification and the prosecution history, must provide objective boundaries for those of skill in the art."). Furthermore, Bicameral's acknowledgment that this alleged "key distinction" is not even met by "certain classes of exceptions" is fatal to its indefiniteness argument. These different classes of exceptions show that "interrupts" and "exceptions" overlap in a manner that cannot be fully 17 7 articulated into precise claim scope for a claim that requires both types of events to be distinguished (as was stated in the prosecution history). See Halliburton Energy Servs., Inc. v. M-I LLC, 514 F.3d 1244, 1251 (Fed. Cir. 2008) ("The fact that [the patent holder] can articulate a definition supported by the specification. . . does not end the inquiry. Even if a claim term's definition can be reduced to words, the claim is still indefinite if a person of ordinary skill in the art cannot translate the definition into meaningfully precise claim scope."). Neither of these "key distinctions" are supported by any citations to the specification – which is unsurprising because the "key distinctions" turn out to not be distinctive at all. 3. Bicameral's Remaining Arguments Are Irrelevant to the Dispute at Hand Specific to the '331 Claims Requiring a Distinction between Interrupts and Exceptions. Bicameral's remaining arguments do not address the specific problem. First, Bicameral argues that "[a] patent need not explicitly include information that is already well known in the art." Bicameral Opening Br. at 13 (citations omitted). This statement does not address the present dispute which does not turn on whether "interrupt" or "exception" can be defined in the abstract. Rather, it was the patentee itself that distinguished between "exceptions" and "interrupts" for the purpose of the '331 claims. As shown throughout Bicameral's Opening Brief (and the extensive discussions of the art in NXP's Brief at 17-19), the usage and meaning of the terms "exceptions" and "interrupts" indistinguishably overlap in the art. It was the '331 patentee that required the specific distinction – to escape a holding of invalidity in the reexamination. Having successfully distinguished the prior art based upon this distinction between these types of events, the patentee cannot revert back to the overlapping definitions of these terms in the abstract. Second, Bicameral argues that PTO examiners in 1999 and 2011 were able to understand the meaning of "interrupts" and "exceptions." There are at least four separate failings in Bicameral's arguments. First, this argument could be (and is) made in response to every assertion 18 7 of indefiniteness in a District Court. If citation during prosecution controlled the District Court's assessment of indefiniteness, then there could never be any holding of indefiniteness because the claim terms were always necessarily considered by an examiner in prosecution. Second, both the June 10, 1999 and April 8, 2011 examiner decisions were made before the Supreme Court clarified the indefiniteness law in its 2014 Nautilus decision. Third, both of these statements in 1999 and 2011 were made prior to the patentee expressly distinguishing the claims on the basis that there must be both "exception" and "interrupt" information and that those types of events were different. See NXP Opening Br., 331EX3 (patentee's distinguishing statements made in Amendment submitted September 27, 2011). Fourth, the examiner was using the "broadest reasonable interpretation" ("BRI") standard during prosecution which is different from the Phillips standard used in District Court. A BRI standard allows the examiner to reject the claims over prior art rather than assess the indefiniteness issues. Bicameral's third argument regarding whether "NXP itself" uses these terms is also irrelevant. It is not the usage of the terms in all contexts that imparts indefiniteness. Rather, it is the '331 patentee's own statements that the claims require a distinction between these terms that creates the indefiniteness. This indefiniteness problem is specific to, and caused by, the reasons that the '331 patent escaped reexamination and the lack of any distinction between "interrupts" and "exceptions" supporting that escape. Context matters. In the end, Bicameral has not, and cannot, identify a sufficient distinction between these terms such that there is an "objective boundary" that can be recognized for infringement. This is fatal to the claims. 19 7 F. Term 6: "cause information" (Claim 21) Bicameral's Construction NXP's Construction Plain and ordinary meaning; requires no cycle by cycle information regarding the construction current instruction being executed by the processor; capable of indicating at least one In the alternative: "information regarding a instance of each of the following: whether it is cause" an exception, a jump / branch instruction based on the contents of a register or a change in the status of the interrupt line Bicameral's Opening Brief (at 19-20) seeks to throw the construction of the coined term "cause information" to the jury. This would be legal error. Similarly, Bicameral seeks to merely disaggregate the term "cause information" into its component words of "cause" and "information." This also is legal error. NXP agrees with Bicameral that the "cause information" is "the cause of the program leaving the normal path of software execution." NXP's construction reflects those causes. Bicameral's construction leaves it to the jury to parse the specification to understand the specific "causes" identified in the specification – a task for which a lay jury is not equipped nor is it expected to be able to perform.2 The term, "cause information," does not appear in the specification and was given a specific meaning by the patentee during prosecution of the reexamination. See NXP Opening Br. at 20-21. The Court should adopt the meaning given by the patentee when required to identify written description support for this term. NXP's construction reflects that meaning. 2 The "cycle by cycle…" clause in NXP's construction reflects the claim language in claim 21 that requires the information in the cause register to include information "about each instruction executed by said processor for each processor clock cycle." See also NXP Opening Br., 331EX1 at 3:20-22, 6:62-7:14, 4:18-20 ("current information…"); Abstract. 20 7 III. CONSTRUCTION OF CLAIM TERMS FOR THE '538 PATENT A. Term: "dynamically computing" (Claims 1, 14, 21) Bicameral's Construction NXP's Construction "computing in real-time or near-real-time" "computing in real-time" With respect to "dynamically computing," Bicameral adopts NXP's proposed construction – "computing in real-time" – in part, but then Bicameral proposes to add the extra verbiage "or near-real-time" to the construction. Bicameral's proposed additional verbiage contravenes the written description as well as the extrinsic evidence, and lacks metes and bounds such that it threatens to swallow the rest of the construction, all based on Bicameral's misreading of a single passage in the specification. The Court should reject Bicameral's construction and adopt NXP's construction. While Bicameral's proposed construction lacks metes and bounds, as a threshold observation, Bicameral's Opening Brief expressly adopts at least one aspect of "real time" processing – namely, that the processing must be "without dead time" even if Bicameral's vague construction of "or near real time" is applied, see Bicameral Opening Br. at 20, ("in near-real time … but still without dead times ….") (emphasis added), where the 538 Patent expressly defines dead time as "a period during which the monitor can miss a transient." See 538 Patent, 1:66-2:1 ("without experiencing dead time, i.e., a period during which the monitor can miss a transient") (emphasis added). Indeed, this is one aspect of "real time" processing, and it is consistent with patent's stated purported advance over what the patent characterized as the state of the prior art – art where a transient could be missed. See 538 Patent, 1:54-60 (characterizing prior art problem that "inputs transients will go undetected," leading to "erroneous and potentially catastrophic conclusion that the monitored system has not been exposed to harmful transients."). Therefore, so as to eliminate 21 7 at least one subset of the dispute of the construction of "dynamically computing" between the parties, NXP submits that the parties appear to agree that whatever the construction of "dynamically computing," one aspect is that the construction requires processing "without experiencing dead time, i.e., a period during which the monitor can miss a transient." 538 Patent, 1:66-2:1 ("without experiencing dead time, i.e., a period during which the monitor can miss a transient"); Bicameral Opening Br. at 20 ("in near-real time … but still without dead times …"). Beyond that aspect, Bicameral's proposed phrase "or near-real-time" is without any metes and bounds, and if misapplied, effectively could swallow the phrase "computing in real time," in contravention of all the patent passages cited in NXP's opening brief as well as the extrinsic evidence showing that "dynamically" means "in real time." See NXP Opening Br. at 22-26. For example, if a circuit does not compute dynamically and instead computes more slowly than real time, mere routine "computing" by that circuit's circuit elements would not be an example of "dynamically computing." Yet Bicameral provides no explanation of how, or any assurance that, Bicameral understands the metes and bounds of Bicameral's proposed construction to prevent a misapplication to such "computing" that would completely read out the claim term "dynamically." As stated in NXP's Opening Brief, Bicameral cites only a single passage of the specification referring to a "user [] determin[ing] in near real time" whether action is required. That patent uses the phrase "near real time" in the context of user interpretation, as well as other additional steps, not "computing." As such, that passage is inapposite to proper construction of "dynamically computing." See NXP Opening Br. at 26. As set forth in NXP's Opening Brief, the patent repeatedly uses the term "real time" (a term absent from the claims, but where even the extrinsic evidence shows that "dynamic" in the art means "in real time") to characterize the invention and the purported improvement over the art. To avoid 22 7 any doubt whatsoever that "dynamically computing" means "computing in real time," the patent cautions that whatever "various changes to this configuration may be made" – in other words, no matter how broadly the invention is understood – one must "ensure" – in other words, make certain – that there is "real time processing of that digital data stream." 538 Patent at 14:23-35. In contravention of this warning in the patent, adding the phrase "or near real time" per Bicameral's proposed construction not only would fail to "ensure" "real time processing," it would utterly defeat it. The Court should reject Bicameral's vague construction, and adopt NXP's construction. IV. CONCLUSION For these reasons, NXP respectfully requests the Court construe the disputed claim terms in accordance with NXP's proposed constructions. Dated: September 3, 2019. Respectfully submitted, /s/ Gilbert A. Greene Gilbert A. Greene (SBN 24045976) Pierre J. Hubert (SBN 24002317) DUANE MORRIS LLP 900 S. Capital of Texas Highway Suite 300 Austin, Texas 78746 Tel: (512) 277-2300 Fax: (512) 277-2301 BGreene@duanemorris.com PJHubert@duanemorris.com Kevin P. Anderson (Pro Hac Vice) DUANE MORRIS LLP 505 9th Street, N.W., Suite 1000 Washington, DC 20004-2166 Tel: (202) 776-7800 Fax: (202) 776-7801 KPAnderson@duanemorris.com Attorneys for Defendants NXP USA, Inc., NXP Semiconductors N.V., and NXP B.V. 23 7 CERTIFICATE OF SERVICE I certify that on September 3, 2019, I electronically filed the foregoing with the Clerk of Court using the CM/ECF system, which will send notification of such filing to all counsel of record. /s/ Gilbert A. Greene Gilbert A. Greene DM2\10431991.6