Bicameral LLC v. NXP USA, Inc. et al

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

BRIEF by NXP B.V., NXP Semiconductors N.V., NXP USA, Inc.

Interested in this case?

Current View

Full Text

3 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' OPENING CLAIM CONSTRUCTION BRIEF DM2\10335838.5 3 TABLE OF CONTENTS I. INTRODUCTION ................................................................................................................ 1 II. STATEMENT OF FACTS ................................................................................................... 2 A. Agreed Constructions................................................................................................ 2 B. Disputed Constructions ............................................................................................. 2 III. GENERAL LEGAL PRINCIPLES OF CLAIM CONSTRUCTION .................................. 2 IV. CONSTRUCTION OF CLAIM TERMS FOR THE '331 PATENT ................................... 3 A. Term 1: "program counter means [directly coupled to said instruction memory means] for indexing said instructions" (Claims 1, 21) ............................................. 5 1. The Specification Clearly Links the Recited Function with NXP's Construction .................................................................................................. 6 2. Bicameral's Construction Improperly Reads Terms out of the Claim, Fails to Identify Specific Structure Clearly Linked With the Function, and Results in Indefiniteness. ........................................................................................... 7 B. Term 2: "cause register means for indicating [cause] information regarding interrupts and exceptions" (Claims 1, 21)................................................................. 8 1. The Structure Disclosed in the Specification, as Identified By Patentee and Its Own Expert During Prosecution, Is Clearly Linked with Structure That Stores Information About Both Exception Conditions and Pending Interrupts Simultaneously. ............................................................................ 8 2. During Prosecution, the Patentee Unambiguously Defined the Cause Register to Require Information on Both Exceptions and Pending Interrupts..................................................................................................... 10 C. Term 3: "first decoder means for indicating information about an instruction executed by said processor during a clock cycle" (Claims 1, 21) .......................... 12 1. NXP's Construction Accurately Reflects the Specific Structure That Performs the Recited Function. .................................................................. 12 2. Bicameral's Construction Improperly Deletes a Claim Term and Fails to Link Its Structure to the Recited Function. ................................................. 14 D. Term 4: "first output" (Claims 1, 21)...................................................................... 14 E. Term 5: "interrupts / exceptions" (Claims 1, 21) .................................................... 15 ii DM2\10335838.5 3 1. The Terms "Interrupts" and "Exceptions" Are Indefinite in the Context of the Intrinsic Record..................................................................................... 15 2. Extrinsic Evidence Confirms That There Is No Accepted Understood Boundaries Between These Terms. ............................................................. 17 3. Bicameral's "Plain and Ordinary Meaning" Constructions Confirm the Inability To Distinguish Between These Items. ........................................... 19 F. Term 6: "cause information" (Claim 21) ................................................................ 20 1. NXP's Construction Reflects the Specific Meaning Given to "Cause" ...... 20 2. Bicameral's Construction Merely Rearranges the Words Without Guiding the Jury on the Meaning of the "Cause." ................................................... 21 V. CONSTRUCTION OF CLAIM TERMS FOR THE '538 PATENT ................................. 22 A. Term: "dynamically computing" (Claims 1, 14, 21) .............................................. 22 1. The Specification and the Extrinsic Evidence Dictate that "Dynamically Computing" Means "Computing in Real-Time" as per NXP's Proposed Construction ................................................................................................ 23 2. The Court Should Reject Bicameral's Proposed Construction that uses the Term "Near" Real-Time That Is Based on Bicameral's Misreading of One Sentence of the Specification, and Is Vague as to Metes and Bounds ........ 25 VI. CONCLUSION ................................................................................................................... 26 iii DM2\10335838.5 3 TABLE OF AUTHORITIES Cases Altiris, Inc. v. Symatec Corp., 318 F.3d 1363 (Fed. Cir. 2003) .......................................................3 Andersen Corp. v. Fiber Composites, LLC, 474 F.3d 1361 (Fed. Cir. 2007) ..................................3 Becton, Dickinson & Co. v. Tyco Healthcare Group, LP, 616 F.3d 1249 (Fed. Cir. 2010) ..........................................................................................................................................6 Cohesive Techs., Inc. v. Waters Corp., 543 F.3d 1351 (Fed. Cir. 2008) .........................................6 Default Proof Credit Card Sys., Inc. v. Home Depot U.S.A., Inc., 412 F.3d 1291 (Fed. Cir. 2005) ........................................................................................................... 5-6, 12-13 Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364 (Fed Cir. 2014) ..................................... 15-16 Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205 (Fed. Cir. 2003) ..........................................................................................................................................7 Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120 (2014) .................................... 14-15, 19 Noah Sys., Inc. v. Intuit Inc., 675 F.3d 1302 (Fed. Cir. 2012) .........................................................4 Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) ............................................................. 2-3 Valmont Indus., Inc. v. Reinke Mfg. Co., 983 F.2d 1039 (Fed. Cir. 1993) ..................................4, 6 Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015) (en banc) ........................ 4, 6-7 Statutes 35 U.S.C. § 112 ......................................................................................................................4, 7, 14 iv DM2\10335838.5 3 TABLE OF EXHIBITS Exhibit No. Title/Description Ex. A Agreed-Upon Claim Constructions Ex. 331EX1 '331 Patent Ex. 331EX2 '331 Ex Parte Reexamination: Examiner's Reason For Allowability Ex. 331EX3 '331 Ex Parte Reexamination: 9/27/2011 Amendment By Patentee Ex. 331EX4 '331 Ex Parte Reexamination: Patentee's Expert Declaration Ex. 331EX5 '331 Ex Parte Reexamination: Petition for Reexamination Ex. 331EX6 Hennessy and Patterson excerpt Ex. 331EX7 ARM Architecture Reference Manual excerpt Ex. 538EX1 '538 Patent Ex. 538EX2 Excerpt from www.dictionary.com for "dynamic" (visited August 12, 2019) (annotated by hand to show relevant part) Ex. 538EX3 Sechi et al., "An On-Line Lightning Monitoring System for Spacecraft Launch Support," SAE Technical Paper Series, 1999-01-2335 v DM2\10335838.5 3 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 Opening Claim Construction Brief regarding claims asserted by Plaintiff Bicameral, LLC ("Plaintiff" or "Bicameral"). In its Infringement Contentions, Bicameral asserted five patents and the following claims of the Asserted Patents against NXP:  claims 1 and 2 of U.S. Patent No. 6,008,727 (the '727 Patent");  claims 1, 2, 3, 4, 21, 23, and 24 of U.S. Patent No. 6,321,331 (the "'331 Patent");  claims 1, 2, 3, 4, 7, 8, 9, 10, 12, 13, 14, 15, 17, 19, 20, 21, 22, and 23 of U.S. Patent No. 6,639,538 (the "'538 Patent");  claims 1 and 5 of U.S. Patent No. 6,754,223 (the "'223 Patent"); and  claims 1, 2, 5,17, 18, 21, 33, 34, 35, 38, 51, 52, and 55 of U.S. Patent No. RE42,092 (the "'092 Patent"). As to the '727 Patent, the parties have stipulated to dismiss Bicameral's claims on the '727 Patent with prejudice and NXP's corresponding counterclaims as to the '727 Patent, with NXP preserving its claim and rights to seek its fees and costs under section 285 as to the '727 Patent. The parties have agreed upon certain constructions listed in Exhibit A. The remaining disputes as to claim construction involve six (6) terms or phrases of the '331 Patent, and one term of the '538 Patent. 1 DM2\10335838.5 3 II. STATEMENT OF FACTS A. Agreed Constructions The parties agreed that the terms listed in Exhibit A be construed as indicated therein and request entry of the agreed-upon constructions for the purposes of this litigation. B. Disputed Constructions The parties agree that for the purposes of this litigation, in addition to the foregoing terms for which the parties have proposed agreed-upon constructions, only the following disputed terms require construction by the Court: '331 Patent  "program counter means [directly coupled to said instruction memory means] for indexing said instructions" (Claims 1, 21)  "cause register means for indicating [cause] information regarding interrupts and exceptions" (Claims 1, 21)  "first decoder means for indicating information about an instruction executed by said processor during a clock cycle" (Claims 1, 21)  "first output" (Claims 1, 21)  "interrupts / exceptions" (Claims 1, 21)  "cause information" (Claim 21) '538 Patent  "dynamically computing" (Claims 1, 14, 21) III. GENERAL LEGAL PRINCIPLES OF CLAIM CONSTRUCTION In Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005), an en banc panel of the Federal Circuit explained the basic principles governing claim construction:  "the claims themselves provide substantial guidance as to the meaning of particular claim terms," id. at 1314; 2 DM2\10335838.5 3  the specification, of which the claims are a part, is the primary basis for construing claims, id. at 1315;  the prosecution history should also be considered, since it "can often inform the meaning of the claim language" or contain disclaimers of claim scope, id. at 1317; and  extrinsic evidence may be useful because it "can help educate the court regarding the field of the invention and can help the court determine what a person of ordinary skill in the art would understand claim terms to mean." Id. at 1319. However, preferred embodiments found in the specification cannot be used to limit claim language that has a broader meaning. Altiris, Inc. v. Symatec Corp., 318 F.3d 1363, 1370 (Fed. Cir. 2003). Claims are "'generally given their ordinary and customary meaning,'" which "is the meaning that the term would have to a person or ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application." Phillips, 415 F.3d at 1312-13. Additionally, "an applicant's argument that a prior art reference is distinguishable on a particular ground can serve as a disclaimer of claim scope even if the applicant distinguishes the reference on other grounds as well." Andersen Corp. v. Fiber Composites, LLC, 474 F.3d 1361, 1374 (Fed. Cir. 2007) (internal citations omitted). IV. CONSTRUCTION OF CLAIM TERMS FOR THE '331 PATENT The '331 patent teaches and claims a very specific set of structures within a processor that are used to debug that processor. The approach taught by the '331 patent involves a "program counter means" that includes an index and a pointer to be able to track the currently executed instruction, a "cause register means" which records certain critical events, and a "first decoder means" which decodes specific information within the processor and provides an output to an external debugging system with that information. The output information is used to debug the processor and/or software executing on the processor. 3 DM2\10335838.5 3 The '331 patent notes that certain events within a processor can be useful for debugging the execution flow. These events include interrupts, exceptions, and program branches. At critical times during the execution flow, the '331 patent's hardware structures output information to an external debugger using the "cause register means" and the "first decoder means" that includes information about the useful events. The '331 patent was previously litigated. Related to that litigation, an ex parte reexamination was filed at the Patent Office. The patentee overcame the cited prior art by emphasizing several specific structural aspects of the alleged invention recited in the claims. First, the patentee emphasized that certain claims required elements to be "directly coupled." Given the unequivocal statements in the prosecution history, Bicameral and NXP have agreed upon the definition of "directly coupled" – one that matches the prosecution history statements. See Exhibit A. Second, the patentee emphasized other aspects of the invention regarding the "cause register means" that is recited in each claim. NXP's constructions reflect the patentee's statements as well as the use of means-plus-function language in the claims. Bicameral's constructions do not. The '331 claims all use means-plus-function language. Because such means-plus-function claims are limited to the specific structures disclosed in the specification (and equivalents), this claim language allowed the patentee to argue that the prior art was distinguished on the basis of those specific structures. The same approach applies in the present dispute. The means-plus- function claims must include the specific structure disclosed in the specification necessary to perform the recited function. This is the quid pro quo of such means-plus-function claiming. The '331 patent contains three disputed elements that the parties agree are means-plus- function elements to be construed under 35 U.S.C. §112 ¶6. With respect to the means-plus- function elements, the parties agree on the function, but disagree on the structure that performs that 4 DM2\10335838.5 3 function. Federal Circuit law requires that the identification of structure reflect at least two fundamental principles: (1) it must reflect all of the structure necessary to perform the recited functions; and (2) the structure must be clearly linked with the function in the intrinsic record. NXP's constructions follow these principles; Bicameral's constructions do not follow either principle. "Construing a means-plus-function claim term is a two-step process. The court must first identify the claimed function. Noah Sys., Inc. v. Intuit Inc., 675 F.3d 1302, 1311 (Fed. Cir. 2012). Then, the court must determine what structure, if any, disclosed in the specification corresponds to the claimed function. … Id. at 1318-19. If the patentee fails to disclose adequate corresponding structure, the claim is indefinite." Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1351-52 (Fed. Cir. 2015) (en banc). In exchange for being able to draft a claim limitation in purely functional language, "[t]he applicant must describe in the patent specification some structure which performs the specified function." Valmont Indus., Inc. v. Reinke Mfg. Co., 983 F.2d 1039, 1042 (Fed. Cir 1993). 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 they equivalents. instruction are executed (and equivalents thereto) 5 DM2\10335838.5 3 1. The Specification Clearly Links the Recited Function with NXP's Construction NXP's construction is taken directly from the specification as is required for a means-plus- function structure. Plaintiff's construction omits structure disclosed in the specification that is necessary to perform the recited function and improperly merely strikes the word "means" from the claims. The legal framework requires NXP's construction. "While corresponding structure need not include all things necessary to enable the claimed invention to work, it must include all structure that actually performs the recited function." Default Proof Credit Card Sys., Inc. v. Home Depot U.S.A., Inc., 412 F.3d 1291, 1298 (Fed. Cir. 2005) (citing Cardiac Pacemakers, Inc. v. St. Jude Med., Inc., 296 F.3d 1106, 1119 (Fed. Cir. 2002)). The parties agree that the function is "indexing said instructions." The term "index" is used in only two passages in the specification – both consistent with NXP's construction. First, the specification clearly defines the "program counter means": "Each sequencer includes a program counter 24a, 24b, 24c and a cause register 26a, 26b, 26c. Each 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." Ex. 331EX1 at 4:16-18 (emphasis added).1 Second, the specification teaches that "[t]he output 001 indicates that the processor has processed the next instruction in the program; i.e., the program counter pointer has incremented to the next instruction in the index." Id. at 4:54- 57 (emphasis added). The associated structure must include "all structure that actually performs the recited function." Default Proof Credit Card Sys., 412 F.3d at 1298 (emphasis added). The only structure 1 Even if the term were not "means plus function," this passage is sufficiently definitional to define the "program counter" consistently with NXP's construction as the passage teaches that "each program counter" has the index and pointer. 6 DM2\10335838.5 3 identified in the specification linked to the "indexing" function is the "index" and the "pointer to the index" recited in the passages quoted above. 2. Bicameral's Construction Improperly Reads Terms out of the Claim, Fails to Identify Specific Structure Clearly Linked With the Function, and Results in Indefiniteness. Bicameral's construction suffers from two fatal flaws. First, Bicameral merely reads the term "means" out of the claims by replacing "program counter means" with "program counter." This plainly contradicts Federal Circuit law. See Cohesive Techs., Inc. v. Waters Corp., 543 F.3d 1351, 1368 (Fed. Cir. 2008) ("district court erred … by reading [a] term [] out of the claim."); see also Becton, Dickinson & Co. v. Tyco Healthcare Group, LP, 616 F.3d 1249, 1260 (Fed. Cir. 2010) (holding that the "spring means limitation requires not only a spring, but a spring that moves the guard down the needle cannula"). Second, while the term "program counter" is used in the specification (e.g., Fig. 1), the specification does not disclose any structure for that "program counter" (other than the index and pointer in NXP's construction) and certainly does not "clearly link" any structure to the function of "indexing said instructions." In exchange for being able to draft a claim limitation in purely functional language, "[t]he applicant must describe in the patent specification some structure which performs the specified function." Valmont Indus., Inc. v. Reinke Mfg. Co., 983 F.2d 1039, 1042 (Fed. Cir. 1993). "Structure disclosed in the specification qualifies as 'corresponding structure' if the intrinsic evidence clearly links or associates that structure to the function recited in the claim." Williamson, 792 F.3d at 1352 (citations omitted). Because the bare term "program counter" is not clearly linked with the requisite specific structure for the function of indexing (other than NXP's "index" and "pointer"), Plaintiff's construction would necessarily lead to a finding that the term (and all claims) is indefinite. Id. ("If the patentee fails to disclose adequate corresponding structure, the claim is indefinite."). 7 DM2\10335838.5 3 Means-plus-function claiming involves a quid pro quo. Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1211 (Fed. Cir. 2003) ("The duty of a patentee to clearly link or associate structure with the claimed function is the quid pro quo for allowing the patentee to express the claim in terms of function under section 112, paragraph 6.") (citation omitted). Bicameral chose to use "means-plus-functional" language in all of its claims. The consequences are that Bicameral is limited to the specific structure and cannot expand the claim to a generic "program counter" even if such a construction would be supported if the term were not a means-plus-function term. 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]2 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) 1. The Structure Disclosed in the Specification, as Identified By Patentee and Its Own Expert During Prosecution, Is Clearly Linked with Structure That Stores Information About Both Exception Conditions and Pending Interrupts Simultaneously. NXP's construction reflects: (a) the structure disclosed in the specification for the cause register means; and (b) the unambiguous statements made during the prosecution history that 2 "Cause information" is separately discussed below. For purposes of the "cause register," there is no meaningful distinction between claims 1 and 21 other than the definition of "cause information." 8 DM2\10335838.5 3 require the "cause register" to contain information about both exceptions and pending interrupts simultaneously. The "cause register" in the specification clearly discloses structure that stores information about exception conditions and pending interrupts simultaneously. Indeed, the patentee's own statements (and expert declaration) described the structure in the specification storing both exception and pending interrupt information simultaneously: As explained by Roy, "[t]he cause registers store current information about interrupts, exceptions, and other processor functions." (Roy, 4:18-20). The specific kind of information stored in the cause register is explained in the context of storing the cause register information in bits 40-18 of the history buffer 14. (Roy, 6:39 - 7:10). As Roy explains, "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). Accordingly, the cause register performs at least two important functions, namely, it stores cause information about (a) exception conditions; and (b) the pending interrupts. (Barr Decl. at ¶ 42). Ex. 331EX3, 9/27/2011 Amendment at 25-26 (citing Ex. 331EX4, Barr Decl.). The patentee (and its expert) plainly identify the structure as two separate sets of bits containing "information about (a) exception conditions; and (b) the pending interrupts." Notably, the Examiner adopted this verbatim identification of structure – including the identification of the specific bits allowing for the storage of the different types of information simultaneously – in the Reasons For Allowability. Ex. 331EX2 at 4 (quoted below at Section B.2). The statements of the patentee and its expert as well as the Examiner are consistent with the remaining passages of the specification disclosing different bits in the cause register for the different information. E.g., 331EX1 at 7:18-20 ("When the cause register bits corresponding to an exception are unmasked or a PC jump register instruction is encountered, an entry is made in the history buffer.") (emphasis added); 4:18-22 ("The cause registers store current information about interrupts, exceptions, and other processor functions."). 9 DM2\10335838.5 3 Thus, because the structure in the specification "clearly linked" with the recited function is structure (bits in the cause register that store information about both exception conditions and pending interrupts), that structure is the correct structure for the "cause register means." This is consistent with the statements of the Examiner, patentee, and patentee's experts. Furthermore, NXP's construction is consistent with the plain language of all of the claims that recites that the function is to indicate information regarding "interrupts and exceptions." Notably, the language is not "or" and also is not "and/or." Rather, the plain language recites the conjunctive "and" which requires both pending interrupts and exceptions. This is not to say that the "cause register means" must always contain information about the pending interrupts and exceptions. Rather, the structure must be capable of containing information about both pending interrupts and exceptions simultaneously. 2. During Prosecution, the Patentee Unambiguously Defined the Cause Register to Require Information on Both Exceptions and Pending Interrupts. As detailed above, the patentee submitted arguments and an expert declaration that unambiguously identified the structure in the specification for the cause register means as including structure that stored both exception information and pending interrupt information. The prosecution is replete with further such statements. The '331 patent was asserted against Xilinx, which filed an ex parte reexamination. 331EX5 (Petition for ex parte Reexamination). In the reexamination, Xilinx asserted that certain references (the "IBM References") contained a register called the EXISR that corresponded to the claimed cause register means. Id. at 17. The patentee argued repeatedly and vociferously that the EXISR was not a cause register because it did not store information about both exception conditions and pending interrupts. Ex. 331EX3 at 25-26. The Examiner adopted the patentee's reasoning in allowing the claims: 10 DM2\10335838.5 3 Examiner's Statement of Reasons for Patentability/Confirmation 8. Claims 1-25, 33-36, 43-44, and 50-55 are deemed to be patentable and/or confirmed over the prior art of record for the following reasons: prior art references submitted by Requester do no[t] teach, disclose or suggest the claimed feature of "cause register means for indicating information regarding interrupts and exceptions" as argued by Patent Owner. According to Patent Owner, "the cause register performs at least two important functions, namely, it stores cause information about (a) exception conditions; and (b) the pending interrupts." (Response at p. 26). Patent Owner explains that the specification of the '331 patent discloses that "bit locations 39 through 35 are used to store processor related exceptions conditions" and "(b]it locations 34 through 18 are used to store an indication of all pending interrupts (external, software, co-processor)." ('331 patent, c6:39-c7:I0). The 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. Ex. 331EX2 at. 4 (bolded emphasis in original). The Examiner's emphasis on the word "and" confirms that the cause register means must store information on both exception conditions and pending information. The Examiner's statement merely reflects the repeated arguments made by the patentee. For example, the patentee's expert distinguished the IBM References by stating that "The EXISR is not a cause register because it only provides external interrupt status information … The EXISR, for instance, lacks any information concerning co-processor interrupts, software interrupts, or exceptions." Ex. 331EX4 at ¶ 58. See also id. at ¶¶ 36, 41, 42, 52. The patentee elaborated on its expert's reasoning. "The EXISR fails to teach, disclose or suggest this [cause register means] element, because the EXISR only indicates information about external interrupts, and not about exceptions." Ex. 331EX3 at 18. According to the patentee, "[t]he EXISR differs from the claimed cause register because, among other things, the EXISR does not store cause information regarding interrupts and exceptions." Id. at 26 (citing expert declaration, Ex. 331EX4 at ¶ 58) (emphasis in original). 11 DM2\10335838.5 3 Thus, the prosecution history of the reexamination confirms that the Examiner, the patentee, and the patentee's expert all: (a) understood the specification to disclose structure that separately stored information about both exceptions and pending interrupts at the same time; and (b) distinguished prior art because the alleged cause register means did not store information about both exceptions and pending interrupts. Plainly, the definition of "cause register means" must fully reflect these unambiguous statements by the Examiner, patentee, and patentee expert. Finally, to be clear, the cause register must identify all pending interrupts (plural) consistent with the unambiguous statements of the Examiner, patentee, and patentee expert. 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. NXP's Construction Accurately Reflects the Specific Structure That Performs the Recited Function. Only NXP's construction includes all of the structure necessary to perform the recited function – a requirement under Federal Circuit law. "While corresponding structure need not include all things necessary to enable the claimed invention to work, it must include all structure that actually performs the recited function." Default Proof Credit Card Sys., 412 F.3d at 1298 (citation omitted). 12 DM2\10335838.5 3 The parties agree that the recited function is "indicating information about an instruction executed by said processor during a clock cycle." The generic "first decoder" does not provide any specific structure, nor is it "clearly linked" with the recited function of "indicating information…." The specification repeatedly and unequivocally states that it is the 3-bit output which "indicates" and is "indicative" of information. The Abstract states: The first decoder provides a three bit real time output which is indicative of the processor activity on a cycle by cycle basis. The three bit output indicates seven different conditions: …. " Ex. 331EX1 at Abstract (emphasis added). The following passage states, almost verbatim, that it is the 3-bit output performing the recited claim function: 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. Id. at 2:67-3:10 (emphasis added). The specification repeats this linkage between the 3-bit output and the recited function over and over. "[T]he three bit output of each first decoder 28 provides an indication of the processor activity during the last clock cycle." Id. at 4:27-29. In describing Table 1, the specification repeatedly links the "indicating" function to the 3- bit output: The output 000 indicates that there has been no change in the processor …. The output 001 indicates that the processor has processed the next instruction in the program; …. The output 010 indicates that the last instruction processed by the processor was a "hard coded" jump to an instruction; … The output 011 indicates that the last instruction processed by the processor was a jump to an instruction based on the contents of a register…. The output 100 indicates that since the last clock cycle the processor has encountered an interrupt or an exception; … The output 101 indicates that the last instruction processed by the processor was a pc branch taken; … The 13 DM2\10335838.5 3 output 111 indicates that since the last clock cycle the processor has encountered an interrupt or an exception…. Id. at 4:35-5:10 (emphasis added). The specific encodings in Table 1 define how the 3-bit output "indicates" the information and is a necessary part of "all structure that actually performs the recited function." Default Proof Credit Card Sys., 412 F.3d at 1298 (citation omitted) (emphasis added). Thus, it is not the generic "first decoder" that performs the recited structure, but the 3-bit output structure of the first decoder. The 3-bit output provides the requisite structure (and output which is determined by Table 1). 2. Bicameral's Construction Improperly Deletes a Claim Term and Fails to Link Its Structure to the Recited Function. Bicameral's construction merely replaces "first decoder means" with "first decoder." The deletion of the claim term "means" is improper for the reasons given above with respect to the program counter means. Furthermore, the specification does not clearly link the generic term "first decoder" with the recited function. Rather, as noted by the repeated quotes above, the specification clearly links the 3-bit output as defined in Table 1 with the recited function. Thus, in the absence of the 3-bit output and Table 1 as part of the required structure, Bicameral's construction renders the term indefinite for failure to identify structure in the specification that is clearly linked with the function. 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 claims recite the "first decoder means having a first output, wherein said first output provides information regarding activity of said processor in real time." Ex. 331EX1 at claim 1. 14 DM2\10335838.5 3 Thus, the "first output" is the portion of the "first decoder means" that is the output providing the information regarding the activity. The "first output" must be construed consistently with the "first decoder means." As noted with respect to the "first decoder means," the specification solely describes the 3-bit output defined by Table 1 as the output of the first decoder. There is no other structure. 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 Terms "Interrupts" and "Exceptions" Are Indefinite in the Context of the Intrinsic Record. In the plain language of the claims, the cause register means must contain information about both interrupts and exceptions – as confirmed by the prosecution history passages cited above for "cause register means." Thus, interrupts and exceptions must be entirely distinct types of events because the intrinsic record distinguishes between these two things and the claims require both distinct types of events. However, the intrinsic record does not provide any means for understanding the difference between an "exception" and an "interrupt." Because the claim leaves a zone of uncertainty about the boundaries between these two distinct events, the claim is indefinite. The definiteness provision in 35 U.S.C. § 112 "require[s] that a patent's claims, viewed in light of the specification and prosecution history, [must] inform those skilled in the art about the scope of the invention with reasonable certainty." Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120, 2129 (2014). "[A] patent must be precise enough to afford clear notice of what is claimed, 15 DM2\10335838.5 3 thereby 'appris[ing] the public of what is still open to them.'" Id. at 2129 (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) (quoting United Carbon Co. v. Binney & Smith Co., 317 U.S. 228, 236 (1942)). The patent must provide information with respect to "objective boundaries" on what is, and is not, infringing. Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364, 1371 (Fed Cir. 2014): Although absolute or mathematical precision is not required, it is not enough, as some of the language in our prior cases may have suggested, to identify "some standard for measuring the scope of the phrase.". The Supreme Court explained that a patent does not satisfy the definiteness requirement of § 112 merely because "a court can ascribe some meaning to a patent's claims." Nautilus, 134 S. Ct. at 2130. The claims, when read in light of the specification and the prosecution history, must provide objective boundaries for those of skill in the art. See id. at 2130 & n.8 (indicating that there is an indefiniteness problem if the claim language "might mean several different things and 'no informed and confident choice is available among the contending definitions'") … see also 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."). Id. at 1370-71 (some citations omitted) (emphasis added). Thus, there must be some "objective boundary" between what is an "interrupt" and what is an "exception" so that the public is not faced with the "zone of uncertainty" of infringement. The specification does not provide any meaningful boundaries between "interrupts" and "exceptions." The specification and prosecution history uses both the terms "interrupts" and "exceptions" but do not identify the difference between the two terms. E.g., 331EX1 at 5:1-10; 6:68-7:3. For example, the specification identifies that both exceptions and interrupts may be caused by software / instructions. Compare id. at 3:8-10 ("the three bit output will indicate whether execution of the instruction resulted in an exception") with 7:1-3 ("Bit locations 34 through 18 are used to store an indication of all pending interrupts (external, software, co-processor)" (emphasis 16 DM2\10335838.5 3 added). See also id. at claim 25 ("indication of pending interrupts includes at least one of an indication of external, software, or co-processor interrupt.") (emphasis added). The intrinsic record compels that "exceptions" and "interrupts" are distinct things that are separately required by the claims. However, the intrinsic record does not provide any objective boundaries. Thus, the terms (and encompassing claims) are indefinite. 2. Extrinsic Evidence Confirms That There Is No Accepted Understood Boundaries Between These Terms. The extrinsic evidence confirms that the terms "interrupts" and "exceptions" are used inconsistently by those of skill in the art – thus rendering a claim that requires a distinction between the two to be indefinite. For example, one of the most widely known and cited computer architecture books is "Computer Architecture A Quantitative Approach" written by John Hennessy and David Patterson ("Hennessy"). Hennessy confirms the indefinite nature of any distinction between these terms. In assessing "interrupts" and "exception" events, Hennessy notes: The enlarged responsibility of interrupts has led to the confusing situation of each computer vendor inventing a different term for the same event, as Figure 5.9 on page 215 illustrates. Intel and IBM still call such events interrupts, but Motorola calls them exceptions; and, depending on the circumstances, DEC calls them exceptions, faults, aborts, traps, or interrupts… Clearly, there is no consistent convention for naming these events. Ex. 331EX6 at 216 (emphasis added). Hennessy's Figure 5.9 is damning to Bicameral's position as it shows that the exact same types of events are described as both "interrupts" or "exceptions:" 17 DM2\10335838.5 3 Id. at 215. As is plainly evident, those of skill in the art do not have any "objective boundaries" for distinguishing between these two different types of events. Other extrinsic evidence fully confirms Hennessy's statements that "there is no consistent convention for naming these events" as either an "interrupt" or an "exception." For example, the ARM architecture manual describes "interrupts" as types of "exceptions": 18 DM2\10335838.5 3 See Ex. 331EX7 (ARM Architecture Reference Manual 2000) at A1-3. Indeed, the ARM architecture describes both an "externally generated interrupt" and an "attempt to execute an undefined instruction" as an "exception": . Id. at A2-13. In contrast to the '331 patent (which describes and expressly claims software interrupts as "interrupts"), the ARM architecture manual describes software interrupts as a "software interrupt exception": Id. at A2-15. Given the lack of any objective boundaries between "interrupt" and "exception" in the intrinsic and extrinsic records, the claims all are indefinite because the claims require information about both types of events and there is no ability to understand what types of events would correspond to each of these terms. Simply put, the public cannot ascertain the scope of the claims, creating a zone of uncertainty – the epitome of indefiniteness. 3. Bicameral's "Plain and Ordinary Meaning" Constructions Confirm the Inability To Distinguish Between These Items. Bicameral's approach is to just throw the construction of these terms to the jury. This is plainly incorrect in light of the prosecution history that distinguished between these terms and required both interrupts and exception information to be present in the cause register. 19 DM2\10335838.5 3 Bicameral's inability to articulate a particular "plain and ordinary meaning" that distinguishes between these two terms is telling. If there were "objective boundaries" between these terms, Bicameral could readily articulate exactly what those boundaries are – as is required by Nautilus and Federal Circuit law. Instead, Bicameral leaves a zone of uncertainty – precisely the zone that the Supreme Court and Federal Circuit prohibit. 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 1. NXP's Construction Reflects the Specific Meaning Given to "Cause" The patentee's own statements during the reexamination provide the specific guidance for the meaning of this term. During the reexamination, the patentee added claim 23 that recites "23. A processor according to claim 1, wherein said information comprises cause information" (emphasis added). Thus, the only distinction in claim 23 is the specific meaning of "cause information." The reexamination Examiner forced the patentee to identify the "written description" support for the new claims, including claim 23. In response, the patentee identified the following passages as describing the cause information: "6:62-7:15, FIGS. 1A and 1B." Ex. 331EX3 at 16. The only passage cited by the patentee states: If cause register information is being stored, bit location 40 is used to indicate whether the exception occurred while the processor was executing an instruction in the branch delay slot. (This applies to pipelined processors such as RISC processors.) Bit locations 39 through 35 are used to store processor related exception conditions. Bit 20 DM2\10335838.5 3 locations 34 through 18 are used to store an indication of all pending interrupts (external, software, co-processor. The HOVRF field at bit location 17 is used to indicate whether the internal event history buffer has overflowed. The TR bit 16 is used to indicate a timestamp rollover and bits 15 through 0 are used to store a sixteen bit timestamp. Ex. 331EX1 at 6:62-7:15 (Figures 1A and 1B do not add any help to the analysis) (emphasis added). The cause register thus indicates three different types of "causes:" (1) whether it is an exception; (2) whether the instruction was a jump register instruction; or (3) a change in the status of an interrupt line. This is consistent with the '331 specification at 3:20-22 that recites "the contents of the cause register indicates an exception, a jump register instruction, or a change in the status of an interrupt line." The specification does not contain the term "cause information." However, as noted above, the patentee identified the passage that provides written description support. NXP's construction construed the claim term in concert with that written description support. 2. Bicameral's Construction Merely Rearranges the Words Without Guiding the Jury on the Meaning of the "Cause." Bicameral's construction merely moves the word "cause" from before "information" to after "information." This is not helpful to the jury. More fundamentally, Bicameral's construction does not help the jury understand what the "cause" might be under the teachings of the patent. Bicameral does not associate the "cause" with any particular sequence of events. Furthermore, Bicameral's construction does not reflect the unequivocal statements made by the patentee to convince the Examiner that written description for "cause information" was present in the '331 patent. Absent tying the "cause" to the specific "causes" in the specification, Bicameral's construction renders the claim term indefinite. 21 DM2\10335838.5 3 V. CONSTRUCTION OF CLAIM TERMS FOR THE '538 PATENT A. Term: "dynamically computing" (Claims 1, 14, 21) Bicameral's Construction NXP's Construction Plain meaning (according to Bicameral), or Plain meaning (according to defendant NXP), alternatively, "computing in real-time or near- or alternatively, "computing in real-time" real-time" The '538 Patent is entitled "Real-Time Transient Pulse Monitoring System." Ex. 538EX1 ('538 Patent). The asserted claims recite basic elements of most any transient monitoring system, namely, receiving an analog transient signal, and converting that analog signal into digital data and processing the digital data. The claims also recite specific language that is not amenable to many practical commercial applications, including a phrase whose construction the parties dispute: "dynamically computing." The prosecution history shows a first action allowance. Claim 21 is representative: 21. A method of characterizing a stimulus represented by an analog signal, the method comprising: continuously receiving digital data digitized from the analog signal representing the stimulus; and dynamically computing from the continuously received digital data a value that characterizes a parameter of the stimulus while receiving new digital data digitized from the analog signal representing the stimulus. Ex. 538EX1, claim 21 (emphasis added to show disputed term). The named inventors designed their transient pulse monitor in a way that is not amenable to many practical commercial applications because the intended use was detecting whether a lightning strike (one of the fastest transients) caused damage to a spacecraft or its payload such that a launch countdown should be aborted. This intended use is reflected in the specification and also in the inventors' own section 102(b) prior art article published just over one year before the patent filing, prior art that closely resembles the patent but is not listed in the prosecution record. Ex. 538EX3. 22 DM2\10335838.5 3 1. The Specification and the Extrinsic Evidence Dictate that "Dynamically Computing" Means "Computing in Real-Time" as per NXP's Proposed Construction According to the title, the invention is "a Real-Time Transient Pulse Monitoring System and Method." According to the field of the invention, the invention relates to "systems and method for real-time monitoring and measuring of transient phenomenon." Ex. 538EX1 at 1:10 (emphasis added). The problems with the prior art, according to the patent, are that "the characterization of the key parameters is not available in real-time" (and as seen in claim 21 above, "characterize[ing] a parameter" is exactly the phrase where "dynamically computing" appears), and that "input transients will go undetected if they occur during [a data] transfer period." Id. at 1:44-60. The specification emphasizes, "[o]bjectives of the present invention are to provide a transient pulse monitor [TPM] that is capable of measuring transients in real-time and to perform such real-time measurements without experiencing dead time, i.e., a period during which the monitor can miss a transient." Id. at 1:64-2:1 (emphasis added). The specification further describes the invention of the claims as follows: In a brief overview, the system and method of the invention feature continuously receiving an input analog signal; continuously sampling and digitizing the analog signal; buffering the digitized data; computing in real-time from the digitized data a parameter value that represents a characteristic of the stimulus; … and continuing to sample, digitize, and buffer while outputting the parameter values to the system bus or storage medium, so as not to miss any transients …. Id. at 2:6-15. Once again, the phrase "computing in real-time from the digitized data a parameter value that represents a characteristic of the stimulus" is associated with computing a parameter, and closely tracks the language of claim 21: "dynamically computing from the continuously received digital data a value that characterizes a parameter" (The claim uses the arguably more formal 23 DM2\10335838.5 3 "dynamically computing" and "digital data" in place of the perhaps less formal "computing in real time" and "digitized data."). Other portions of the specification also make clear that the computation from the digital data is in "real-time." According to Ex. 538EX1 at 7:42-44, "[t]he digital data passes to the respective digital circuitry 22, which, in accordance with the principles of the invention, computes key parameters of the stimulus from the digital data in real-time" (emphasis added). According to 8:17- 21, again, "[t]he digital data passes to the respective digital circuitry 22, which, in accordance with the principles of the invention, computes key parameters of the stimulus from the digital data in real-time" (emphasis added). Yet another indicator of the correctness of NXP's proposed construction comes just before the claims, where the applicant describes the '538 Patent invention as follows: [V]arious changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the following claims. More specifically, although the described embodiments achieve real-time transient pulse monitoring without dead time by employing an A/D converter, buffer memory, and a digital signal processor, various changes to this configuration may be made to ensure a continuous stream of digital data and real-time processing of that digital data stream. Id. at 14:23-35 (emphasis added). In other words, even according to the boilerplate just before the claims – where a patent applicant typically attempts to characterize the claims as broadly as possible – the claims are directed to "real time transient pulse monitoring without dead time" and even if any changes are contemplated, one must "ensure" – or in other words, make certain -- that the processing remains "real-time" processing. NXP's proposal that "dynamically computing" means "computing in real time" also finds support in extrinsic evidence. If "dynamically computing" were to be given a plain meaning in this context, NXP submits that it would be "computing in real time." For example, www.dictionary.com (visited August 12, 2019) for the term "dynamic," gives the example that "Dynamic websites 24 DM2\10335838.5 3 contain Websites that are generated in real time." See Ex. 538EX2. Further, the inventors' own prior art publication, which closely resembles the patent but is not listed in the prosecution record, also uses the term "real time," indicating that its "Transient Pulse Monitor … continuously analyzes sensor inputs in real time and provides a summary of important transient characteristics. … The TPM electronics continuously monitors the sensor inputs with zero 'dead time' and guarantees that critical events are never missed," language that closely resembles the '538 Patent and its "Real Time Transient Pulse Monitor." See Ex. 538EX3 at 2, and Ex. 538EX1 at Title ("Real Time Transient Pulse Monitor") (emphasis added); 1:64-2:2 ("Objectives of the present invention are to provide a transient pulse monitor [TPM] that is capable of measuring transients in real-time and to perform such real-time measurements without experiencing dead time, i.e., a period during which the monitor can miss a transient."). 2. The Court Should Reject Bicameral's Proposed Construction that uses the Term "Near" Real-Time That Is Based on Bicameral's Misreading of One Sentence of the Specification, and Is Vague as to Metes and Bounds Bicameral argues plain meaning, but it is clear that the parties have a different understanding of what plain meaning is for "dynamically computing" in this context. Alternatively, or as an explanation of what it understands to be plain meaning, Bicameral proposes adding the term "near" to NXP's proposed construction, arriving at the additional phrase "near real time." When NXP asked Bicameral during the meet-and-confer process to define what Bicameral meant by the term "near real-time," Bicameral did not provide a definition and instead pointed only to a single sentence in the specification -- a sentence that Bicameral plainly misreads. Specifically, Bicameral quotes a single occurrence of the phrase "near real time" in the specification, but in a context that a "user can determine in near-real-time" if there is an issue (emphases added), where the data was transmitted, stored, and presented to the user after it was computed. See Ex. 538EX1 at 5:67-6:6 (emphasis added): 25 DM2\10335838.5 3 For example, the application program can graphically present the computed values to a user in a graphic user interface by which the user can visually determine from the displayed parameter values whether potentially harmful transient phenomena have occurred. As another example, the application program can compare each computed parameter value with a predetermined threshold value and set an audible or visible system alarm if the parameter value exceeds the threshold value. Accordingly, a user can determine in near-real-time if transient phenomena have occurred (i.e., delayed from real-time by the time taken for the conversion circuitry 20 to receive and convert the analog signal into digital data and for the digital circuitry 22 to compute and transmit the parameter values to the storage system 28). Regardless of the total time it takes to "transmit," "stor[e]," and present to a "user" for interpretation, per the passage quoted by Bicameral, in every independent claim, the phrase "dynamically computing" is associated with computing. The values are transmitted to storage and data presented to the user for interpretation only after the system has "dynamically computed" – i.e., computed in real time. The Court should reject Bicameral's attempt to misconstrue a passage in a way that flies in the face of all the other parts of the specification – the Title, the Field, the Summary, the Description, and even the boilerplate just before the claims – all of which require "real time" computing as set forth above. Bicameral also should not be allowed to incorporate the term "near" – which is vague, without metes and bounds, and still undefined by Bicameral -- into the claims and treat the claims as a nose of wax in litigation, after having included terms in the claims such as "dynamically computing" that limited the claim scope to secure a first action allowance. VI. CONCLUSION For these reasons, NXP respectfully requests the Court construe the disputed claim terms in accordance with NXP's proposed constructions. 26 DM2\10335838.5 3 Dated: August 12, 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. 27 DM2\10335838.5 3 CERTIFICATE OF SERVICE I certify that on August 12, 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\10335838.5