Bicameral LLC v. NXP USA, Inc. et al

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

RESPONSE Claim Construction Brief to {{43}} Brief, by Bicameral LLC.

Interested in this case?

Current View

Full Text

5 IN THE UNITED STATES DISTRICT COURT FOR THE WESTERN DISTRICT OF TEXAS WACO DIVISION BICAMERAL, LLC, Plaintiff, Case No. 6:18-cv-00294-ADA v. JURY TRIAL DEMANDED NXP USA, INC., NXP SEMICONDUCTORS N.V. AND NXP B.V., Defendants. PLAINTIFF BICAMERAL LLC'S RESPONSIVE BRIEF ON CLAM CONSTRUCTION 5 TABLE OF CONTENTS I. DISPUTED CLAIM TERMS .......................................................................................... 1 A. "program counter means … for indexing said instructions" ('331 Patent, claims 1 and 21) ................................................................................ 1 B. "cause register means for indicating information regarding interrupts and exceptions" ('331 Patent, claim 1) .............................................................................................. 4 C. "cause register means for indicating cause information regarding interrupts and exceptions" ('331 Patent, claim 21) ............................................................................................ 7 D. "interrupt[s]" and "exception[s]" ('331 Patent, claims 1 and 21) ................................................................................ 9 E. "first output" ('331 Patent, claims 1 and 21) .............................................................................. 11 F. "first decoder means for indicating information about an instruction executed by said processor during a clock cycle" ('331 Patent, claims 1 and 21) .............................................................................. 13 G. "cause information" ('331 Patent, claim 21) .......................................................................................... 15 H. "dynamically computing" ('538 Patent, claims 1 and 21) .............................................................................. 17 1. NXP's Thinly Veiled Inequitable-Conduct Allegation Has No Merit...... 17 2. NXP's Proposed Construction Is Unduly Limiting .................................. 18 i 5 TABLE OF AUTHORITIES Cases Applied Med. Res. Corp. v. United States Surgical Corp., 448 F.3d 1324 (Fed. Cir. 2006) ........ 15 Cisco Sys., Inc. v. Innovative Wireless Solutions, LLC, 2015 WL 128138 (W.D. Tex. Jan. 8, 2015) ............................................................................. 12 Cox Communs., Inc. v. Sprint Commun. Co. LP, 838 F.3d 1224 (Fed. Cir. 2016) ......................... 9 DESA IP, LLC v. EML Techs., LLC, 211 Fed. Appx. 932 (Fed. Cir. 2007) ........................... 3, 8, 9 Digital-Vending Servs. Int'l, LLC v. Univ. of Phoenix, Inc., 672 F.3d 1270 (Fed. Cir. 2012) ..... 17 Epos Tech. Ltd. v. Pegasus Tech. Ltd., 766 F.3d 1338 (Fed. Cir. 2014) ...................................... 12 Kara Technology Inc. v. Stamps.com Inc., 582 F.3d 1341 (Fed. Cir. 2009) ................................ 17 Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898 (2014) ................................................... 10 Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) ........................................................ 12, 17 Salazar v. Procter & Gamble Co., 414 F.3d 1342 (Fed. Cir. 2005). .............................................. 7 Wenger Mfg. v. Coating Mach. Sys., 239 F.3d 1225 (Fed. Cir. 2001)............................................ 8 Statutes 35 U.S.C. § 112 ¶ 6 ........................................................................................................... 1, 4, 7, 14 ii 5 I. DISPUTED CLAIM TERMS A. "program counter means … for indexing said instructions" ('331 Patent, claims 1 and 21) Bicameral's Construction Defendants' Construction Function: indexing said instructions. 35 U.S.C. § 112 ¶ 6 Structure: program counter (such as 24a, 24b, NXP's original function: indexing contents 24c) as described in Fig. 1, Abstract, col. 3:33- of memory means 42, col. 4:7-7:10, and claims; and equivalents. NXP's current function: indexing said instructions structure: program counter 24 which contains (i) an index of the instructions in an associated IRAM and (ii) pointer to the index as they instruction are executed. (and equivalents thereto) In its opening Markman brief, NXP apparently changed its proposed function for this term. During the claim construction exchange, NXP proposed that the function for the program counter means is "indexing contents of memory means": Defendants' Disclosure of Proposed Claim Constructions, July 23, 2019 (Ex. 8)1. However, NXP apparently has since changed its proposed function for this term to "indexing said instructions"—matching Bicameral's proposed function. While Bicameral appreciates NXP's move to match Bicameral's proposed function, NXP's proposed structure for the term is a remnant from NXP's no-longer proposed construction. NXP's proposed structure for this term is 1 In this brief, citations to Exhibits 1-7 refer to exhibits to the August 12, 2019 Kheyfits Declaration and citations to Exhibits 8-9 refer to exhibits to the September 3, 2019 Kheyfits Declaration. 1 5 beyond that required for "indexing … instructions" and is more appropriately tailored to "program counter means … for indexing contents of said instruction memory means"—a function that NXP has abandoned. First, NXP's proposed structure is more closely associated with indexing contents of a memory than with indexing instructions, which may be located in the instruction memory or may be stored outside of such memory. NXP's proposed structure for the program counter limits indexing of instructions to only those stored "in an associated IRAM," requiring an index of instructions stored in the IRAM and pointing to that index. But the now-agreed upon function of this term is "indexing said instructions"—not indexing the contents of a memory. Indeed, claims reciting "indexing contents of said instruction memory means" are not asserted in this action. The difference between the two concepts is visible when the different claims in which these terms appear are placed side-by-side: Claim 1 (asserted and disputed): Claim 11 (not asserted): In the disputed language of claim 1, the function of "indexing said instructions" is not limited to instructions that have been stored in the IRAM. The claim recites "indexing said instructions" not "indexing said stored instructions." And the '331 Patent provides for indexing instructions based on information not necessarily stored in the IRAM, such as a jump register. For example, the '331 Patent provides a scenario where "the instruction in IRAM pointed to by the program counter includes code indicating that it is a jump instruction to a location in the program determined by the value of a variable." Ex. 1, col. 4:64-67. The '331 Patent also 2 5 provides a scenario where "the instruction in IRAM pointed to by the program counter includes code indicating that it is a jump instruction to an absolute address in the program." Id., col. 4:59- 61. Thus, the structure for "indexing said instructions" does not require "an index of the instructions in an associated IRAM" nor a "pointer to the index." As the Federal Circuit explained, "[t]he structure corresponding to [the claimed means] necessarily varies from claim to claim, depending on the functions disclosed." DESA IP, LLC v. EML Techs., LLC, 211 Fed. Appx. 932, *15 (Fed. Cir. 2007) Second, neither the patentee nor the USPTO understood the "program counter means" to be as limited as NXP alleges. The original prosecution history for the '331 Patent and its reexam history are devoid of any mentions of NXP's proposed structure for this term, either in office actions or responses thereto. See, for example, March 4, 2011 Office Action in Ex Parte Reexamination on p. 4 ("Augsburg teaches, e.g., an instruction address register (IAR) 110, 'commonly known as the program counter,' for indexing the instructions. See, e.g., col. 5:62-65; col. 6:12-15.") Ex. 3, at BC_GEN_0002156. For reference, col. 5:62-65 of U.S. Patent No. 5,996,092 to Augsburg et al. states: Ex. 9, at BC_GEN_0002996. For further reference, col. 6:12-15 of Augsburg states: Ex. 9, at BC_GEN_0002996. Notably, there is no reference to NXP's proposed structure in the office action, cited reference, or the patentee's response thereto. In view of the above, the 3 5 structure proposed by NXP is not required by the claims, the specification, or the prosecution history. B. "cause register means for indicating information regarding interrupts and exceptions" ('331 Patent, claim 1) Bicameral's Construction Defendants' Construction Function: indicating information regarding 35 U.S.C. § 112 ¶ 6 interrupts and exceptions function: indicating information regarding interrupts and exceptions Structure: cause register (such as 26a, 26b, and structure: Cause Register 26 that may store 26c) as described in Fig. 1, Abstract, col. 3:13- information about both (a) exception 42, col. 4:7-7:10, and claims; and equivalents. conditions; and (b) the pending interrupts simultaneously (and equivalents thereto) The parties agree that the function of this term is "indicating information regarding interrupts and exceptions." The parties also agree that the cause register may store information about exceptions and interrupts. NXP, however, argues that the cause register must store information about both exception conditions and pending interrupts simultaneously. NXP argues that its proposed structure is required by the specification and prosecution history of the '331 Patent. NXP is not correct. First, having the capability of storing information about exceptions and interrupts does not mandate storing both simultaneously. NXP entirely ignores disclosure in the '331 Patent which allows the contents of the cause register to be an interrupt or an exception: Ex. 1, col. 5:2-3. NXP focuses on a single sentence in the specification which states that "Bit locations 39 through 35 are used to store processor related exception conditions. Bit locations 34 through 18 are used to store an indication of all pending interrupts (external, software, co- processor.)" Id., col. 6:66-7:3. However, while data from the cause register may be captured 4 5 into some of those locations, the 44-bit entries referred to in the specification describe the history buffer, not the cause register. See Ex. 1, '331 Patent, col. 3:33-34 ("[a]ccording to the presently preferred embodiment, each entry in the event history buffer is forty-four bits."). And there is nothing controversial about storing different kinds of information in different bit locations of a history buffer – it provides a more precise location for each kind of information. In sum, while the cause register of the '331 Patent must be capable of storing information about interrupts and exceptions (as the claims also require), the structure of the cause register does not need to store both simultaneously. Second, contrary to NXP's arguments, no person involved in the prosecution and reexamination of the '331 Patent stated that both exceptions and interrupts must be stored simultaneously, or at the same time, or concurrently. The reexamination arguments highlighted the lack of a prior art register that was capable of storing information beyond a single type of program flow deviation. For example, the IBM PowerPC 403GA User's Manual disclosed an External Interrupt Status Register ("EXISR") which stored only interrupt information. There was no capacity in EXISR to store anything but interrupt information. Thus, the patentee and its reexamination expert explained that the prior art did not have corresponding disclosure. NXP, however, mischaracterizes the testimony of the patentee's reexamination expert and argues on page 9 of its Opening Brief that: 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. But NXP's argument is undermined by the very quote it uses in support of its argument, where the patentee, relying on its expert declaration stated that: 5 5 Accordingly, the cause register performs at least two important functions, namely, it stores cause information about (a) exception conditions; and (b) the pending interrupts. Ex. 3, at BC_GEN_0002233. This statement is significant because (1) it explicitly notes that storing information about exception conditions and pending interrupts are "two…functions," not a part of the structure as NXP contends, and (2) it identifies two separate functions, in plural, for the cause register. Neither the patentee nor the expert ever stated that the cause register must perform both functions simultaneously. As to the bit location, the quote reproduced by NXP, once again, undercuts NXP's position. The patentee stated that: 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. Ex. 3, at BC_GEN_0002232. This quote is also significant because (1) it describes the "kind of information stored in the cause register," not the cause register structure, consistently with the function of the cause register means, and (2) the description is provided "in the context of…bits 40-18 of the history buffer," not the structure of the cause register. In similar vein, NXP mischaracterizes the Examiner's Reasons for Allowance, arguing on page 9 of its opening brief that: 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. But the Examiner never stated that the storage occurs "simultaneously"—that word (or any word conveying the "simultaneous" concept) is simply not in the Examiner's statement. As importantly, NXP confuses "specific bits" of a history buffer, referred to and explained by the patentee, with the structure of the cause register. And, once again, NXP confuses the "functions" of the cause register, as understood by the Examiner and the patentee, with the structure of the cause register. The Examiner simply stated that "neither [prior art register] stores both interrupts 6 5 and exception conditions as required by the claims," which is consistent with the claimed "cause register means for indicating information regarding interrupts and exceptions." Ultimately, an applicant's silence regarding statements made by the examiner during prosecution, without more, cannot amount to a "clear and unmistakable disavowal" of claim scope. See 3M Innovative Props., 350 F.3d at 1373-74 ("'Prosecution history … cannot be used to limit the scope of a claim unless the applicant took a position before the 'PTO. Schwing GmbH v. Putzmeister Aktiengesellschaft, 305 F.3d 1318, 1324-25 (Fed. Cir. 2002) (emphasis added). An applicant's silence in response to an examiner's characterization of a claim does not reflect the applicant's clear and unmistakable acquiescence to that characterization if the claim is eventually allowed on grounds unrelated to the examiner's unrebutted characterization."). After all, the applicant has disavowed nothing. Salazar v. Procter & Gamble Co., 414 F.3d 1342, 1345 (Fed. Cir. 2005). Third, NXP argues that if the patentee did not mean "simultaneous" storage of interrupts and exceptions, the claims should have recited "interrupts or exceptions" or "interrupts and/or exceptions." However, NXP's argument is flawed, particularly in view of the prosecution history. As discussed above, the patentee was clear in explaining that the IBM Manual described a register that indicated interrupt information. Thus, a disjunctive "or" (or "and/or") would not be consistent with the patentee's claimed invention. Accordingly, the patentee properly claimed "for indicating information regarding interrupts and exceptions" but did not require simultaneous indication of both. C. "cause register means for indicating cause information regarding interrupts and exceptions" ('331 Patent, claim 21) Bicameral's Construction Defendants' Construction Function: indicating cause information 35 U.S.C. § 112 ¶ 6 regarding interrupts and exceptions function: indicating cause information regarding interrupts and exceptions Structure: cause register (such as 26a, 26b, and 26c) as described in Fig. 1, Abstract, col. 3:13- structure: same as above 42, col. 4:7-7:10, and claims; and equivalents. 7 5 The parties agree that the function of this term is "indicating cause information regarding interrupts and exceptions." The parties disagree as to the structure of this term. As discussed in Section I.B above, NXP's proposed structure for the simultaneous storage of information regarding interrupts and exceptions by the cause register is flawed, and is contradicted by the claims, specification, and file history. Turning to the disputed term, the only difference between the two disputed "cause register" terms is that the "cause register" discussed in Section I.B above indicates "information" while the cause register in the instant Section indicates "cause information." NXP argues that that the structure of the cause register means is the same regardless of whether the cause register indicates "information" or "cause information." However, NXP's construction eliminates the difference between two distinct terms and ignores Federal Circuit precedent that limits the structure of a means-plus-function term only to that required for performing the proper function. "Under § 112, P 6, a court may not import functional limitations that are not recited in the claim, or structural limitations from the written description that are unnecessary to perform the claimed function." Wenger Mfg. v. Coating Mach. Sys., 239 F.3d 1225, 1233 (Fed. Cir. 2001). NXP's proposed construction violates both principles. See also DESA IP, 211 Fed. Appx. 932 at *15 ("The structure corresponding to [the claimed means] necessarily varies from claim to claim, depending on the functions disclosed."). The function of providing "cause information" is narrower than the function of providing "information." The patentee explained that "in the patented claims, the word 'cause' is used as an adjective" and distinguished registers that do not provide cause information from the claimed cause register means. Ex. 3 at BC_GEN_0002235. By attempting to rely on the same structure for both types of cause register means, NXP is ignoring the additional structure required to 8 5 indicate information regarding the cause of the interrupts and exceptions, which is not required to simply indicate information in the "cause register means" of Section I.B above. See also DESA IP, 211 Fed. Appx. 932 at *15. Even assuming the structure for both terms is the same, it would not be limited to "simultaneous" storage as discussed above. D. "interrupt[s]" and "exception[s]" ('331 Patent, claims 1 and 21) "interrupt[s]" Bicameral's Construction Defendants' Construction no construction required/plain and ordinary Indefinite meaning "exception[s]" Bicameral's Construction Defendants' Construction no construction required/plain and ordinary Indefinite meaning NXP's position is that "[b]ecause the claim leaves a zone of uncertainty about the boundaries between [interrupts and exceptions], the claim is indefinite." If adopted, NXP position would invalidate all claims of the '331 Patent as the phrase "interrupts and exceptions" appears in every independent claim. However, NXP failed to establish indefiniteness by clear and convincing evidence and its arguments should be rejected. Cox Communs., Inc. v. Sprint Commun. Co. LP, 838 F.3d 1224 (Fed. Cir. 2016) ("Any fact critical to a holding on indefiniteness must be proven by the challenger by clear and convincing evidence."). As an initial matter, the expert declaration of David Hansquine, M.S., provides evidence of the understanding by a person skilled in the art as to the respective meanings of these two terms and establishes that such a person would understand the scope of the claims with reasonable certainty. See August 12, 2019 Hansquine Decl. (Dkt. No. 44-9) ¶¶ 23-35. Mr. Hansquine confirms that the well understood meaning of interrupts and exceptions is consistent with the usage, and description of those terms, in the '331 Patent. See id. at ¶35. 9 5 NXP argues that certain books and microprocessor manufacturers described the same type of events as "interrupts" or "exceptions." But because some books or manufacturers depart from the conventional understanding at the time, does not render the terms meaningless. While taken in context of a particular book or processor, the meaning may be redefined, but it does not change the fact that the meaning in the art remained well understood and reasonably certain. As discussed in Bicameral Opening Brief at p. 5, experts, Examiners, and NXP itself use the terms interrupts and exceptions, strongly indicating that these terms have a reasonably certain understanding. Moreover, NXP now proposes using these very terms in construing "cause information" as: cycle by cycle information regarding the current instruction being executed by the processor; capable of indicating at least one instance of each of the following: whether it is an exception, a jump / branch instruction based on the contents of a register or a change in the status of the interrupt line Section 0 below (emphasis added). If NXP is able to use these very words ("interrupt" and "exception") presumably to assist the jury in understanding the scope of the claim and to impart clarity, then these words, evidently, are not as indefinite as NXP argues. Most importantly, however, the determination of indefiniteness is gauged on the basis of claims, not on the basis of a claim term. Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898, 910 (2014) ("Cognizant of the competing concerns, we read §112, ¶2 to require that a patent's claims. . . inform those skilled in the art about the scope of the invention with reasonable certainty.") (emphasis added). Here, each of the claims recites "interrupts and exceptions." And regardless of whether a particular event is categorized as an interrupt or an exception there is no question that a person of ordinary skill in the art would understand with reasonable certainty that such an event is within or outside the claim scope. In other words, it would be sufficient to determine whether a particular event falls into the broad, combined category of "interrupts and 10 5 exceptions." Even the events that are characterized as interrupts in one book and as exceptions in another book, would fall within the claims' scope. Contrary to NXP's contention, the claim language provides a reasonably-certain scope of the claim. NXP does not point to a single event that is an interrupt according to one source, but is neither an interrupt nor an exception according to another. If a particular event is an interrupt or exception, then the event is within the claim scope and if the event is neither an interrupt nor an exception then it is outside the scope. The precise demarcation between "interrupt" and "exception" that NXP urges is not required for definiteness, and is also unnecessary in view of the specific claims at issue. E. "first output" ('331 Patent, claims 1 and 21) Bicameral's Construction Defendants' Construction no construction required/plain and ordinary "3-bit output interpreted as shown in Table meaning 1" NXP does not argue that "first output" is a means-plus-function term, or provide a function or structure for the "first output." Yet, NXP's proposed construction focuses on one of several embodiments for the first output, excluding others, and violates at least two claim construction principles pertinent to this term. First, it is improper to limit claims to an embodiment even if it is a preferred embodiment or the only embodiment disclosed in the patent. Cisco Sys., Inc. v. Innovative Wireless Solutions, LLC, 2015 WL 128138, *2 (W.D. Tex. Jan. 8, 2015). See also Epos Tech. Ltd. v. Pegasus Tech. Ltd., 766 F.3d 1338, 1341 (Fed. Cir. 2014) ("it is improper to read limitations from a preferred embodiment described in the specification—even if it is the only embodiment—into the claims absent a clear indication in the intrinsic record that the patentee intended the claims to be so limited."). In fact, the 3-bit output was not even the only embodiment disclosed in the specification. As noted in Bicameral's opening brief, the inventors of the '331 Patent disclosed 11 5 an "n-bit" output in the original application. See Bicameral's Opening Brief at Section E, pp. 15- 16. Second, according to the claim differentiation presumption that NXP fails to overcome, NXP's proposed construction is incorrect. Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005) ("Differences among claims can also be a useful guide in understanding the meaning of particular claim terms.") Here claim 1 of the '331 Patent recites "first output" without any further limitations on the number of bits; claim 5, which depends on claim 1, recites "said first output consists of a three bit parallel output"; and claim 10, which ultimately depends on claim 1 as well, recites "said first output is an n-bit parallel output." Accordingly, the proper construction of "first output" must be broad enough to encompass 3-bit output and n-bit output and cannot be limited to just 3-bit output, which would render claim 5 superfluous and claim 10 impossible. To defend its flawed construction, NXP improperly treats the "first output" as if it were part of the structure in the means-plus-function claim term, ignoring the fact that "first output" appears outside of the "means" language in the claims. NXP states that "[t]he claims recite the 'first decoder means having a first output, wherein said first output provides information regarding activity of said processor in real time." NXP Opening Brief at 14. NXP then leaps to the following conclusion, as if it logically follows from the previous sentence: 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.' Id. at 15. By the above, NXP implies that the structure underlying the first decoder means—as performing the corresponding function—must include "first output," and that the "first output" should be limited to the disclosed structures in the specification. But this conclusion does not 12 5 follow. The claim separately recites that the "first decoder means [has] a first output." See, e.g., Ex. 1, the '331 Patent, claim 1. If the "first output" was part of the "first decoder means" structure, the recitation would be superfluous. Therefore, the "first output" is not part of the "first decoder means" structure and is not required to be construed as means-plus-function or even consistently with the "first decoder means," as NXP argues. Moreover, even if the first output was construed as a means plus function element (for which NXP has not provided a function or structure), NXP's construction would still omit the "n-bit output" embodiment disclosed by the inventors at filing. This dispute simply underscores that limiting the first output or first decoder to a "3-bit output" is a flawed construction that omits embodiments, whether in means-plus-function format or not. Accordingly, "first output" has its plain and ordinary meaning and requires no further construction. For further clarity, the term "output" is not in dispute as NXP uses that term in its own construction and "first" is used as a label to distinguish it from a "second output." See Ex. 1, the '331 Patent, claim 6. F. "first decoder means for indicating information about an instruction executed by said processor during a clock cycle" ('331 Patent, claims 1 and 21) Bicameral's Construction Defendants' Construction Function: indicating information about an 35 U.S.C. § 112 ¶ 6 instruction executed by said processor during a function: indicating information about an clock cycle instruction executed by said processor during a clock cycle Structure: first decoder (such as 28a, 28b, 28c) structure: Decoder 28 with three bit output as described in Fig. 1, Abstract, col. 2:62-3:32, (elements 30a, 30b, 30c) on a cycle by cycle col. 3:43-58, col. 4:20-6:39, col. 7:21-8:10, basis which is indicative of the processor 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) The parties agree that the function of this term is "indicating information about an 13 5 instruction executed by said processor during a clock cycle." The parties, however, disagree as to its structure. NXP proposes an overly narrow construction that confuses function and structure, and actually contradicts the agreed-upon function. First, in order to support the verbose structure proposed by NXP for the first decoder, NXP repeatedly cites to the preferred embodiment's "three bit output" of the first decoder. But, as Bicameral explained in its opening brief, even at filing the inventors disclosed an "n-bit output" of a first decoder. See Dkt. No. 44, Bicameral's Opening Markman Brief, Section II.F at pp. 17-19. One skilled in the art would recognize that for an n-bit output, a 2-bit output would produce up to four states and a 4-bit output would produce up to 16 states. Plainly, the inventors did not intend to limit their invention to the exemplary 3-bit output. Second, a three-bit output is not required to satisfy the agreed-upon function of this term. NXP is not suggesting that the function of this term is "indicating all possible information about an instruction executed by said processor during a clock cycle." Instead, NXP agreed that "indicating information…" is the proper function. But even in the exemplary Table 1, which NXP urges to be incorporated as part of the structure, a two-bit output is sufficient to "indicate information about an instruction executed by said processor during a clock cycle." The highlighted two-bit output in Table 1 below indicates information about the executed instruction: 14 5 By NXP's own logic, incorporating additional bits would go beyond "all structure that actually performs the recited function." See Applied Med. Res. Corp. v. United States Surgical Corp., 448 F.3d 1324, 1334 (Fed. Cir. 2006) ("the inquiry should be restricted to the way in which the structure performs the properly-defined function and should not be influenced by the manner in which the structure performs other, extraneous functions."). Third, NXP's proposed structure of "on a cycle by cycle basis which is indicative of the processor 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" is not structure. Instead, NXP introduces a number of functional steps into its purported "structure" of the term in attempt to backdoor further functional limitations into the construction. But NXP's functional language is not structure, and simply highlights that to a person skilled in the art, the structure of this term is clear in view of the specification and the architecture that it proposes for the first decoder means. Forth, while NXP argues that "Bicameral's construction merely replaces 'first decoder means' with 'first decoder'" and that "[t]he deletion of the claim term 'means' is improper," NXP's own construction of this term removes "means" and argues that the structure of the "first decoder means" is "Decoder 28…" Accordingly, both parties appear to agree that the term "means" need not appear in the construction; both parties agree that a decoder is the proper structure, but NXP attempts to load the structure with additional functional requirements unrelated to the claimed function. G. "cause information" ('331 Patent, claim 21) Bicameral's Construction Defendants' Construction Plain and ordinary meaning; requires no "cycle by cycle information regarding the construction current instruction being executed by the 15 5 processor; capable of indicating at least one In the alternative: "information regarding a instance of each of the following: whether it cause" is an exception, a jump / branch instruction based on the contents of a register or a change in the status of the interrupt line" NXP applies improper legal reasoning to construe this term. NXP argues that because the patentee identified a particular "written description" supporting "cause information," the construction of this term must be limited to that written description. NXP Opening Brief at 21. ("NXP's construction construed the claim term in concert with that written description support.") But the fact that a specification contains written description for a particular claim term (as it must) does not make the claim term necessarily limited to that description, as NXP implies. Limiting claims to an embodiment, even if the preferred or the only embodiment, is improper. Kara Technology Inc. v. Stamps.com Inc., 582 F.3d 1341 (Fed. Cir. 2009) (citing Phillips) ("The claims, not specification embodiments, define the scope of patent protection. The patentee is entitled to the full scope of his claims, and we will not limit him to his preferred embodiment or import a limitation from the specification into the claims.") NXP argues that "[a]bsent tying the 'cause' to the specific 'causes' in the specification, Bicameral's construction renders the claim term indefinite." NXP Opening Brief at 21. This is, again, NXP's attempt to limit "cause information" to a particular embodiment. Moreover, the claims already explain what the "cause information" pertains to. For example, claim 21 recites "cause information regarding interrupts and exceptions." Adopting NXP's construction that further overlaps limitations on top of cause information that already relates to interrupts and exceptions would render the claim language "regarding interrupts and exceptions" superfluous, which is improper. Digital-Vending Servs. Int'l, LLC v. Univ. of Phoenix, Inc., 672 F.3d 1270 (In Phillips, this court reinforced the importance of construing claim terms in light of the surrounding claim language, such that words in a claim are not rendered superfluous. 415 F.3d at 16 5 1314.) For example, when a claim refers to 'steel baffles,' this 'strongly implies that the term 'baffles' does not inherently mean objects made of steel.' Id. In this case, the reference in some claims to a "registration server being further characterized in that it is free of content managed by the architecture" strongly implies that the term "registration server," standing alone, does not inherently mean a server that is free of managed content.") NXP faults Bicameral's position that no further construction is required, or its alternative construction, as supposedly not being helpful to the jury. Bicameral disagrees because the construction proposed by NXP is so convoluted that it, rather than Bicameral's construction, would confuse the jury with NXP's verbose, multi-part construction (including "cycle by cycle," "a jump / branch instruction based on the contents of a register," and "interrupt line") that would require further elaboration for the jury. H. "dynamically computing" ('538 Patent, claims 1 and 21) Bicameral's Construction Defendants' Construction "computing in real-time or near-real-time" "computing in real-time" 1. NXP's Thinly Veiled Inequitable-Conduct Allegation Has No Merit In its Opening Brief, in addition to its claim construction position, NXP presents arguments related to non-infringement (invention "not amenable to many practical commercial applications"), invalidity (referring to the Sechi reference [NXP Ex. 538EX3] as a "section 102(b) prior art article"), and inequitable conduct (stating that the Sechi reference is "prior art that closely resembles that patent but is not listed in the prosecution record"). Bicameral submits that such arguments are not proper in the context of claim construction briefing. Nonetheless, to briefly address NXP's invalidity and inequitable conduct arguments, the differences between the claims of the '538 Patent and the Sechi reference are significant. Not only does Sechi perform the relevant computation with analog electronics in the analog domain, but Sechi explicitly 17 5 teaches away from using the digital circuitry claimed in the '538 Patent to continuously receive digital data and perform the relevant computations: The companion TPM electronics processes the data. . . all in the analog domain. . . . Unlike digitizer-based systems, the TPM is guaranteed never to miss a transient event. . . . As with all digitizing systems, there are limits on the data transfer rates and subsequent rearming times that may cause critical level transients to be missed. Sechi, Ex. 538EX3, pp. 1-2. Instead of using digital circuitry for the critical computations, which is the primary purpose of the '538 Patent, Sechi relegates digital circuitry to the role of providing visuals to the user over the Internet: While the digitizers are able to provide the actual high-frequency waveforms desired by may users, they have inherent limitations in duty cycle and large data storage requirements. . . . The master station uses web server technology to make the data available to users. Id. Accordingly, in view of the disclosure in Sechi, any allegations of invalidity over Sechi or of Sechi's materiality to claims of the '538 Patent are without merit. 2. NXP's Proposed Construction Is Unduly Limiting Turning to claim construction, despite NXP's best efforts to incorporate a limitation from the specification into the claims, NXP cannot avoid the fact that the claims do not recite "real time." NXP identified close to a dozen instances where real-time appears in the specification, but not a single instance of that phrase appears in the claims. Having used the phrase "real time" throughout the specification, there can be no doubt that the inventors knew how to use that phrase in the claims, had they chosen to do so. Faced with this flaw in its position, NXP tries to somehow tie its desired "real time" construction to the claims. NXP provides the rationale for its dubious arguments in the following parenthetical: The claim uses the arguably more formal "dynamically computing" and "digital data" in place of the perhaps less formal "computing in real time" and "digitized data." 18 5 NXP Opening Brief at 24. However, nowhere does the specification equate "dynamically" with "in real time." Nor is it clear why a "less formal" construction is preferred to a "more formal" construction. Even assuming that NXP is able to use the specification to limit the claims to "real time" through the construction of the word "dynamically," NXP has to explain away a passage in the specification that expressly provides for "near real time." 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). Ex. 2, the '538 Patent, col. 5:67-6:6. The above passage expressly contemplates near-real-time computation, i.e., delayed from real-time by the time required to carry out various operations, including computation. NXP mischaracterizes this passage as if it discusses the delay associated with operations only after computation. NXP Opening Brief at 26 ("The values are transmitted to storage and data represented to the user for interpretation only after the system has "dynamically computed" – i.e., computed in real time.") This is a misreading of the passage, which discusses "delay[] from real time" inherent in operations that occur before computing (receipt of analog signals and converting to digital), the computation itself, and operations performed after computation (transmission and storage). In other words, the inventors contemplated delay from real time for every operation of the claimed systems/methods. NXP's extrinsic support is equally unavailing. First, NXP uses a definition from 2019, which is not proper for purposes of claim construction. Second, the relied-upon definition does not support NXP's position and NXP is forced to rely on an exemplary use of the term in connection with unrelated technology (web page generation). 19 5 NXP's argument in support of its claim construction relies on a logical fallacy, namely, that if real-time processing is one way to accomplish the objective of avoiding dead time, then it must be the only way. As explained in the Bicameral Opening Brief at 20, a system may accomplish the objective of no dead time processing by sensing and analyzing stimuli without time gaps, but by introducing a delay in processing, which does not undermine the no-dead-time objective. Because the only difference between "real time" and "near real time" is delay, NXP's insistence on "real time" and resistance to "near real time" leads to the conclusion that to NXP "real time" means without delay, i.e., instantaneously. To the extent, NXP is attempting to attribute instantaneous processing to "real time," the Court should reject NXP's construction. First, any processing has an inherent delay and instantaneous processing (including computation) is impossible. Second, the inventors specifically included "near real time" in the specification to indicate that delay, without dead time, does not depart from the invention and that such embodiments should not be excluded from the claim scope. 20 5 Dated: September 3, 2019 Respectfully submitted, /s/ Dmitry Kheyfits Dmitry Kheyfits (Admitted Pro Hac Vice) California State Bar No. 321326 dkheyfits@kblit.com KHEYFITS BELENKY LLP 4 Embarcadero Center, Suite 1400 San Francisco, CA 94111 Tel: 415-429-1739 Fax: 415-429-6347 Andrey Belenky (Admitted Pro Hac Vice) New York State Bar No. 4524898 abelenky@kblit.com Hanna G. Cohen (Admitted Pro Hac Vice) hgcohen@kblit.com New York State Bar No. 4471421 KHEYFITS BELENKY LLP 1140 Avenue of the Americas 9th Floor New York, New York 10036 Tel. (212) 203-5399 Fax. (212) 203-6445 Raymond W. Mort, III Texas State Bar No. 00791308 raymort@austinlaw.com THE MOST LAW FIRM, PLLC 106 E. Sixth Street, Suite 900 Austin, Texas 78701 Tel/Fax: (512) 865-7950 Attorneys for Plaintiff Bicameral, LLC 21 5 CERTIFICATE OF SERVICE I hereby certify that all counsel of record who are deemed to have consented to electronic service are being served with a copy of this document and all accompanying documents via the Court's CM/ECF system on September 3, 2019. /s/ Dmitry Kheyfits Dmitry Kheyfits 22