Full opinion text
WILLIAM C. BRYSON, UNITED STATES CIRCUIT JUDGE In these consolidated infringement actions, Plaintiff Sycamore IP Holdings LLC ("Sycamore") filed suit against a number of defendants grouped into four cases: Case No. 2:16-cv-588, against AT & T Corp., AT & T Services, Inc., and Teleport Communications America, LLC (collectively, "AT & T"); Case No. 2:16-cv-589, against CenturyLink Communications, LLC, and Qwest Corporation (collectively, "CenturyLink"); Case No. 2:16-cv-590, against Level 3 Communications, LLC ("Level 3"); and Case No. 2:16-cv-591, against Verizon Business Global, LLC, and Verizon Services Corporation (collectively, "Verizon"). On February 15, 2018, the Court was informed that the parties in the Verizon case have entered into a settlement agreement. Accordingly, this order will not address any issues relating to that case. The Court has set trial in the action against Level 3 to begin on April 23, 2018, with the trials in each of the other two cases to follow. This order addresses a number of motions filed in advance of the Level 3 trial, some of which are filed by, or directed at, Level 3 alone, and some of which are filed by, or directed at, Level 3 and other defendants. This order will first address Sycamore's Motion for Partial Summary Judgment of Infringement by Performing the Accused Mappings Pursuant to the Accused Standards, Dkt. No. 185; Defendants' Motion for Summary Judgment of Noninfringement, No Direct Infringement, and No Willful Infringement, Dkt. No. 193; and Sycamore's Motion for Summary Judgment on the Scope of Level 3's Infringement, Dkt. No. 191. After construing the relevant claim terms, with the assistance of supplemental briefs, see Dkt. Nos. 418, 419, 420, 421, 512, and 514, and oral arguments by the parties at the motions hearing held on January 19, 2018, the Court DENIES Sycamore's motion for partial summary judgment of infringement (Dkt. No. 185), GRANTS the defendants' motion for summary judgment of non-infringement (Dkt. No. 193), and DENIES AS MOOT Sycamore's motion for summary judgment on the scope of Level 3's infringement (Dkt. No. 191). This order also addresses four motions for summary judgment relating to defenses raised by Level 3 and other defendants: Defendants' Motion for Summary Judgment of Invalidity Under 35 U.S.C. § 102(f) and 35 U.S.C. § 102(a), Dkt. No. 179; Defendants' Motion for Summary Judgment of Invalidity Under 35 U.S.C. Section 101, Dkt. No. 180; Sycamore's Motion for Summary Judgment of No Inequitable Conduct, Dkt. No. 186; and Sycamore's Motion for Summary Judgment on Equitable Estoppel, Fraud, Patent Misuse, Laches, Unclean Hands, and Waiver, Dkt. No. 183. The Court DENIED the first three of those motions following argument at the motions hearing, with an explanation for the Court's ruling on each motion. The Court GRANTED the fourth motion in part and DENIED it in part. In this order, the Court will expand on the explanations given in open court for its rulings on each of those four motions. The reasons for the Court's rulings in each instance incorporate both the Court's remarks during the motions hearing and the written elaboration on those remarks set forth below. BACKGROUND Sycamore alleges that the defendants have infringed claims 1 and 3-8 of U.S. Patent No. 6,952,405 ("the '405 Patent"). The patent is directed to a problem that arises during the electronic communication of information over networks when different communication protocols are used for different portions of the communication path. Transmission protocols that are frequently used in local area networks ("LANs"), such as Gigabit Ethernet ("GbE") or Fibre Channel, are inefficient for transmitting data over long-haul communication networks that are designed to carry data at high speeds and over long distances. Long-haul networks, sometimes referred to as wide area networks ("WANs"), therefore typically use different transmission protocols from those used in local networks; for example, long-haul networks often rely on optical communication protocols such as Synchronous Optical Networking ("SONET"). When multiple protocols are used, it is often desirable that messages transferred from a LAN system to a WAN system be transferred without the loss or corruption of information, a process known as "transparent transcoding." A. The '405 Patent A problem that engineers in the industry encountered during their efforts to devise transparent transcoding schemes was that differences in the bandwidth used by the LAN and WAN systems resulted in the inefficient use of the available WAN bandwidth. '405 patent, col. 1, line 52, through col. 2, line 11. The objective of the '405 patent was to create a transcoding protocol that would, for example, compress a GbE signal into fewer bits, thus enabling two GbE signals to be sent at once over a SONET link. Id., col. 2, ll. 53-59. To achieve that objective, the inventors of the '405 patent devised a transcoding system in which, for example, an 80-bit information group from the GbE transmission is converted into a 65-bit information stream for transmission over the SONET link without the loss of any information. Id., col. 7, ll. 41-48; see also id., Fig. 6. The 65-bit stream includes not only data, but also bits that indicate the locations and identities of any control characters that were contained in the information group. Id., col. 2, ll. 41-52; see also id., col. 3, ll. 37-45. The '405 patent refers to the input for the claimed encoding methods as an "information group." An "information group" is a series of bits comprising data words, control characters, or a combination of both data words and control characters. Dkt. No. 104, at 2. The output of the encoding methods is called the "encoded information stream." The parties agree that each "information group" is encoded into a single "encoded information stream," and that the two correspond one-to-one. See Dkt. No. 419, at 1 (Defendants: " 'Encoded information stream' refers only to the data corresponding to a single incoming 'information group.' "); Dkt. No. 420, at 1 (Sycamore: "The parties agree that each 'encoded information stream' corresponds to a single 'information group' and vice versa."). Claim 1 recites a method in which the encoding occurs through one of two processes, depending on whether the information group includes control characters. Claim limitation 1(a). If the information group contains only data words and no control characters, the first process is used. The first step is to generate a "data indicator." Claim limitation 1(b). The data indicator consists of one or more bits indicating whether the information group includes any control characters. Dkt. No. 104. The data indicator is combined with the data words, and both are included in the encoded information stream. The parties agree that the data indicator and the data words must be combined as part of the same encoded information stream. Dkt. No. 419, at 10 (Defendants: "The limitations require that the recited claim components [i.e., the data indicator and data words]...be combined/included in one encoded information stream."); Dkt. No. 420, at 1 n.1 (Sycamore: "Sycamore agrees the referenced fields are contained within the same 'encoded information stream.' "). If the information group contains one or more control characters, the encoding method uses the second process, which consists of four steps. First, the control characters are encoded to form "control codes." Claim limitation 1(c)(i). Second, a transition indicator is generated based on the number of control codes that are present in the information group. Claim limitation 1(c)(ii). A "transition indicator," which consists of one or more bits, indicates the occurrence of the last control code in the encoded information stream. Dkt. No. 110. Third, a location pointer is generated for each control code; the location pointer indicates the sequential position of the corresponding control character within the information group. Claim limitation 1(c)(iii). Finally, the control codes, data words, location pointers, and transition indicator are all combined to form the encoded information stream. Claim limitation 1(c)(iv). Claim 8, the only other independent claim asserted in this action, teaches a nearly identical method for encoding a multi-word information group. If the information group does not include control characters, the data words and a data indicator are encoded into an encoded information stream. Claim limitation 8(a). If the information group includes control characters, then: (i) the control characters are encoded into control codes; (ii) a transition indicator is generated; (iii) a location pointer is generated; and (iv) the control codes, the transition indicator, the location pointers, and any data words are combined into an encoded information stream. Claim limitation 8(b). B. The Accused Mapping Standards Sycamore accuses the defendants' networks of infringing the '405 patent to the extent that they use one of four transcoding methods, or "mappings," for which the Telecommunication Standardization Sector of the International Telecommunications Union ("ITU-T") has issued standards. Sycamore's theory of infringement is that those standardized transcoding methods are covered by the claims of the '405 patent and that the defendants' use of those standardized methods in their communication systems infringes the patent. For ease of reference, the Court adopts the defendants' nomenclature of referring to the four accused mappings as Mappings A through D. See Dkt. No. 193. Mapping A: In 2005, the ITU-T released a standard for what it called the Transparent Generic Framing Procedure ("GFP-T") in a document entitled ITU-T Recommendation G.7041/Y.1303. That standard, referred to as ITU G.7041, described a process for mapping LAN signals, such as Gigabit Ethernet or Fibre Channel signals, onto a transport network. Dkt. No. 185-2. Mapping B: In 2009, the ITU-T released a standard for mapping Gigabit Ethernet signals onto networks that use an ODU0 signal (an optical data transport protocol). The document containing that standard is entitled ITU-T Recommendation G.709/Y.1331, and the standard is referred to as ITU G.709 or the G.709 standard. Dkt. No. 185-3. The 2009 version states: "The mapping of the 1000BASE-X signal into GFP-T is performed as specified in [ITU G.7041]...." Id. at 84 (brackets in original). Mapping C: In 2012, the ITU-T released a new revision to ITU G.709 that, among other things, set out a standard for mapping 10 Gigabit Ethernet Fibre Channel signals onto networks that use an ODU2 signal (another optical data transport protocol). Dkt. No. 185-4. Mapping D: The 2012 version of ITU G.709 also described a standard for mapping 40 Gigabit Ethernet signals onto ODU3 (another optical data transport protocol). Id. DISCUSSION I. Claim Construction Following summary judgment briefing, the Court identified several infringement disputes that the Court considered to be predicated on disagreements regarding claim construction. The Court therefore directed the parties to file briefs on the newly identified claim construction issues. Dkt. No. 389. The parties filed briefs addressing those issues, Dkt. Nos. 418-421, and the Court heard oral argument on those issues at the January 19, 2018, motions hearing. The Court will address two of those issues here: the meaning of the term "encoded information stream," and the meaning of the term "control characters" in the phrases "encoding the control characters," claim limitation 1(c)(1), and "encoding control characters," claim limitation 8(b). The Court does not address the "data words" claim construction issue raised only by CenturyLink. See Dkt. No. 419, at 20-23. A. "Encoded Information Stream" With respect to the term "encoded information stream," the parties disagree about two interrelated issues: (1) whether an encoded information stream must be a continuous series of bits, such that when a data indicator is "combin[ed]" with the data words the data indicator bits and the data words are physically contiguous; and (2) whether the bits in an encoded information stream may be logically connected but physically separate in the outgoing data signal, such that the data indicator bits may be separated from the data words by bits from other, unrelated encoded information streams. Sycamore argues (1) that the '405 patent requires only that there be a "logical relationship" between the bits in an encoded information stream, and (2) that the word "combining" does not require physical contiguity. Sycamore notes that the specification permits the user to "arrange the fields...as desired," so long as the fields are sent in "prearranged sequential locations in the encoded information stream." '405 patent, col. 6, ll. 12-19. Sycamore also emphasizes a sentence in the specification that reads: "It is not necessary to have these fields [i.e., the control codes, the data words, and the transition indicator] be physically contiguous within the encoded information stream as long as the fields can be found according to predetermined logic." Id., col. 6, ll. 20-22; see also id., col. 4, ll. 56-60 ("It is understood that the data indicator field...and the data fields...may be arranged in many other predetermined orders within the encoded information stream."); id., col. 5, ll. 65-67 ("Again it should be appreciated that the first and second fields 414 and 418 and the sub-fields 418zmay be arranged in other predetermined orders."); id., col. 8, ll. 18-21 ("These fields can be arranged in any of a variety of different orders, as desired by the user, within the constraints as described above."). From these descriptions in the specification, Sycamore concludes that the bits of an encoded information stream need not be contiguous in the outgoing signal. Sycamore's position, however, begs the question. The quoted excerpts from the specification make clear that the various fields may be rearranged within the encoded information stream in any predetermined order, so long as those fields all appear within the same encoded information stream. Thus, it does not matter whether the control codes are transmitted first or last, or whether a control code is physically contiguous to its corresponding location pointer, so long as their positioning within the encoded information stream is predetermined. That much is beyond dispute. But that does not answer the question whether the encoded information stream itself consists of a continuous series of bits. That is, the specification does not unambiguously answer the question whether all of the bits belonging to a particular encoded information stream need to be physically contiguous, or whether the bits belonging to each encoded information stream can be intermingled with bits belonging to other information streams. While the specification is not explicit as to that issue, both intrinsic and extrinsic evidence supports the construction that an encoded information stream consists of a continuous series of bits. Both of the examples of encoded information streams depicted in the specification, Figures 3(a) and 3(b), depict a single block of contiguous bits. Figure 6, which "illustrates one example of the configurations for the encoded information stream 400 that may be generated according to the present encoding algorithm," '405 patent, col. 7, ll. 43-46, labels the bits in a 64B/65B encoded information stream sequentially, from bit 1 to bit 65. See also id., col. 7, line 41, through col. 8, line 21 (describing a preferred embodiment of the encoding method in a sequential, bit-by-bit process). Although the defendants concede that the specification does not expressly define the term "encoded information stream" to be limited to a continuous series of bits, they argue persuasively that a person of ordinary skill in the art would understand the term "stream" to impose a requirement of contiguity. For example, although dictionary definitions of the term "stream," including those cited by the defendants, are not identical, nor all equally relevant, they are consistent in suggesting that the term "stream," as of the date of the '405 patent application, was understood to refer to a continuous or sequential series of bits. See, e.g., Alan Freedman, The Computer Desktop Encyclopedia (2d. ed. 1999) (Stream: "A contiguous group of data." Streaming data: "Data that is structured and processed in a continuous flow, such as digital audio and video."); IEEE Standard Dictionary of Electrical and Electronics Terms (6th ed. 1997) (Stream: "An ordered sequence of characters, as described by the C Standard."); McGraw-Hill Dictionary of Scientific and Technical Terms (Sybil P. Parker, ed., 5th ed. 1994) (Stream: "A collection of binary digits that are transmitted in a continuous sequence, and from which extraneous data such as control information or parity bits are excluded."); Microsoft Computer Dictionary (5th ed. 2002) (Stream: "Any data transmissions, such as the movement of a file between disk and memory, that occurs in a continuous flow."); Official Internet Dictionary (Russ Bahorsky, ed. 1998) (Streaming: "A technique for transferring data in a continuous stream to allow large multimedia files to be viewed before the entire file has been downloaded to a client's computer."); U.S. Dep't of Commerce, Nat'l Tech. Info. Serv., Telecommunications: Glossary of Telecommunication Terms (1991) (Bit stream transmission: "The transmission of characters at fixed time intervals without stop and start elements. Note: The bits that make up the characters follow each other in sequence without interruption." Data stream: "A sequence of digitally encoded signals used to represent information for transmission."); Webster's New World Dictionary of Computer Terms (6th ed. 1997) (Stream: "A continuous flow of data through a channel."); Martin H. Weik, Communications Standard Dictionary (2d ed. 1989) (Bit stream: "An uninterrupted sequence of pulses representing binary digits transmitted in a transmission medium. For example, a continuous sequence of bits in a wireline or optical fiber." Data stream: "A sequence of characters or pulses used to represent information during transmission."). Although the Court does not adopt any single one of those definitions as the sole proper construction of the term "encoded information stream," as that term is used in the '405 patent, the dictionary definitions as a whole indicate that a person of skill in the art at the time of the invention would have understood that the word "stream" indicates contiguity, continuousness, or sequential ordering. Indeed, even Sycamore's expert, Dr. Scott Nettles, appears to have agreed with the thrust of those definitions when he testified in his deposition that "stream is a term of art and streams are sequences of things of indefinite extent." Dkt. No. 421-1, at 74:6-8. Sycamore argues that a person of ordinary skill in the art would understand that the encoded information stream could be "further encoded, encrypted, or scrambled prior to transmission over the network." Dkt. No. 420, at 4. For example, Dr. Nettles explained that a person of ordinary skill in the art would know that the outgoing signal would be multiplexed for transmission and de-multiplexed at the receiver. Dkt. No. 418-3 ¶¶ 22-23. That may be so. But the patent does not address whether the stream might be further encoded, encrypted, scrambled, or multiplexed once it is sent to the network; it merely requires that the outgoing signal be encoded into a stream before it is sent to the network. See '405 patent, col. 4, ll. 38-41 (describing that, when no control characters are present, the indicator bit and data words are "sent to the serializer 280 which generates the encoded information stream to be sent to the network 290"); id., col. 6, ll. 10-12 (describing that, when control characters are present, the data and control fields "are sent to the serializer 280 for generating the encoded information stream 400 to be sent to the network 290"); id., col. 6, ll. 27-28 ("At the receiving end 300, a deserializer 311 receives the encoded information stream 400 from the network 290."). That the stream may undergo additional encodings does not detract from the requirement that a stream be generated as part of the claimed methods. This construction of the term "encoded information stream" is harmonious with the patent's use of the term "combine." The patent makes clear that certain fields are combined to generate the encoded information stream. See, e.g., '405 patent, claim 1(b), col. 9, ll. 28-30 ("combining said data indicator with the data words of the information group to generate an encoded information stream"); id., claim 11, col. 11, ll. 16-17 ("generating an encoded information stream by combining said data indicator and the data words"); id., col. 2, ll. 33-36 ("[T]he control codes, the data words, the location pointers, and the transition indicator are combined for each information group to form the encoded information stream."). Under Sycamore's construction of "encoded information stream," the term "combin[ed]" would mean merely "logically connected" in some manner. That interpretation of the term "combine" is not supported by the '405 patent or any of the extrinsic evidence cited by Sycamore. If, however, "encoded information stream" means a contiguous set of bits such that the various fields are put together in a continuous stream, the term "combine" can assume its natural and ordinary meaning. See, e.g., Webster's Third New Int'l Dictionary of the English Language (2002) (Combine: "[T]o bring into close relationship."). The Court therefore construes "encoded information stream" to mean "a continuous series of encoded bits that is to be sent or received over the network and that corresponds to its respective information group." B. "Encoding Control Characters" The defendants argue that two of the accused mappings, Mappings C and D, do not satisfy the limitations of claims 1 and 8 that provide for encoding control characters into control codes. The defendants' argument raises two related claim construction issues: what it means to "encode," and what types of information can be included in a "control character." As for the term "encode," the parties agree that "encoding" control characters to control codes means that the control characters must be converted into a different form. Dkt. No. 418, at 11; Dkt. No. 419, at 18. The parties' agreed-upon construction of "control codes" as "encoded control characters," Dkt. No. 104, at 2, indicates that each control character must be encoded in some fashion. Furthermore, the specification provides that the encoding of the information stream results in a reduction in "the necessary bandwidth for transporting the information," '405 patent, col. 2, ll. 36-37, and that "[t]he control codes have fewer bits than the control characters contained in the information group," id., col. 4, ll. 24-25. Therefore, it is clear that each control character must be converted in some way that results in a reduction in the number of bits. Accordingly, the Court construes "encoding control characters" to mean "converting at least a portion of each present control character into a form that comprises fewer bits." Second, the parties dispute whether "control characters" consist exclusively of bits that represent system control information, or whether "control characters" can contain non-control information, including data information or block-type information. Although the parties previously agreed that "control characters" should be construed to mean "bits in an information group representing control information," Dkt. No. 104, at 2, Sycamore now argues for a construction that permits control characters to "include information relating to non-control information, so long as when considered in their entirety, they represent control information," Dkt. No. 418, at 9. The defendants contend that the patent draws a clear distinction between "control characters" and "data," such that "control characters" must include only bits representing control information and may not include data. Dkt. No. 419, at 14-16. The defendants note that the asserted claims recite two distinct elements, "control characters" and "data words," and that the claims treat information groups that contain control characters differently from those that do not. Id. at 14-15. Based on that observation, the defendants conclude that "control characters and data words can't be the same thing." Id. at 15. The Court agrees that the distinction between data information and control information is fundamental to the patent and its claimed encoding scheme. However, the defendants' construction of "control characters" limits that term in a way that is not supported by the specification. The '405 patent does not explicitly define the term "control character," except to say that the term is used "in place of the more conventionally used term control code." '405 patent, col. 3, ll. 39-40. As an example, the patent refers to the 1 Gigabit Ethernet standard in which there are 12 possible control codes. Id., col. 3, ll. 37-45; id., col. 6, ll. 61-62. The patent explains that the coding scheme it teaches is applicable to a variety of networking formats, including Gigabit Ethernet, Fibre Channel, and "other data formats that have been encoded using block line codes," id., col. 3, ll. 33-37; id., col. 4, ll. 53-57, such as "256B/257B, 128B/129B, 16B/17B, [and] 8B/9B," id., col. 2, ll. 66-67; see also id., col. 7, ll. 32-36. The patent is therefore not limited to a single encoding scheme or a single conception of control character, but states that it is applicable to a variety of "long-established Ethernet standard[s]." Id., col. 1, ll. 18-38. The meaning of "control character" in the '405 patent is therefore not limited to the definition of control characters contained in the 1 Gigabit Ethernet standard that the patent describes as a preferred embodiment, nor is it limited to a series of bits that consist exclusively of system control information. The '405 patent designates certain bits as "control characters" based on the designation assigned by the LAN line encoding scheme. That is to say, the patented scheme relies on the input signal protocol to define the distinction between data words and control characters. The encoding protocol simply reduces the number of bits in each control character so as to transport the communication more efficiently over an optical network. As Sycamore's expert explained, in the 8B/10B encoding specification "there are clear definitions as to what the control and what the data is" and "the definition of 8b/10b says these are the control and these are the data." Dkt. No. 419-8, at 105:6-107:7; see also id. at 105:18-20 ("[W]hat is control and what is data is something that you have to look at contextually."); id. at 106:1-2 ("This applies to other transcodings besides 8b/10b."). For purposes of the '405 patent, a control character can therefore contain whatever the incoming line encoding scheme provides in the portions of the signal that it designates as control characters, even if the control characters also include data information. Finally, although the claims use the terms "data words" and "control characters," which could suggest that each field is limited to a single word or character, the specification makes clear that each field could also be a block, consisting of multiple words or characters. See '405 patent, col. 5, ll. 50-55 ("For example, if 5-8 blocks or words are included in the information group, a sub-field 418zof 3-bits is preferably selected to represent the eight different positions where a control character may be found within the information group." (emphasis added) ). The term "control character" can therefore refer to a block of multiple characters or words and is not limited to a single character. For the foregoing reasons, the Court construes "control characters" as "bits in an information group designated as related to control by the input encoding scheme." II. Motions Relating to Infringement A. Infringement: Accused Mappings A and B 1. The ITU G.7041 Standard (Mapping A) Like the '405 patent, the G.7041 standard describes a method for encoding information. The G.7041 standard receives eight characters of 8B/10B information and maps them onto a 64B/65B block. Dkt. No. 185-2, at 30. In each 65-bit block, the "leading bit" or "flag bit" indicates whether "that block contains only 64B/65B 8-bit data characters or whether client control characters are also present in that block." Id. If the 65-bit block does not contain control characters, the flag bit is set as 0; otherwise it is set as 1. Id. If the 65-bit block contains control characters, the control characters are placed at the beginning of the block, and each control character is encoded into eight bits. The first of those eight bits is a Last Control Character flag bit, which indicates whether that control character is the last control character in the block. The next three bits constitute the Control Code Locator, which indicates the original location of the control code character within the sequence of the eight characters contained in the block. The last four bits in the 8-bit group constitute the Control Code Indicator, which represents the 8B/10B control code character and is coded in 4 bits. Id. Figure 8-2 illustrates how the input is encoded: Input client Flag bit 64-bit (8-Octet) field characters All data 0 D1 D2 D3 D4 D5 D6 D7 D8 7 data. 1 0 aaa D1 D2 D3 D4 D5 D6 D7 1 control C1 6 data. 1 1 aaa 0 bbb D1 D2 D3 D4 D5 D6 2 control C1 C2 5 data. 1 1 aaa 1 bbb 0 ccc D1 D2 D3 D4 D5 3 control C1 C2 C3 4 data. 1 1 aaa 1 bbb 1 ccc 0 ddd D1 D2 D3 D4 4 control C1 C2 C3 C4 3 data. 1 1 aaa 1 bbb 1 ccc 1 ddd 0 eee D1 D2 D3 5 control C1 C2 C3 C4 C5 2 data. 1 1 aaa 1 bbb 1 ccc 1 ddd 1 eee 0 fff D1 D2 6 control C1 C2 C3 C4 C5 C6 1 data. 1 1 aaa 1 bbb 1 ccc 1 ddd 1 eee 1 fff 0 ggg D1 7 control C1 C2 C3 C4 C5 C6 C7 8 control 1 1 aaa 1 bbb 1 ccc 1 ddd 1 eee 1 fff 1 ggg 0 hhh C1 C2 C3 C4 C5 C6 C7 C8 - Leading bit in a control octet (LCC) = 1 if there are more control octets and = 0 if this payload octet contains the last control octet in that block - aaa = 3-bit representation of the 1st control code's original position (1st Control Code Locator) - bbb = 3-bit representation of the 2nd control code's original position (2nd Control Code Locator) . . . - hhh = 3-bit representation of the 8th control code's original position (8th Control Code Locator) - Ci = 4-hit representation of the ith control code (Control Code Indicator) - Di = 8-bit representation of the ith data value in order of tlEllISIlliSS1011 The eight characters that compose the 64B/65B block are not transmitted over the network as a discrete block. Rather, eight 64B/65B code blocks are combined into a "superblock," which is described in Figure 8-3 of the standard. Dkt. No. 185-2, at 32. The entire superblock is 536 bits in size and consists of the following components: First, the payloads from each of the eight 64B/65B blocks are grouped into a superblock-i.e., 64 characters of eight bits each; next, the "leading (Flag) bits of each of the eight 64B/65B codes are grouped together into a first trailing octet"; finally, 16 additional bits are sent, which are used "for a CRC-16 error check over the bits of this superblock." Id. The superblock has the following structure, in which each row is eight bits: Octet 1, 1 Octet 1, 2 Octet 1, 3 - - - Octet 8, 7 Octet 8, 8 L1 L2 L3 L4 L5 L6 L7 L8 CRC-1 CRC-2 CRC-3 CRC-4 CRC-5 CRC-6 CRC-7 CRC-8 CRC-9 CRC-10 CRC-11 CRC-12 CRC-13 CRC-14 CRC-15 CRC-16 where: Octet j. k is the kth octet of the jth 64B/65B code in the superblock Lj is the leading (Flag) bit jth 64B/65B code in the superblock CRC-i is the ith error control bit where CRC-1 is the MSB of the CRC The G.7041 standard notes that "[t]o minimize latency, the transparent GFP mapper can begin transmitting data as soon as the first 64B/65B code in the group has been formed rather than waiting for the entire superblock to be formed." Id. 2. The 2009 Version of the ITU G.709 Standard (Mapping B) As noted, in 2009 the ITU-T issued a standard for mapping Gigabit Ethernet signals onto certain types of optical transport networks. This standard was designated as ITU G.709, but it stated that the mapping "is performed as specified in [ITU G.7041]," that is, Mapping A. Dkt. No. 185-5, at 84 (brackets in original). The infringement analysis is therefore identical for Mappings A and B. 3. Infringement of Claim Limitations 1(b) and 8(a) Sycamore's theory of infringement is that the defendants practice the two mapping standards at issue in this case, ITU G.7041 and ITU G.709, and that any party that practices those mapping standards will necessarily infringe the asserted claims of the '405 patent. The defendants respond that a party that practices the G.7041 mapping standard does not necessarily infringe claim limitations 1(b) and 8(a) of the '405 patent, and that proof that the defendants practice those mapping standards therefore does not constitute proof of infringement. Sycamore's infringement theory is based on the principles set out by the Federal Circuit in Fujitsu Ltd. v. Netgear Inc., 620 F.3d 1321 (Fed. Cir. 2010). There, the Circuit held that a district court "may rely on an industry standard in analyzing infringement." Id. at 1327. Specifically, the court held that "[i]f a district court construes the claims and finds that the reach of the claims includes any device that practices a standard, then this can be sufficient for a finding of infringement." Id. However, the court cautioned that "in many instances, an industry standard does not provide the level of specificity required to establish that practicing that standard would always result in infringement." Id. The court emphasized that in such cases the patent owner cannot establish infringement simply by "arguing that the product admittedly practices the standard, therefore it infringes." Id. at 1328. Rather, "the patent owner must compare the claims to the accused products or, if appropriate, prove that the accused products implement any relevant optional sections of the standard." Id. It is only in the situation in which a patent covers "every possible implementation of a standard" that it will be "enough to prove infringement by showing standard compliance." Id. Applying the test set forth in Fujitsu, this Court agrees with the defendants that the evidence does not show that practicing the G.7041 standard would necessarily infringe the '405 patent, and that the defendants are therefore entitled to summary judgment of non-infringement. The parties do not disagree that the "information group" referred to in the G.7041 mapping standard consists of the eight incoming characters of the 8B/10B signal-that is, 80 bits of information that comprise some combination of eight data words and/or control characters. The "encoded information group" in the G.7041 standard is therefore the 64B/65B encoding of those eight data words and/or control characters, consisting of a single flag bit and eight bits for each of the eight data words or control characters. See Dkt. No. 159-1, at A-1 (Sycamore's infringement contentions regarding the G.7041 standard, dated September 12, 2016, identify the "Input client characters" in Figure 8-2 as the multi-word information group for claim 1 and describe the information group as containing eight data words, eight control characters, or a mixture of eight data words and control characters); id. at A-20 (stating, for claim 3, "Each of the information groups comprises 8 words....Each of the words of the information group comprises 10 bits (i.e., an 8B/10B character)."); id. at A-22 (stating, for claim 4, "Each of the information groups comprises 80 bits (8 10-bit 8B/10B characters)."); see also Dkt. No. 185, at 10; Dkt. No. 245, at 3; Dkt. No. 418, at 9 ("In the G.7041 GFP-T standard, a 'block' is defined as a 64b/65b portion of the outgoing signal that corresponds to 80 bits of an incoming 8b/10b signal (or 64 bits of an incoming 8-bit signal). If those 80 (or 64) bits are the 'information group', then each 64b/65b block is a single 'encoded information stream.' " (citation omitted) ). The "data indicator" is the "flag bit" in the G.7041 standard. Dkt. No. 159-1, at A-6 through A-7. Under the Court's claim constructions, Sycamore has not presented evidence that the G.7041 mapping standard necessarily satisfies either claim limitation 1(b) or claim limitation 8(a) of the '405 patent. Claim limitation 1(b) requires that the data indicator and data words be combined to generate an encoded information stream that includes the data indicator and data words. Similarly, claim limitation 8(a) requires that the data words be encoded with a data indicator to generate an encoded information stream. The G.7041 standard does neither. Although the G.7041 standard generates a flag bit for each 64-bit information group, the data words and the corresponding flag bit are not combined, but are transmitted separately. The superblock structure transmits the data words and control characters first, followed by an octet of eight flag bits. Because the eight separate information groups-i.e., eight separate encoded information streams-are transmitted first, and the data indicators for all eight are combined and transmitted later, the data indicator is never put into a contiguous stream of encoded information with the data words. For that reason, the transmission of the superblocks under the G.7041 standard does not infringe the '405 patent. In its opposition to the defendants' motion for summary judgment of non-infringement, Sycamore made an alternative argument in favor of infringement. It argued that superblock encoding is a two-part process, and that "the data indicator and data words are first combined before the data indicator is separated into a trailing octet." Dkt. No. 245, at 7. As support for that proposition, Sycamore cited two White Papers on the G.7041 and G.709 standards prepared by Dr. Steve Gorshe, an engineer with PMC-Sierra and one of the principal architects of the standards. See Dkt. Nos. 245-12 and 245-13. Summarizing the mapping method for Gigabit Ethernet onto OPU0 in the 2011 White Paper, Dr. Gorshe described the implementation of the G.709 standard as follows: "Adapt the incoming GE signal into GFP-T: • Transcode the incoming GE 8B/10B characters into 64B/65B code blocks, • Group eight 64B/65B blocks into a 67 byte superblock, and • Map one superblock into a GFP frame, with no 65B_PAD or GFP Idles." Dkt. No. 245-13, at 41. Sycamore also cites the 2005 White Paper by Dr. Gorshe, Dkt. No. 245-12, which addressed the G.7041 standard. The cited portions of that White Paper describe the GFP-T mapping protocol and the way data and control characters are mapped into a 64B/65B code. It describes the process of mapping an incoming information stream to form a 64B/65B code, after which eight 64B/65B codes are combined into a superblock in which the "payload data bytes of the eight constituent 64B/65B codes are placed into the superblock in transmission order, with the eight leading (flag) bits of these codes grouped together in a trailing byte." Id. at 15. In their reply brief, the defendants did not respond to Sycamore's argument based on the White Papers. Because little attention had been devoted to the White Papers in the parties' briefs, the Court requested additional briefing on the relevance and admissibility of the White Papers. Dkt. No. 494. The defendants responded that the White Papers are inadmissible as hearsay and do not create a fact issue regarding infringement. Dkt. No. 512. Sycamore responded that the White Papers are admissible and that they raise a factual issue as to infringement. Dkt. No. 514. Sycamore also pointed to certain technical documents generated by manufacturers of the equipment that use the accused mappings. That evidence had not previously been submitted as part of the summary judgment record. For purposes of the summary judgment motions, the Court will assume the White Papers are both admissible. The question before the Court on Sycamore's alternative theory of infringement is whether Sycamore's evidence, consisting primarily of the G.7041 standard and the two White Papers, is sufficient to create a factual issue as to whether the standards require the formation of an infringing block of continuous bits before the data indicator is separated from the data to which it pertains. Sycamore argues that the G.7041 standard establishes that the decoded 8B/10B characters are mapped into a 64B/65B block, as shown in Figure 8-2 of the standard, before the 64B/65B blocks are grouped into a superblock, as shown in Figure 8-3 of the standard. Dkt. No. 185-2, at 30, 32. The block shown in Figure 8-2, Sycamore argues, is a physical, contiguous block of bits. That characterization, according to Sycamore, is consistent with the statement in the 2011 White Paper referring to "[t]ranscod[ing] the incoming GE 8B/10B characters into 64B/65B code blocks." Dkt. No. 509-2, at 41. The problem with Sycamore's theory is that neither the G.7041 standard nor the White Papers establishes that the 64B/65B block consists of physically contiguous bits, as opposed to bits that are logically related but not necessarily continuous within the communication signal. Both the standard and the White Papers refer to the 64B/65B blocks as "codes" or "code blocks," Dkt. No. 509-1, at 15-16; Dkt. No. 509-2, at 41, and the standard refers to the 64B/65B code being "formed," Dkt. No. 418-4, at 32, but none of those references states that the standard requires that a physical "block" of contiguous bits ever be generated in order to satisfy the '405 patent. For example, the 2005 White Paper articulates, in granular detail, the "process of going from the 64B/65B code to a GFP frame," which is illustrated in Figure 6 of that document. Dkt. No. 245-12, at 16. Figure 6 shows the construction of the GFP-T frame in four steps: first, it shows a 65-bit block of contiguous bits containing the leading bit and the 64 bits of payload information; second it shows a 520-bit block consisting of eight 65-bit blocks, in which each leading bit is physically contiguous with its respective 64 bits of payload information; third, the eight leading bits are repositioned into a trailing byte to form the superblock structure; and finally, four superblocks are fit into a GFP-T frame. Dkt. No. 245-12, at 17. If this four-step process of encoding were necessary for implementing the G.7041 standard, the first and second steps would satisfy the contested claim limitations. However, the standard itself suggests that this four-step process need not occur. The standard states that "[t]o minimize latency, the transparent GFP mapper can begin transmitting data as soon as the first 64B/65B code in the group has been formed rather than waiting for the entire superblock to be formed." Dkt. No. 185-2, at 32. Because information can begin to be transmitted immediately after the first block of information is received, the standard does not require the actual physical generation of the second step of the White Paper's four-step implementation. Given that the 2005 White Paper is intended to "provide an overview of GFP for a reader who is unfamiliar with this technology," Dkt. No. 245-12, at 5, the Court cannot infer that the White Paper describes the only possible implementation of the G.7041 mapping standard. It is therefore insufficient to satisfy Sycamore's burden. The defendants elicited expert testimony from several witnesses that the 64B/65B block referred to in the G.7041 standard does not have to consist of physically contiguous bits. See Dkt. No. 298-6, 91:22-92:10 (Sharma deposition: "Q. In order to create an output 64b/65b block, is it necessary that those 65 bits be physically contiguous? A. It's not necessary that they be physically contiguous, no."); Dkt. No. 185-10 ¶ 248 (Lanning Report: "Figure 8-2 is a logical representation....Figure 8-2 does not depict how products practicing the accused standard must be implemented. Dr. Nettles has presented no evidence that the Accused Instrumentalities perform the encoding as depicted in Figure 8-2. Indeed, it would make no sense and be less efficient to generate such a structure and then encode the 64B/65B blocks into the superblock structure shown in Figure 8-3."); Dkt. No. 185-11 ¶ 124 (Schofield Report: "Dr. Nettles provides no source code, documentation, or analysis as to whether the intermediary step shown in Figure 8-2 is ever generated by any of the accused line cards. Based on my experience, doing so is unnecessary and could lead to added latency. Instead of generating the blocks shown in Figure 8-2 and then transforming those blocks into the superblock structure of Figure 8-3, one of skill in the art would generate the information stream of each octet as shown in Figure 8-3 and then separate the data indicator by placing it in the appropriate slot in the first trailing octet. Thus, from an implementation stand point, one of skill in the art could place the data indicator directly into the first trailing octet without ever combining it with the data words in the encoded information stream as required by limitation 1(b)."). Sycamore offered no expert evidence to the contrary. In fact, Sycamore's expert, Dr. Nettles, gave testimony that was squarely at odds with Sycamore's alternative theory of infringement. He admitted that Figure 8-2 from the G.7041 standard does not "depict what is actually generated and sent over a communications link," but instead "is showing the logical relationships that go into the transform. The figure which is 8-3, which is the superblock, is closer to what is sent over the wire[.]" Dkt. No. 427-4, at 152:14-21. When asked, "Is 8-2 generated?" Dr. Nettles replied, "Something that has all of the pieces of 8-2 is generated because otherwise there would be no way to recreate them." Id. at 155:5-8. He added, "[t]he output stream is generated with the logical relationships we see in 8-2...you don't have to preserve the physical relationships we see in 8-2 in the serialized output."Id. at 159:4-23. He conceded that "I don't necessarily have visibility into what the implementation of the framer does and what order they do things in," id. at 160:3-6, but he clarified that "picture 8-2 tells us how to encode information groups. Figure 8-3 tells us more about how the serializer formats things," id. at 162:8-10. When asked, "So it doesn't matter for purposes of infringement whether what is actually physically generated takes the form of what is shown in Figure 8-2, it just needs to employ the logical relationships depicted in Figure 8-2; is that correct?" he answered, "It has to have the pieces." Id. at 166:15-21. Thus, Dr. Nettles conceded that, as the defendants' experts contended, the G.7041 standard does not require an implementation that generates the 65 bits of the 64B/65B block depicted in Figure 8-2 in a physically contiguous form. His testimony puts the kibosh on Sycamore's alternative infringement theory that the 64B/65B block of Figure 8-2 is generated before the creation of the superblock of Figure 8-3 and that each of the data-only blocks in the 64B/65B block is an encoded information stream of continuous bits that includes both the data indicator and data words. In response to the Court's request for the parties to brief the issue of the admissibility and relevance of the White Papers, and to provide any deposition testimony or expert reports in the case that discussed the White Papers, Sycamore submitted specification sheets from four chip manufacturers. Sycamore contends that the chips made by those manufacturers generate an intermediate block of physically contiguous bits corresponding to one of the blocks displayed in Figure 8-2 of the G.7041 standard. Those specification sheets, Dkt. Nos. 514-2 through 514-5, provide no significant support for Sycamore's infringement claims. To begin with, Sycamore's infringement contention was that the defendants practice the G.7041 standard and that practicing that standard would necessarily result in infringement of the '405 patent. See Fujitsu, 620 F.3d at 1327-28. Even assuming that the specification sheets describe an infringing 65-bit block of continuous bits, the specification sheets do not prove that the G.7041 standard must be implemented in a way that infringes Sycamore's patent, but only that it could be. Second, at least two of the specifications-those from Nortel Networks and Ciena Corporation-contain language that largely tracks the G.7041 standard. Nothing in those specifications provides support for Sycamore's alternative theory of infringement. The other two specifications-from Applied Micro Circuits Corp. and Cortina Systems, Inc.-are ambiguous; without supporting testimony explaining the language used in those specifications, it is not clear whether the reference to "blocks" and "codes" are meant to refer to physical structures or merely logical constructs. And finally, Sycamore represented that it was not relying on those specifications to prove infringement, but was merely using them as support for the proposition that the G.7041 standard is consistent with Sycamore's alternative theory of infringement. In sum, the Court concludes that the evidence presented on summary judgment fails to show a genuine issue of material fact as to infringement by Accused Mappings A or B. B. Infringement: Accused Mappings C and D 1. The Standards The 2012 revised version of the G.709 standard provided for mapping of faster LAN networks onto faster optical transport networks. Among other changes, the revised standard provided for mapping 10 Gigabit Fibre Channel signals onto ODU2e signals (Mapping C) and 40 Gigabit Ethernet signals onto ODU3 signals (Mapping D). The 2012 document was released as a new version of ITU-T Recommendation G.709/Y.1331. Except for one difference at the end of the encoding process, Mapping C and Mapping D are identical. Sycamore claims that both infringe the '405 patent. Mappings C and D are both methods to encode data and to send it more efficiently over a transport network. Rather than receive information in 8B/10B characters, as in the '405 patent and the G.7041 standard, Mappings C and D process input that is in the form of 64B/66B code blocks-i.e., 64 bits of content and two bits of overhead. Dkt. No. 185-4, at 164-65. According to the line encoding scheme, each 64B/66B block can be one of two types: a data block, which contains eight data bytes; or a control block, which can include a mixture of data and control information. Id. at 164. The 64B/66B control blocks are more complex than the control words in the 8B/10B scheme. In the 8B/10B scheme, there are only 12 possible control words. The 64B/66B line encoding scheme describes 15 different control block types, which can contain exclusively control information or a mixture of control and data information. Id. at 166, 168. Specifically, a 64B/66B control block contains a two-bit sync header, eight bits to indicate which of the 15 block types the control character is, and 56 bits of other information. Id. Figure B.2 of the 2012 mapping standards illustrates the data block format and the 15 control block formats: As in the G.7041 mapping standard, in which eight 8B/10B words are grouped and processed, Mappings C and D group and process eight 64B/66B blocks to encode a 512B/513B block. Id. at 165. The composition and structure of the 512B/513B block is determined based on the number of 64B/66B data blocks and control blocks to be included in the 512B/513B block. Id. at 168-69. If the 512B/513B structure contains at least one control block, a flag bit is set to "1"; if the structure contains only data blocks, the flag bit is set to "0." Id. Data blocks are transmitted without any further encoding. Figure B.5 shows the components of the 512B/513B structure, based on the number of 64B/66B data blocks and control blocks: Input client Flag 512-bit (64-Octet) field characters bit All data block 0 DB1 DB2 DB3 DB4 DB5 DB6 DB7 DB8 7 data block 0 AAA aaaa DB1 DB2 DB3 DB4 DB5 DB6 DB7 1 control block CB1 6 data block 1 AAA aaaa 0 BBB bbbb 2 control block 1 CB1 CB2 DB1 DB2 DB3 DB4 DB5 DB6 5 data block 1 AAA aaaa 1 BBB bbbb 0 CCC cccc 3 control block 1 CB1 CB2 CB3 DB1 DB2 DB3 DB4 DB5 4 data block 1 AAA aaaa 1 BBB bbbb 1 CCC cccc 0 DDD dddd DB1 DB2 DB3 DB4 4 control block 1 CB1 CB2 CB3 CB4 3 data block 1 AAA aaaa 1 BBB bbbb 1 CCC cccc 1 DDD dddd 0 EEE eeee DB1 DB2 DB3 5 control block 1 CB1 CB2 CB3 CB4 CB5 2 data block 1 AAA aaaa 1 BBB bbbb 1 CC:C cccc 1 DDD dddd 1 EEE eeee 0 FEE ffff DB1 DB2 6 control block 1 CB1 CB2 C133 CB4 CB5 CB6 1 data block 1 AAA aaaa 1 BBB bbbb 1 CCC cccc 1 DDD dddd 1 EEE eeee 1 FEE ffff 0 GGG gggg 7 control block 1 CB1 CB2 CB3 CB4 CB5 CB6 CB7 DB1 8 control block 1 AAA aaaa 1 BBB bbbb 1 CCC cccc 1 DDD dddd 1 EEE eeee 1 FFF ffff 1 GGG gggg 0 HHH hhhh 1 CB1 CB2 CB3 CB4 CB5 CB6 CB7 CB8 - Leading bit in a 66B control block FC = 1 if there are more than 66B control block and = 0 if this payload contains the last control block in that 513B block - AAA = 3 bit representation of the first control code's orginal position (First control code loca tor. POS) - BBB = 3-bit representation of the second control code's original position (Second control code lo cator. POS) - HRH = 3-bit representation of the eighth control codes original position (Eighth control code lo cator. POS) - aaa = 4-bit representation of the first control code's type (first control block type: CB TYPE) - bbb = 4-bit representation of the second control code's type (Second control block type: CB TYPE) - hhh = 4-bit representation of the eighth control code's type (Eighth control block type: CB TYPE) - CBi = 56-bit representation of the 1-th control code caracters - DBi = 64-bit representation of the i-the data value in order of transmission Control blocks, which include eight bits of block type information and 56 bits of control and/or data information, are encoded as follows: The eight-bit control block type is "translated into a 4-bit code according to the rightmost column of Figure B.2." Id. at 168. This four-bit code is shown in Figure B.5 as four lowercase letters ("aaaa," "bbbb," etc.). A three-bit "POS field" is generated to indicate the position of the original 64B/66B control block in the sequence of the eight 64B/66B blocks that are received in the coding process. Id. The POS field is shown in Figure B.5 as three capital letters ("AAA," "BBB," etc.). A flag continuation bit ("FC") indicates whether the particular control block is the final control block in the 512B/513B mapping group, or whether there are additional control blocks in the group. Id. Figure B.4 shows the structure of the eight-bit "control block header": The control block header is combined with the remaining 56 bits of the control block to create a 64-bit row in the 512B/513B structure. Id. Any control blocks are placed at the front of the 512B/513B structure, in the order in which they were received, followed by any data blocks, in the order received. Id. Figure B.3 depicts an example, containing five data blocks and three control blocks (the fifth, sixth, and seventh rows on the left side of the figure), of how eight incoming 64B/66B blocks are processed and rearranged into the 512B/513B structure: The two mapping standards diverge at the final step. In Mapping C, each 512B/513B structure is grouped with seven other 512B/513B structures to form a "516-octet superblock," and 17 such superblocks are grouped to form an 8800-octet GFP frame. Id. at 95. As in the G.7041 mapping standard, the physical structure of the superblock is significant for infringement analysis. Figure 17-18 of the 2012 version of the G.709 standard, set out below, illustrates the FC1200 GFP frame, with four bytes (32 bits) per row, and shows in detail the structure of a single superblock. The figure shows that a superblock has 512 bytes (4096 bits) of information and four trailing bytes (32 bits). Specifically, the eight one-bit flag bits are grouped together in a single octet at the end of the superblock (the "Superblock flags"), followed by 24 CRC error-check bits. Id. at 95-96. Mapping D combines the 512B/513B structures in a different way. Rather than being combined into a superblock, two 512B/513B structures are combined to form a 1027B block. Id. at 92. Mapping D adds an additional leading bit, the "flag parity bit" to protect the 512B/513B structure's flag bit and signal the location of the code blocks. Id. at 191. The two 512B/513B structures are transmitted in the following order: the parity bit; the flag bit from the first 512B/513B structure; the flag bit from the second 512B/513B structure; the payload (i.e., the eight data and/or control blocks) from the first 512B/513B structure; and finally, the payload from the second 512B/513B structure. Id. Figure F.1 from the 2012 standard illustrates this structure: 2. Infringement of Claim Limitations 1(b) and 8(a) As with the first two accused mappings, Sycamore's theory of infringement is that the defendants practice Mappings C and D, and that those mapping standards necessarily infringe the asserted claims of the '405 patent. The defendants again respond that Sycamore's evidence fails to show that implementing the mapping standards necessarily satisfies limitations 1(b) and 8(a) of the '405 patent, and that Sycamore has therefore failed to prove that practicing the mapping standards constitutes proof of infringement. The Court again agrees with the defendants. Sycamore contends that the "information group" in the 512B/513B mapping standards is the set of eight 64-bit blocks that are shown in Figure B.5. Dkt. No. 185, at 16; see also Dkt. No. 159-1, at C-1 (Sycamore's infringement contentions regarding Mapping C, dated September 12, 2016, which identify the "multi-word information group" as the eight 64-bit blocks shown in Figure B.5); id. at D-1 (same, regarding Mapping D). As in the case of the G.7041 mapping standard, the "data indicator" of the '405 patent corresponds to the standard's "Flag bit." Id. at C-8, D-8. As in the case of Mappings A and B, the defendants contend that the 512B/513B mapping standards do not infringe the '405 patent because the data words and the data indicator are not "combin[ed]" to "generate an encoded information stream." For that reason, the defendants argue, the 512B/513B mapping standards do not satisfy claim limitations 1(b) or 8(a), which require that the data words and the data indicator be "includ[ed]" in a single encoded information stream. In Mapping C, as in the G.7041 standard, the flag bits for each of the eight information groups in the superblock are placed in a trailing octet at the end of the superblock, separate from the corresponding data words. In Mapping D, the flag bits for the two information groups are grouped first and are transmitted immediately before the two information groups. Applying the Court's claim constructions, limitations 1(b) and 8(a) both require that the data indicator and the data words be combined or included in the same encoded information stream. The encoded data is transmitted in a superblock in the case of Mapping C, and in a pair of blocks in the case of Mapping D. As a result, multiple flag bits are combined and transmitted together, and they are transmitted separately from their corresponding data words. Therefore, it is clear that the final encoded output of each mapping does not infringe the '405 patent. In its opposition to the defendants' motion