Opinion
Civil Action LEAD CASE No. 16-10860-PBS No. 16-10868-PBS
04-02-2020
Intellectual Ventures I, LLC; Intellectual Ventures II, LLC, Plaintiffs, v. NETAPP, INC., Defendants.
MEMORANDUM AND ORDER
INTRODUCTION
Plaintiffs Intellectual Ventures I, LLC and Intellectual Ventures II, LLC ("IV") filed suit against NetApp, Inc., accusing NetApp's MetroCluster Fabric Attached systems of infringing U.S. Patent No. 6,516,442 (the '442 Patent). NetApp has moved for summary judgment on the ground that the MetroCluster products do not satisfy the "error correction" limitation in independent claims 1 and 24 of the '442 Patent, as that limitation was construed in this Court's March 13, 2019 Claim Construction Order, Intellectual Ventures I, LLC v. Lenovo Grp. Ltd., 365 F. Supp. 3d 200 (D. Mass. 2019). IV has cross- moved for partial summary judgment and both parties have moved to strike various portions of opposing experts' reports.
After hearing, the Court ALLOWS NetApp's Motion for Summary Judgment on Non-Infringement of the '442 Patent (Dkt. 369). In light of that ruling, the Court DENIES as moot IV's Motion for Partial Summary Judgment (Dkt. 376), IV's Motion to Strike (Dkt. 373), and NetApp's Motion to Strike (Dkt. 366).
FACTUAL BACKGROUND
The following facts are undisputed except where otherwise indicated.
A. '442 Patent
The '442 Patent is entitled "Channel interface and protocols for cache coherency in a scalable symmetric multiprocessor system." Dkt. 371-2 at 2. The patent relates to a type of computer architecture known as a "symmetric multi-processor system," in which multiple computer processors share a common operating system and memory. The '442 Patent claimed to improve upon prior art by incorporating "a switched fabric (switch matrix) for data transfers that provides multiple concurrent buses that enable greatly increased bandwidth between processors and shared memory." Id. In layman's terms, the '442 Patent sought to improve how data is transferred through the components of a symmetric multi-processor system in order to increase the system's processing capacity.
IV asserts four dependent claims of the '442 Patent against NetApp in this action — claims 2, 8, 25, and 31. Claims 2 and 8 are dependent on independent claim 1 and claims 25 and 31 are dependent on independent claim 24. As relevant here, both claim 1 and claim 24 require that certain components of the shared-memory multiprocessor system "perform error correction of the data in the packets exchanged over the channels." Dkt. 371-2 at 33; see id. at 34. The independent claims read in full:
1. A shared-memory multi-processor system comprising:
• a switch fabric configured to switch packets containing data;
• a plurality of channels configured to transfer the packets;
• a plurality of switch interfaces configured to exchange the packets with the switch fabric, exchange the packets over the channels, and perform error correction of the data in the packets exchanged over the channels;
• a plurality of microprocessor interfaces configured to exchange the data with a plurality of microprocessors, exchange the packets with the switch interfaces over the channels, and perform error correction of the data in the packets exchanged over the channels; and
• a memory interface configured to exchange the data with a memory device, exchange the packets with the switch interfaces over the channels, and perform error correction of the data in the packets exchanged over the channels.
24. A method of operating a shared-memory multiprocessor system, the method comprising:
• exchanging data between a plurality of microprocessors and a plurality of microprocessor interfaces;
• exchanging packets containing the data between the microprocessor interfaces and a plurality of switch interfaces over channels;
Id. at 33-34 (emphasis added).• exchanging the packets between the switch interfaces through a switch fabric;
• exchanging the packets between the switch interfaces and a memory interface over the channels;
• exchanging the data between the memory interface and a memory device; and
• in the interfaces, performing error correction of the data in the packets exchanged over the channels.
B. March 13, 2019 Claim Construction Order
This Court held a non-evidentiary Markman hearing and issued its Claim Construction Order on March 13, 2019. Intellectual Ventures I, LLC v. Lenovo Grp. Ltd., 365 F. Supp. 3d 200 (D. Mass. 2019) ("Intellectual Ventures"). The parties contested three terms in the '442 Patent — "packet," "error correction," and "error correction code." Id. at 206-10. The Court ruled that a "packet" is a "basic unit of transport over a channel," "error correction" means "correcting errors in data by at least reconstructing erroneous data," and "error correction code" means "a code that can be used to correct erroneous data." Id. at 211. The parties agreed that the term "channel" means "a general-purpose, high-speed, point-to-point, full-duplex, bi-directional interconnect bus." Id. at 205.
In regard to "error correction," IV had proposed that the term "not exclude the possibility of correcting errors using a retry request." Id. at 207. Defendants, including NetApp, argued that "performing error correction" instead means "correcting erroneous data in a packet via the reconstruction of errors - for example, changing an erroneous 1 back to a 0." Id. at 208.
The Court rejected IV's proposed construction. The Court found that the specification in the '442 Patent "distinguishes between 'error correction' and 'retry' protocols." Id. at 209. Furthermore, the Court reasoned that the doctrine of claim differentiation counseled against construing "error correction" to be met by retry alone because dependent claim 2 adds "retry request" to independent claim 1. Thus, the Court concluded, "the 'error correction' in claim 1 is different from correcting errors via a retry protocol." Id. Finally, the Court recognized that Defendants' proposed construction "does not exclude a retry protocol" because the construction would encompass "a system that is capable of a retry request as long as that system is also capable of reconstructing erroneous data." Id.
C. NetApp's MetroCluster Fabric Attached Systems
The NetApp products that IV accuses of infringing the '442 Patent are known as MetroCluster Fabric Attached systems (hereinafter, "MetroCluster" systems or products). "MetroCluster is a data storage system that provides redundant data storage at different locations." Dkt. 370 ¶ 3. The MetroCluster system allows a user to continuously back up data in a separate location as far as 300 kilometers away to prevent data loss in the event of a system failure at one location.
The MetroCluster system consists of corresponding sets of MetroCluster components at a local and remote location, labeled Site A and Site B in the illustration below.
Image materials not available for display. Dkt. 394-3 ¶ 9. Each site has at least one "controller," where data enters the system and which contains multiple microprocessors. Each site also has multiple memory storage devices known as "disk shelves." The controller and disk shelves at each site are connected by a series of Fibre Channel ("FC") switches, switch fabrics, and bridge components. Data that enters one controller is replicated in multiple locations, including the disk shelves in Sites A and B.
The MetroCluster system commits data to memory in four-kilobyte blocks of data. A single four-kilobyte block of data must travel through many components to go from controller to disk shelf. MetroCluster uses, among other protocols, PCI Express ("PCIe") connections, or busses, to transfer data between certain components in the system.
"Bus" is a generic term for a data connection between two or more devices.
When data is transferred from one component to another over a PCIe connection, the four-kilobyte block is first split into multiple PCIe packets in the sending component. Each PCIe packet is made up of over a thousand "bits," or binary digits (i.e. a single binary value of either 1 or 0). The PCIe packets travel across PCIe busses to the recipient component. PCIe busses are important to the overall system because they allow data to travel simultaneously across multiple "lanes," increasing the system's capacity.
IV refers to these PCIe packets as "sub-packets" of the four-kilobyte blocks of data, which it calls "end-to-end or channel" packets. See, e.g., Dkt. 394 at 10.
To ensure that data is transmitted correctly from one component to the other, the MetroCluster systems use a cyclic redundancy check ("CRC") code. After the four-kilobyte block of data is split into the PCIe packets — but before each PCIe packet is transmitted across the PCIe bus — a 32-bit CRC code is appended to each packet. In simplified terms, a CRC code works by treating a set of data as a single numerical sum and then performing a predetermined mathematical operation, such as dividing by a fixed number, to yield a predetermined value. The same mathematical operation is performed in the recipient component. If the result is not the predetermined value, the system knows there has been a transmission error in at least one bit of the data or CRC code.
If an error is detected, a negative acknowledgement ("NAK") is transmitted back to the first component. The PCIe packet containing an error is discarded and a new PCIe packet is retransmitted. Once all the PCIe packets have been transmitted without any errors, the PCIe packets are reassembled into the four-kilobyte block of data in the recipient component. This process is repeated over each PCIe connection in the MetroCluster system.
Both IV and its expert, Dr. Hugh Smith, contend that the "PCI express connections at the relevant interfaces" implement error correction as required by claims 1 and 24 of the '442 Patent, meaning the process described above meets the patent's "error correction" limitation. Dkt. 394 at 15; Dkt. 394-3 ¶ 15. IV does not contend that the MetroCluster systems employ any alternate method of addressing errors that would meet the "error correction" limitation.
MOTION FOR SUMMARY JUDGMENT
I. Summary Judgment Standard
Summary judgment is appropriate when there is "no genuine dispute as to any material fact and the movant is entitled to judgment as a matter of law." Fed. R. Civ. P. 56(a). A genuine dispute exists where the evidence "is such that a reasonable jury could resolve the point in the favor of the non-moving party." Rivera-Rivera v. Medina & Medina, Inc., 898 F.3d 77, 87 (1st Cir. 2018) (quoting Cherkaoui v. City of Quincy, 877 F.3d 14, 23-24 (1st Cir. 2017)). "The court must view the facts in the light most favorable to the non-moving party and draw all reasonable inferences in [its] favor." Carlson v. Univ. of New Eng., 899 F.3d 36, 43 (1st Cir. 2018).
II. Infringement Analysis
Analysis of an infringement allegation is a two-step process. First, "the trial court determines the scope and meaning of the asserted claims" in a claim construction order. Searfoss v. Pioneer Consol. Corp., 374 F.3d 1142, 1148 (Fed. Cir. 2004). Second, "the claims as construed by the court are compared limitation by limitation to the features of the allegedly infringing device." Id.
A patent holder bears the burden of proving that the allegedly infringing product satisfies each limitation of the asserted patent claim. Laitram Corp. v. Rexnord, Inc., 939 F.2d 1533, 1535 (Fed. Cir. 1991). Because IV has not alleged infringement under the doctrine of equivalents, it must show literal infringement, meaning "every limitation set forth in a claim must be found in an accused product, exactly." Advanced Steel Recovery, LLC v. X-Body Equip., Inc., 808 F.3d 1313, 1319 (Fed. Cir. 2015) (citation omitted).
Application of a construed claim to the accused product is a "factual determination." Dow Chem. Co. v. United States, 226 F.3d 1334, 1338 (Fed. Cir. 2000). Summary judgment of non-infringement is nonetheless appropriate where, "on the correct claim construction, no reasonable jury could have found infringement on the undisputed facts or when all reasonable factual inferences are drawn in favor of the patentee." Netword, LLC v. Centraal Corp., 242 F.3d 1347, 1353 (Fed. Cir. 2001).
III. Discussion
NetApp argues that its MetroCluster products do not satisfy the "error correction" limitation found in independent claims 1 and 24 and therefore all the asserted dependent claims. To refresh, the relevant limitation in independent claims 1 and - with minor alterations — 24 is that the infringing product must have certain components "configured to . . . perform error correction of the data in the packets exchanged over the channels." Dkt. 371-2 at 33-34 (emphasis added).
The Court ruled in its Claim Construction Order that a "packet" is "a basic unit of transport over a channel," and "error correction" means "correcting errors in data by at least reconstructing erroneous data." Intellectual Ventures, 365 F. Supp. 3d at 211. As agreed upon by the parties, a "channel" is "a general-purpose, high-speed, point-to-point, full-duplex, bi-directional interconnect bus." Id. at 205.
A. Parties' Arguments
Both parties agree that the CRC code is the only relevant method by which the MetroCluster products address errors. However, the parties disagree as to whether the CRC code, as used in the PCIe process, satisfies the "error correction" limitation in claims 1 and 24 of the '442 Patent. IV argues that "CRC codes are used to detect errors and correct erroneous data," Dkt. 396 ¶ 14 (emphasis added), while NetApp argues the CRC codes are solely "error detecting codes," Dkt. 370 ¶ 14. The parties also have different understandings of the "packets" and "channels" referenced in claims 1 and 24, which frame their positions on the "error correction" limitation.
IV argues that a MetroCluster system "reconstruct[s] erroneous data" when it uses the CRC code to detect erroneous PCIe sub-packets, requests retransmission, and then reassembles the now-corrected sub-packets back into a correct 4-kilobyte block of data. IV argues that the 4-kilobyte block of data is the "packet" referenced in claims 1 and 24 and that the relevant "channel" is the entire chain of transmission between the controller and the disk shelf. With these understandings of "packet" and "channel," IV argues that the "reconstruct[ion of] erroneous data" from the Court's Claim Construction Order occurs at the level of the 4-kilobyte block of data when it is "reconstructed" with corrected PCIe sub-packets. IV also argues that the disagreement between its own expert, Dr. Smith, and NetApp's expert, Dr. Horst, about whether the CRC code "performs error correction" creates a genuine dispute of material fact that must go to a jury.
NetApp argues that "reconstructing erroneous data" means flipping erroneous bits from 1 to 0 or vice versa, which the CRC code undisputedly does not do. See, e.g., Dkt. 371 at 17. NetApp argues that the relevant "packets" are the PCIe packets and the relevant "channels" are the PCIe links between system components. With these understandings of "packet" and "channel," NetApp argues that the "reconstruct[ion of] erroneous data" would need to occur at the level of the PCIe packets. Instead, NetApp continues, the only method of error correction at that level is a retry request triggered by the CRC code, which unambiguously does not satisfy the "error correction" limitation, as construed in the Court's Claim Construction Order.
B. Analysis
Although the parties' understandings of the terms "packet" and "channel" help to clarify their arguments regarding the "error correction" limitation, the Court need not decide here which components of the MetroCluster products, if any, correspond with the "packets" and "channels" described in claims 1 and 24. The MetroCluster systems' method of addressing errors falls squarely outside the construction of "error correction" adopted in this Court's Claim Construction Order, so NetApp is entitled to summary judgment on the basis of non-infringement.
IV contends that NetApp incorrectly equates "reconstructing erroneous data" with "flipping bits" from 1 to 0 or vice versa. According to IV, flipping bits is a "specific error correction technique called Forward Error Correction (FEC)." Dkt. 394 at 7. However, IV continues, "FEC is by no means the only technique for correcting errors in data by at least reconstructing erroneous data." Id. IV claims that the Court never construed "error correction" to require unflipping bits and that to do so would "exclude the preferred embodiments of the patent." Id.
Regardless, the Court's order unambiguously excluded a definition of "error correction" that could be met exclusively by a retry procedure. IV had argued in the Markman hearing that "error correction" could be met by retry alone. The Court disagreed, noting, "In the '442 Patent, the specification distinguishes between 'error correction' and 'retry' protocols." Intellectual Ventures, 365 F. Supp. 3d at 209. The Court further noted that for dependent claim 2 (which references "retry") to be narrower in scope than independent claim 1 (which does not), "retry" must be an additional limitation not found in independent claim 1's "error correction" limitation. Id. The Court succinctly concluded, "Thus, the 'error correction' in claim 1 is different from correcting errors via a retry protocol." Id.
IV asserts it is not arguing retry or retransmission alone meets the "error correction" limitation. Instead, as Dr. Smith explains, the MetroCluster systems "utilize retransmission of portions of the channel packets containing errors and perform reconstruction of erroneous data." Dkt. 394 at 13. According to IV, "reconstruction of erroneous data" is performed in the reassembly process of PCIe packets into 4-kilobyte blocks, rather than only the retry process at the level of the PCIe packets.
This strains the Court's Claim Construction Order too far. The reassembly process is not part of the MetroCluster systems' method of handling errors. Only the CRC code addresses errors. The CRC code's only function is to trigger a retry request, at the exclusion of any other method of addressing errors. At best, the MetroCluster systems "reconstruct" corrected data into the 4-kilobyte block. The products never "reconstruct[] erroneous data" for the purpose of error correction, as required by this Court's Claim Construction Order.
IV also argues that NetApp seeks to impermissibly "exclude the preferred embodiments of the patent." Dkt. 394 at 7. That argument was discussed and rejected by the Court in its Claim Construction Order. IV had argued in its Markman briefing that "reading 'error correction' to exclude the possibility of a retry request would unnecessarily limit the term and read out a preferred method of error correction." Intellectual Ventures, 365 F. Supp. 3d at 209. The Court rejected this argument, stating that Defendants' proposed construction "would not foreclose a system that is capable of a retry request as long as that system is also capable of reconstructing erroneous data." Id. Because the CRC code is capable only of retry and not any other method of addressing errors, the MetroCluster products do not meet the "error correction" limitation in claims 1 and 24.
Finally, IV argues that the application of a court's claim construction to an accused device is generally a question of fact. See Uniloc USA, Inc. v. Microsoft Corp., 632 F.3d 1292, 1301 (Fed. Cir. 2011). As a result, "[a]s a general rule, summary judgment is inappropriate where an expert's testimony supports the non-moving party's case." Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 683 (Fed. Cir. 2015). IV argues that because Dr. Smith has opined that the MetroCluster systems satisfy the "error correction" limitation, IV survives summary judgment on non-infringement.
However, the construction of patent claims is a question of law for the Court to decide. Markman v. Westview Instruments, Inc., 517 U.S. 370, 372 (1996). Therefore, "an expert's analysis that contradicts the language or reasoning behind a court's claim construction order" cannot be used to "create an issue of fact that precludes summary judgment." ICU Med., Inc. v. Alaris Med. Sys., Inc., No. SA CV 04-00689 MRP (VBKx), 2007 WL 8081360, at *12 (C.D. Cal. Jan. 22, 2007).
Here, Dr. Smith's testimony supports IV's case only in that his ultimate conclusion is a finding of infringement. See Dkt. 394-3 ¶ 15 ("[T]hese PCI express connections at the relevant interfaces implement error correction consistent with the Court's claim construction because they at least correct errors in data by at least reconstructing erroneous data.") But Dr. Smith's analysis of the relevant technology describes a process that plainly falls outside the Court's Claim Construction Order because it fails to account for the Court's clear holding that "reconstructing erroneous data" cannot be achieved through retry alone. See Intellectual Ventures, 365 F. Supp. 3d at 209.
Dr. Smith writes that the PCIe process ensures data integrity "because any errors induced during the transfer of packets between the interfaces is corrected using the PCIE's error correction code." Dkt. 394-3 ¶ 17. It is undisputed that the PCIe packets are "corrected" through retry alone. Dr. Smith's analysis thus erroneously equates "correction" with "retry" in direct contravention of this Court's Claim Construction Order. See Intellectual Ventures, 365 F. Supp. 3d at 209. Dr. Smith also writes that "error correction" occurs when the "overall [4-kilobyte] packet [is] reconstructed with the corrected, not the erroneous data." Dkt. 394-3 ¶ 17. But the Court's Claim Construction Order plainly requires an error correction method that "reconstruct[s] erroneous data," not one that reassembles corrected data. See Intellectual Ventures, 365 F. Supp. 3d at 211.
Dr. Smith's description of "error correction" in the MetroCluster products contradicts the Court's construction of that limitation. IV cannot relitigate claim construction at the summary judgment stage and then cry dueling experts. See Clare v. Chrysler Grp. LLC, 819 F.3d 1323, 1332-34 (Fed. Cir. 2016) (affirming summary judgment of non-infringement where the testimony of plaintiff's expert was "based on an incorrect understanding of the district court's claim construction").
ORDER
The Court ALLOWS NetApp's Motion for Summary Judgment on Non-Infringement of the '442 Patent (Dkt. 369). The Court DENIES as moot IV's Motion for Partial Summary Judgment (Dkt. 376), IV's Motion to Strike (Dkt. 373), and NetApp's Motion to Strike (Dkt. 366). SO ORDERED.
/s/ PATTI B. SARIS
Hon. Patti B. Saris
United States District Judge