Opinion
No. 6:10cv493 LED-JDL
10-01-2012
REALTIME DATA, LLC, d/b/a IXO, Plaintiff, v. METROPCS TEXAS, LLC, et al., Defendants.
JURY DEMANDED
MEMORANDUM OPINION AND ORDER
This claim construction opinion construes the disputed claim terms in U.S. Patent Nos. 7,161,506 ("the '506 patent"); 7,321,937 ("the '937 patent"); 7,352,300 ("the '300 patent"); 7,395,345 ("the '345 patent"); and 7,415,530 ("the '530 patent"). Plaintiff Realtime Data, LLC ("Realtime") alleges Defendants infringe the above-named patents. The parties have presented their claim construction positions (Doc. Nos. 240, 253 & 272). On April 12, 2012, the Court held a claim construction hearing. For the reasons stated herein, the Court adopts the constructions set forth below.
In addition, Plaintiff originally asserted U.S. Patent Nos. 6,604,158; 6,601,104 ; and 7,378,992. These patents are no longer asserted against Defendants. See RESPONSE AT 2, n.1 and REPLY AT 1, n.1.
The Court previously construed many of the patents-in-suit in Realtime Data, LLC v. Packeteer, Inc., No. 6:08cv144, (E.D. Tex.) issuing a Markman Order on June 22, 2009.
OVERVIEW OF THE PATENTS
The patents may be categorized into two groups: the data acceleration patents and the data compression patents. The data acceleration patents include the '937 patent, '345 patent and '530 patent. These patents are directed to "[s]ystems and methods for providing accelerated data storage and retrieval utilizing lossless data compression and decompression." '937 patent, ABSTRACT; see also '345 patent, ABSTRACT; '530 patent, ABSTRACT. The specification is common to all of these patents.
As for the data compression patents—the '506 and '300 patents—these patents discuss "[s]ystems and methods for providing fast and efficient data compression using a combination of content independent data compression and content dependent data compression." '506 patent, ABSTRACT; '300 patent, ABSTRACT.
Claim 1 of the '937 patent is set forth below as a representative claim of the data acceleration patents, with disputed claim terms set forth in bold:
1. A method comprising:'937 patent at 18:52-61. Claim 86 of the '506 patent is representative of the claims at issue in the data compression patents:
receiving a data stream at an input data transmission rate which is greater than a data storage rate of a target storage device;
compressing the data stream, with a plurality of encoders provided in a parallel configuration, at a compression rate that increases the effective data storage rate of the data storage device; and
storing the compressed data stream in the target storage device.
86. A method comprising:'506 patent at 32:51-61.
receiving a data block, wherein said data block is included in a data stream;
determining whether to output said data block in received form or in a compressed form; and
outputting said data block in received form or said compressed form based on said determination, wherein outputting said data block in said compressed form comprises determining whether to compress said data block with content dependent data compression based on the type of said data block or to compress said data block with a single data compression encoder.
Although it seems Realtime does not assert Claim 86 of the '506 patent against Defendants, it does assert Claims 93, 94, and 99, all of which are dependent on Claim 86. See REALTIME'S MOTION TO ENFORCE COURT'S ORDER AT 2 (Doc. No. 306).
CLAIM CONSTRUCTION PRINCIPLES
"It is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude." Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). The Court examines a patent's intrinsic evidence to define the patented invention's scope. Id. at 1313-1314; Bell Atl. Network Servs., Inc. v. Covad Commc'ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). Intrinsic evidence includes the claims, the rest of the specification and the prosecution history. Phillips, 415 F.3d at 1312-13; Bell Atl. Network Servs., 262 F.3d at 1267. The Court gives claim terms their ordinary and customary meaning as understood by one of ordinary skill in the art at the time of the invention. Phillips, 415 F.3d at 1312-13; Alloc, Inc. v. Int'l Trade Comm'n, 342 F.3d 1361, 1368 (Fed. Cir. 2003).
Claim language guides the Court's construction of claim terms. Phillips, 415 F.3d at 1314. "[T]he context in which a term is used in the asserted claim can be highly instructive." Id. Other claims, asserted and unasserted, can provide additional instruction because "terms are normally used consistently throughout the patent." Id. Differences among claims, such as additional limitations in dependent claims, can provide further guidance. Id.
"[C]laims 'must be read in view of the specification, of which they are a part.'" Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995)). "[T]he specification 'is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.'" Id. (quoting Vitronics Corp.v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); Teleflex. Inc. v.Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). In the specification, a patentee may define his own terms, give a claim term a different meaning that it would otherwise possess, or disclaim or disavow some claim scope. Phillips, 415 F.3d at 1316. Although the Court generally presumes terms possess their ordinary meaning, this presumption can be overcome by statements of clear disclaimer. See SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1343-44 (Fed. Cir. 2001). This presumption does not arise when the patentee acts as his own lexicographer. See Irdeto Access, Inc. v. EchoStar Satellite Corp., 383 F.3d 1295, 1301 (Fed. Cir. 2004).
The specification may also resolve ambiguous claim terms "where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone." Teleflex, Inc., 299 F.3d at 1325. For example, "[a] claim interpretation that excludes a preferred embodiment from the scope of the claim 'is rarely, if ever, correct." Globetrotter Software, Inc. v. Elam Computer Group Inc., 362 F.3d 1367, 1381 (Fed. Cir. 2004) (quoting Vitronics Corp., 90 F.3d at 1583). But, "[a]lthough the specification may aid the court in interpreting the meaning of disputed language in the claims, particular embodiments and examples appearing in the specification will not generally be read into the claims." Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988); see also Phillips, 415 F.3d at 1323.
The prosecution history is another tool to supply the proper context for claim construction because a patentee may define a term during prosecution of the patent. Home Diagnostics Inc. v. LifeScan, Inc., 381 F.3d 1352, 1356 (Fed. Cir. 2004) ("As in the case of the specification, a patent applicant may define a term in prosecuting a patent"). The well established doctrine of prosecution disclaimer "preclud[es] patentees from recapturing through claim interpretation specific meanings disclaimed during prosecution." Omega Eng'g Inc. v. Raytek Corp., 334 F.3d 1314, 1323 (Fed. Cir. 2003). The prosecution history must show that the patentee clearly and unambiguously disclaimed or disavowed the proposed interpretation during prosecution to obtain claim allowance. Middleton Inc. v. 3M Co., 311 F.3d 1384, 1388 (Fed. Cir. 2002); see also Springs Window, 323 F.3d at 994 ("The disclaimer . . . must be effected with 'reasonable clarity and deliberateness.'") (citations omitted)). "Indeed, by distinguishing the claimed invention over the prior art, an applicant is indicating what the claims do not cover." Spectrum Int'l v. Sterilite Corp., 164 F.3d 1372, 1378-79 (Fed. Cir. 1988) (quotation omitted). "As a basic principle of claim interpretation, prosecution disclaimer promotes the public notice function of the intrinsic evidence and protects the public's reliance on definitive statements made during prosecution." Omega Eng'g, Inc., 334 F.3d at 1324.
Although, "less significant than the intrinsic record in determining the legally operative meaning of claim language," the Court may rely on extrinsic evidence to "shed useful light on the relevant art." Phillips, 415 F.3d at 1317 (quotation omitted). Technical dictionaries and treatises may help the Court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but such sources may also provide overly broad definitions or may not be indicative of how terms are used in the patent. Id. at 1318. Similarly, expert testimony may aid the Court in determining the particular meaning of a term in the pertinent field, but "conclusory, unsupported assertions by experts as to the definition of a claim term are not useful." Id. Generally, extrinsic evidence is "less reliable than the patent and its prosecution history in determining how to read claim terms." Id.
DISCUSSION
I. "target storage device" / "data storage device" / "memory device"
This term is contained in Claim 1 of the '345 patent and Claims 1 and 11 of the '937 patent.
This term is contained in Claims 1 and 11 of the '937 patent.
This term is contained in Claim 1 of the '530 patent.
+-----------------------------------------------------------------------------+ ¦Plaintiff's Proposed Construction ¦Defendants' Proposed Construction ¦ +--------------------------------------+--------------------------------------¦ ¦An identified memory device to which ¦An identified memory device to which ¦ ¦data is ¦data is ¦ ¦ ¦ ¦ ¦directed for storage. ¦directed for retention and later ¦ ¦ ¦retrieval. ¦ +-----------------------------------------------------------------------------+
At the hearing, the parties had no objections to the Court's proposed construction. MARKMAN TRANSCRIPT (Doc. No. 290) at 5:7-22. Therefore, a "target storage device," "data storage device," or "memory device" is "an identified memory device to which data is directed for recording and later retrieval."
II. "a data compression type descriptor" / "first data descriptor . . . indicative of said first compression technique"
This term is contained in Claim 1 of the '345 patent.
This term is contained in Claim 1 of the '530 patent.
+-----------------------------------------------------------------------------+ ¦Plaintiff's Proposed Construction ¦Defendants' Proposed Construction ¦ +--------------------------------------+--------------------------------------¦ ¦ ¦Any recognizable data token or ¦ ¦ ¦descriptor ¦ ¦ ¦ ¦ ¦ ¦provided with [a first] output data ¦ ¦Any recognizable data token or ¦block that ¦ ¦descriptor that ¦ ¦ ¦ ¦can indicate that no data encoding has¦ ¦indicates which data encoding ¦been ¦ ¦technique has ¦ ¦ ¦ ¦applied to the data block, or, if ¦ ¦been applied to the data. ¦encoding has ¦ ¦ ¦ ¦ ¦ ¦been applied, which data encoding ¦ ¦ ¦technique ¦ ¦ ¦ ¦ ¦ ¦has been applied. ¦ +-----------------------------------------------------------------------------+
The central dispute among the parties is whether a "null data compression type descriptor" is a subcategory of "a data compression type descriptor" or a completely separate type of descriptor. See PLTFF'S BRIEF AT 16; RESPONSE AT 11-12. Realtime contends that the null data compression type descriptor is a different type of descriptor and therefore Defendants' proposed construction is incorrect because it attempts to import the definition of the null data compression type descriptor into the definition of "a data compression type descriptor." PLTFF'S BRIEF AT 16. Realtime further argues that its proposal reflects the explicit definition for "a data compression type descriptor" provided by the specification. Id. at 15 (citing '345 patent at 13:63-66).
Defendants, on the other hand, maintain that a null descriptor is a type of data compression type descriptor. RESPONSE AT 12. As such, the construction of "data compression type descriptor" should reflect that (1) "no data encoding has been applied to the data block, or, (2) if encoding has been applied, which data encoding technique has been applied," as is required by the claims. Id. (citing Claim 1 of the '345 patent). Defendants contend that Realtime's proffered construction only indicates what compression type was applied and does not account for the possibility that data may not be compressed at all. Id. at 13.
The parties point to portions of the specification wherein the definitions of "a data compression type descriptor" and "null data compression type descriptor" are supposedly defined:
• "A data compression type descriptor is defined as any recognizable data token or descriptor that indicates which data encoding technique has been applied to the data." '345 patent at 13:58-66; '530 patent at 12:33-41.However, these definitions, particularly that of the "null data compression type descriptor," do not conform with the claim language. See Phillips, 415 F.3d at 1314 ("[T]he context in which a term is used in the asserted claim can be highly instructive."). Rather, Claim 1 of the '345 patent does not differentiate between a null type descriptor and a data compression type descriptor, but indicates that a null type descriptor is a subcategory of a data compression type descriptor:
• "A null data compression type descriptor is defined as any recognizable data token or descriptor that indicates no data encoding has been applied to the input data block." '345 patent at 14:7-14; '530 patent at 12:49-56.
1. A method comprising:
. . .'345 patent at 19:55-20:2.
providing an output data block and a data compression type descriptor wherein:
if said data compression type descriptor is indicative of said data not being compressed then said data was not compressed and said output data block is said data;
if said data compression type descriptor is indicative of said data being compressed then said data was compressed based on said compression type descriptor at a compression rate that increased the effective data storage rate of the target storage device to provide a compressed data block, wherein said output data block is said compressed data block.
Further, the claim language states that the data compression type descriptor indicates both when data is compressed and when it is not. Thus, both Realtime and Defendants' proposals are incorrect; Realtime's proposal does not account for the scenario where data is not compressed at all and Defendants' proposal simply restates the claim language. Because the claim language controls, the Court finds that neither of the proposed constructions is accurate. See Phillips, 415 F.3d at 1312 ("The claims of a patent define the invention to which the patentee is entitled the right to exclude") (quoting Innova/Pure Water, Inc., 381 F.3d at 1115). The parties do, however, seem to agree that "a data compression type descriptor" is "any recognizable data token or descriptor." Such an interpretation describes what "a data compression type descriptor" is without reiterating the claim language or failing to account for each alternative set forth in the claim.
While Claim 1 of the '530 patent does not iterate "a data compression type descriptor," it does recite a "first data descriptor . . . indicative of said first compression technique." '530 patent at 18:38-40. Again, the claim language already iterates that the "first descriptor" indicates the type of compression technique used. Therefore, any construction of a "first descriptor" does not require a functional definition as the parties' proposals seem to suggest.
In light of the parties' apparent agreement to a portion of the construction, the Court construes the terms "a data compression type descriptor" and "first data descriptor . . . indicative of said first compression technique" as "any recognizable data token or descriptor."
III. "compressing with a plurality of encoders in a parallel configuration" / "parallel configuration [of a plurality of encoders]"
This term is contained in Claims 16 and 17 of the '530 patent and Claims 1, 5, 11 and 14 of the '937 patent.
This term is contained in Claims 16 and 17 of the '530 patent and Claims 1, 5, 6, 11, 14 and 15 of the '937 patent.
+----------------------------------------------------------------------------------------+ ¦Disputed Terms ¦Plaintiff's Proposed Construction ¦Defendants' Proposed Construction ¦ +----------------+-----------------------------------+-----------------------------------¦ ¦"compressing ¦Using more than one encoder, ¦ ¦ ¦with a plurality¦ ¦Using more than one encoder ¦ ¦ ¦in parallel configuration, to ¦ ¦ ¦of encoders in a¦ ¦to concurrently compress the ¦ ¦parallel ¦concurrently compress data ¦ ¦ ¦ ¦ ¦same data stream. ¦ ¦configuration" ¦from the same data stream. ¦ ¦ +----------------+-----------------------------------+-----------------------------------¦ ¦"parallel ¦A configuration [of a plurality ¦A configuration [of a plurality ¦ ¦configuration ¦ ¦ ¦ ¦[of a ¦of encoders] which compress ¦of encoders] which ¦ ¦ ¦ ¦ ¦ ¦plurality of ¦data from the same data ¦concurrently compress the ¦ ¦encoders]" ¦ ¦ ¦ ¦ ¦stream. ¦same data stream. ¦ +----------------------------------------------------------------------------------------+
At the hearing, Realtime agreed to Defendants' proposed construction. MARKMAN TRANSCRIPT AT 24:14-24. Therefore, "compressing with a plurality of encoders in a parallel configuration" is defined as "using more than one encoder to concurrently compress the same data stream." Further, "parallel configurations [of a plurality of encoders]" is defined as "a configuration [of a plurality of encoders] which concurrently compress the same data stream."
IV. "receiving a data stream" / "receiving a data block"
This term is contained in Claims 1 and 11 of the '937 patent.
This term is contained in Claim 86 of the '506 patent.
+----------------------------------------------------------------------------------------+ ¦Disputed Terms ¦Plaintiff's Proposed Construction ¦Defendants' Proposed Construction ¦ +----------------+-----------------------------------+-----------------------------------¦ ¦ ¦ ¦Passive receipt of one or more ¦ ¦ ¦ ¦ ¦ ¦ ¦Receiving one or more data blocks ¦data blocks transmitted in ¦ ¦"receiving a ¦transmitted in ¦ ¦ ¦data stream" ¦ ¦sequence. ¦ ¦ ¦sequence. ¦ ¦ ¦ ¦ ¦[SPRINT, AT&T, CRICKET, ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦& METROPCS] ¦ +----------------+-----------------------------------¦ ¦ ¦ ¦ ¦Passively receiving in ¦ ¦ ¦ ¦ ¦ ¦ ¦This term needs no ¦software one or more data ¦ ¦"receiving a ¦ ¦ ¦ ¦data block" ¦construction. ¦blocks transmitted in sequence ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦[T-MOBILE & VERIZONWIRELESS]. ¦ ¦ ¦ ¦ ¦ +----------------------------------------------------------------------------------------+
The parties take issue with what it means to receive data, in particular (1) whether the receipt is passive and (2) whether such receipt must occur in software. RESPONSE AT 6, 24-25. Defendants contend that Realtime consistently disclaimed any active receipt during reexamination of the patents, thereby forfeiting such claim scope. Id. at 6-8. In addition, the T-Mobile and Verizon Wireless Defendants argue that to overcome prior art during reexam, Realtime repeatedly emphasized that certain elements, including the "receiving" element, were performed in software. Id. at 24-25. Thus, Realtime effectively narrowed the scope of the claim to require receipt of data in software. Id.
Realtime, however, contends that any purportedly disclaiming statements with regard to "passive receipt" made during reexam were withdrawn. PLTFF'S BRIEF AT 23. And such comments simply distinguished the prior art, noting that "retrieving data from an internal system memory using standard memory access techniques (as done in the prior art) was fundamentally different from 'receiving a data stream.'" REPLY AT 11. Realtime does, however, acknowledge that comments made during reexamination distinguish receiving data from internal memory (prior art) and receiving data from an external source. See e.g., MARKMAN TRANSCRIPT AT 52:7-11 (stating Figure 2 of the '506 patent shows the compression system receiving a data system from an external source). Addressing T-Mobile and Verizon Wireless' software arguments, Realtime notes that the specifications explicitly note that the technologies covered by the patents may be implemented in forms other than software and therefore a software limitation is inconsistent with the intrinsic record. PLTFF'S BRIEF AT 22-23.
Realtime further argues that the Court should adopt its previous construction for "receiving a data stream." Id. at 21. In Packeteer, the Court construed "receiving a data stream" as "receiving one or more data blocks transmitted in sequence." PACKETEER MARKMAN at 41, 6:08cv144, (Doc. No. 371). However, the same construction does not apply to "receiving a data block" given that this particular term does not imply any sequential requirement. Thus, Realtime contends, "receiving a data block" should be given its plain and ordinary meaning. PLTFF'S BRIEF AT 21.
A. Passive Receipt
"The doctrine of prosecution disclaimer is well established in Supreme Court precedent, precluding patentees from recapturing through claim interpretation specific meanings disclaimed during prosecution." Omega Eng'g, 334 F.3d at 1323 (internal citations omitted). However, prosecution disclaimer may not apply after looking at the prosecution history as a whole, which may indicate that the purported disclaimer was merely an isolated statement, lending ambiguity to whether the patent applicant clearly disavowed the particular subject matter. Ecolab, Inc. v. FMC Corp., 569 F.3d 1335, 1342 (Fed. Cir. 2009) (citing Elbex Video, Ltd. v. Sensormatic Elec. Corp., 508 F.3d 1366, 1372-73 (Fed. Cir. 2007)). Statements made during reexamination may be considered under the doctrine of prosecution disclaimer. Grober v. Mako Prods., Inc., ---F.3d ----, Nos. 2010-1519, 2010-1527, 2012 WL 3065278, at *3 (Fed. Cir. July 30, 2012). However, the standard remains the same; in order to find disclaimer, any disavowal must be unambiguous. Id.
Realtime does not deny that it described "receiving a data stream" as "an inherently passive process." See REPLY AT 12. However, the context in which such comments were made is in dispute. Particularly, Realtime maintains that "passive receipt" describes a process whereby the system receives data—specifically, a data stream—without retrieving it from internal memory. Id. at 11-12. The Court agrees.
In distinguishing the '506 patent from U.S. Patent No. 5,794,229 ("French"), the patent owner stated that the prior art (1) does not receive a data stream and (2) actively retrieves data from memory:
[T]he data that French streams to disk is not a "data stream" because it involves data output from French's Buffer Manager rather than the data received from a source whose characteristics are not controlled by the compression system. Further, French discloses that "[d]ata compression is added to the system at the level of the Cache or Buffer Managers." (French at 16:8-10.) The "data pages of an object are compressed when sent out to the disk." (French at 16:13-14.) The uncompressed data pages clearly reside in the system memory of French's apparatus, as do the buffers managed by French's Buffer Manager. (French at 17:62-63.) One skilled in the art would know that this type of standard memory retrieval does not constitute "receiving . . . a data stream," as claimed in the patent-in-reexamination. (Modestino Decl. ¶ 16.).REMARKS AT 9, REEXAMINATION OF PATENT NO. 7,161,506, REEXAM CONTROL NO. 95/000,479 (MARCH 15, 2010) (emphasis added), EX. 14, ATTACHED TO REPLY. The cited portion of the reexamination history shows that Realtime differentiates the '506 patent from the prior art by contrasting the act of retrieving data from internal memory (French) with simply receiving data. Note that Realtime further distinguishes French from the '506 patent when implying that the technology of the '506 patent does not control what type or quantity of data is transmitted; the data in the '506 patent is "received from a source whose characteristics are not controlled by the compression system." As Realtime pointed out in the hearing, Realtime's comments are directed to "distinguishing [the '506 patent] over an internal memory fetch," as opposed to receiving data from an external source. See MARKMAN TRANSCRIPT AT 52:18-53:7.
For this term, and others, the parties seem to make arguments referencing one or more of the data compression patents and extrapolate them to apply to terms found in the data acceleration patents, and vice versa. Because none of the parties seem to object to this line of argument, the Court will apply the arguments and prosecution history referencing one family of patents to assess the same terms found in the other patent family.
Realtime's expert, who contributed a declaration that was heavily cited during reexam, made similar remarks regarding the '506 patent and U.S. Patent No. 5,870,036 ("Franaszek"):
As indicated previously in paragraphs 9-11, in the context of the '506 patent, on of ordinary skill in the art would consider a data stream as a continuous stream of data elements to be received or transmitted. Similarly, an input or received data stream would be considered a data stream received at an input port. However, nowhere in Franaszek '036 is there any mention that the input blocks to the Franaszek '036 system are part of a data stream as defined above. Although Franaszek '036 shows ellipses between data blocks 205 in FIG. 2, one of ordinary skill in the art would not consider such an illustration a data stream. The ellipses merely indicate that the Franaszek system can process more than one input data block but not that they are necessarily organized as one or more data blocks transmitted or received in a continuous sequence. More specifically, in referring to a black diagram of the overall disclosed compression/decompression system Franaszek '036 states at col. 4, lines 4-13, "A system structure suitable for use in conjunction with the present invention is shown in FIG. 1. The system includes a CPU 5 which accesses a first memory 10 containing uncompressed data blocks 15. Within the same information processing system as the CPU 5 or within another 'remote' system, there is a second memory 20....... The data blocks are transferred between the first and second memories." To one of ordinary skill in the art, this citation would imply that the input, or uncompressed, blocks in Franaszek '036 are retrieved by direct memory access techniques from the first memory 10. As noted previously in paragraph 13, one of ordinary skill in the art would distinguish this active process of retrieving a data block from an internal storage device as fundamentally different than the passive process of receiving a data stream as taught in the '506 patent.MODESTINO DECL. AT ¶ 17 (emphasis added), EX. 12, ATTACHED TO REPLY; see also id. at ¶ 13 ("retrieving a data block from an internal storage device [is] fundamentally different than the passive process of receiving a data stream."); REMARKS AT 15, REEXAMINATION OF PATENT NO. 7,161,506, REEXAM CONTROL NO. 95/000,479 (MARCH 15, 2010), EX. 14, ATTACHED TO REPLY ("Franaszek's CPU 5 retrieves data from a first memory 10 through direct memory access rather than receiving a data stream."). The discussion of the Franaszek patent describes an active retrieval by the overall system where the direct memory access functionality actively retrieves data blocks from internal memory. Any discussion of passive retrieval by Realtime differentiates the directed memory access functionality of Franaszek from the simple acceptance of data from an external source, as is taught in the '506 patent. The declaration further distinguishes Franaszek from the '506 patent by stating that Franaszek does not disclose a "data stream," unlike the '506 patent.
Thus, looking at the prosecution history as a whole, the Court finds no disclaimer. Despite multiple comments describing passive receipt of data, such comments were directed to distinguishing the patents-in-suit from prior art that disclosed active retrieval of data from internal memory; Realtime's comments, although not isolated, were not directed toward pure "passive receipt" of data, as Defendants contend. Therefore, "receiving" is not limited to "passive." However, as Realtime states, and Defendants apparently agree, the patents-in-suit are directed to compression systems that receive data from an external source. See MARKMAN TRANSCRIPT AT 62:17-63:20.
Even though Realtime asserts it withdrew any comments regarding "passive receipt" during reexamination, whether the comments were withdrawn is of no import to the disclaimer inquiry given that the Court finds the applicant did not make any clear, unmistakable disavowals. The purported withdrawal of Realtime's comments, however, does add to the ambiguity surrounding any supposed disclaimer.
B. Software
Defendants claim that during the reexamination of U.S. Patent No. 6,604,158 ("the '158 patent) Realtime repeatedly made statements claiming that software must "receive" a data stream. RESPONSE AT 24-25. Even though Realtime no longer asserts the '158 patent, Defendants contend the prosecution history is relevant to the construction of "receiving" given that the '158 patent is part of the patent family concerning the data acceleration patents that are asserted in the case. Id. at 6 n.4.
Defendants take a few comments from the prosecution history of the '158 patent and imprecisely apply Realtime's comments to all "receiving" steps disclosed in the asserted patents. In particular, Defendants hone in on remarks that note "the method steps recited in Claim 1 must necessarily be performed in software." Id. at 25 (citing EX. E at 10, ATTACHED TO RESPONSE). Yet, when read in context, Realtime's comments refer to the preamble of Claim 1 of the '158 patent, not all "receiving" elements recited across the data acceleration patents.
For example, Realtime stated:
Claims 1, 5, and 6 are directed to "a program storage device readable by machine, [sic]. . . tangibly embodying a program of instructions executable by [the] machine to perform method steps for ... compressing the data stream at a compression rate that increases the effective data storage rate of the data storage device." As such, because they are recited as being performed by a machine, based on instructions encoded on a machine-readable device, the method steps recited in Claim 1 must necessarily be performed in software.REMARKS AT 10, REEXAMINATION OF PATENT NO. 6,604,158 , REEXAM CONTROL NO. 95/000,486 (FEB. 12, 2010), EX. E, ATTACHED TO RESPONSE. Comparing Realtime's prosecution remarks with the preamble of Claim 1 of the '158 patent, the language is similar:
1. A program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for providing accelerated data storage, said method steps comprising:'158 patent at 20:4-23. Defendants fail to view the claim in its entirety, overlooking the fact that Claim 1 of the '158 patent claims a machine—not merely a program of instructions—that receives, compresses, and stores data. The machine executes the program of instructions, but the program instructions themselves do not receive, compress, or store data. Realtime's comments regarding the '158 patent during reexam essentially state the same: "[B]ecause they are recited as being performed by a machine, based on instructions encoded on a machine-readable device, the method steps recited in Claim 1 must necessarily be performed in software." REMARKS AT 10, REEXAMINATION OF PATENT NO. 6,604,158 , REEXAM CONTROL NO. 95/000,486 (FEB. 12, 2010) (emphasis added), EX. E, ATTACHED TO RESPONSE. Realtime's statements regarding Claim 1 of the '158 patent are ambiguous, noting that the machine, based on the programmed instructions, performs the method steps. Thus, one of ordinary skill could interpret Realtime's remarks as clarifying that the machine, which also contains program instructions, performs the steps of receiving, compressing, and storing data. See 01 Communique Lab., Inc. v. LogMeIn, Inc., --- F.3d ----, No. , 2012 WL 3089367, at *4 (Fed. Cir. July 31, 2012) ("There is no 'clear and unmistakable' disclaimer if a prosecution argument is subject to more than one reasonable interpretation, one of which is consistent with a proffered meaning of the disputed term.") (internal citations omitted). Therefore, the Court declines to find that Realtime made a clear and unmistakable surrender of claim scope. See Elbex Video, 508 F.3d at 1373 ("For a prosecution statement to prevail over the plain language of the claim, the statement must be clear and unmistakable such that the public should be entitled to rely on any 'definitive statements made during prosecution.'") (quoting Omega Eng'g, Inc., 334 F.3d at 1324). Consequently, Realtime's remarks regarding the '158 patent, and in particular, the "receiving" limitation, do not apply to the '506 or '937 patents.
receiving a digital data stream at an input data transmission rate which is greater than a data storage rate of a target storage device;
compressing the digital data stream at a compression rate that increases the effective data storage rate of a target storage device;
storing the compressed digital data stream in the target storage device;
wherein the instructions for performing the step of compressing comprise instructions for performing the steps of:
reading a first parameter that is indicative of the compression type to be applied to the input digital data stream; and
selecting at least one allowable encoder based on the first parameter.
Defendants also note that similar comments were made during the course of reexamination of Claim 1 of U.S. Patent No. 6,601,104 ("the '104 patent"). RESPONSE AT 25. The Court's reasoning equally applies to comments made with regard to the '104 patent; Claim 1 of the '104 patent recites similar, if not identical, preamble limitations. See '104 patent at 18:41-44.
As noted above, Realtime's remarks refer to the preamble of Claim 1 of the '158 patent, specifically, the disclosure of a machine containing executable program instructions where the machine performs the recited method steps. In contrast, the claims at issue (in the '506 and '937 patents) containing the "receiving" limitations do not contain a preamble limitation similar to that of Claim 1 of the '158 patent; neither Claims 1 and 11 of the '937 patent, nor Claim 86 of the '506 patent recite preamble limitations requiring executable program instructions. Accordingly, Realtime did not clearly state that the '506 and '937 patents required software to "receiv[e] a data stream" or "receiv[e] a data block."
The preambles of all claims recited "A method comprising . . . ." See e.g., '506 patent at 32:50.
Moreover, the specification of each patent explicitly states that the disclosed invention may be implemented in a variety of forms: "It is to be further understood that the present invention may be implemented in various forms of hardware, software, firmware, or a combination thereof." '506 patent at 6:26-28; '937 patent at 4:50-53. Even if Realtime's remarks during reexam concerning the '158 patent applied to the '506 and '937 patents, such comments would directly contradict the specifications of each patent, therefore creating ambiguity. See Ecolab, 569 F.3d at 1344 (finding patent applicant did not disavow claim scope when the patent specification clearly contradicted the allegedly disclaiming statement). Thus, the Court finds no disclaimer with regard to "receiving a data stream" or "receiving a data block" as used in the '937 and '506 patents, respectively.
In accordance with the Court's prior construction in Packeteer, the Court construes "receiving a data stream" as "receiving from an external source one or more data blocks transmitted in sequence." The Court further finds that "receiving a data block" requires no construction.
V. "compressing the data stream" / "said data was compressed" / "compressing said data block"
This term is contained in Claims 1, 5-8, 11 and 14-16 of the '937 patent.
This term is contained in Claim 1 of the '345 patent.
This term is contained in Claims 19 and 42 of the '300 patent and Claims 90, 92-95 of the '506 patent.
+-----------------------------------------------------------------------------+ ¦Plaintiffs Proposed Construction ¦Defendants' Proposed Construction ¦ +------------------------------------+----------------------------------------¦ ¦ ¦Compressing with software the received ¦ ¦Further construction of these terms ¦data ¦ ¦is ¦ ¦ ¦ ¦blocks on a per block basis in the ¦ ¦unnecessary. ¦sequence ¦ ¦ ¦ ¦ ¦ ¦received ¦ +-----------------------------------------------------------------------------+
The dispute surrounding these terms is three-fold: (1) whether compression must necessarily performed in software; (2) whether compression occurs "on a per block basis"; and (3) whether compression of data must be performed in the sequence data is received. RESPONSE AT 27-28. Realtime contends that these terms do not require construction because each term is comprised of other terms for which there are agreed constructions. PLTFF'S BRIEF AT 24. Defendants reiterate their arguments regarding "receiving a data stream" and contend the same remarks Realtime made with respect to the reexamination of the '158 patent also apply to the "compressing" step; therefore, the compressing step must be executed in software. RESPONSE AT 26-27. Defendants further maintain that the specifications exclusively describe data compression as performed on a per block basis. Id. at 27 (citing '158 patent at 7:7-8; 10:6-13). Finally, Defendants assert that that the compressing and storing steps recited in the claim must be done in sequential order. Id. at 28-29. Because the claim refers to "the data stream" and "said data stream," Defendants contend that the referred antecedent is the "data stream" defined as "one or more data blocks transmitted in sequence." Id. Thus, it logically follows that once a data stream is received, it is compressed and stored in the same sequential order. See id. at 28.
The Court has already rejected Defendants' "in software" arguments above. See SECTION IV.B. The same reasoning applies to the "compression" steps. As for Defendants' "per block basis" and "sequential" arguments, the Court finds such contentions equally unpersuasive. As Realtime points out, the specification of the '345 patent, which shares a specification with the '937 patent, describes two methods for compressing data:
It is to be understood that Method 1 relies on data compression and encoding techniques that process data as a contiguous stream (i.e., not block oriented). . . . Method 2 provides for block oriented processing of the input data blocks. . . . It should be noted that Method 1 and Method 2 are not mutually exclusive, and may be utilized in any combination.'345 patent at 7:64-66; 8:41-42; 8:61-63 (emphasis added); see also '937 patent at 7:33-35; 8:4-5; 8:19-21. The specification explicitly lays out two separate methods of compression: one that operates on a per block basis (Method 2), as Defendants argue, and one that processes data as a continuous stream (Method 1). The specification even goes so far as to say that both methods could be combined such that a portion of the data is compressed on a per block basis while another portion may be compressed in a non-block oriented manner. Therefore, to adopt Defendants' proposal would necessarily exclude a preferred embodiment of '937 and '345 patents. Vitronics Corp., 90 F.3d at 1584 (stating that interpreting a claim such that it excludes a preferred embodiment in the specification is "rarely, if ever correct.").
Moreover, the '937 patent claims state that the data stream is compressed. See e.g., '937 patent at 18:56. The parties agreed the construction of "data stream" is "one or more data blocks transmitted in sequence." Ex. 1 at 11, ATTACHED TO JOINT CLAIM STATEMENT (Doc. No. 223). Per the agreed definition, only the transmission of data blocks to the compression functionality need be sequential, not necessarily the compression itself.
Further, the specification notes that the compression process need not be performed sequentially:
Data compression is performed by the encoder module 25. . . . [T]he encoding process may be performed either in parallel or sequentially. In particular, the encoders E1 through En of encoder module 25 may operate in parallel (i.e. simultaneously processing a given input data block by utilizing task multiplexing on a single central processor, via dedicated hardware, by executing on a plurality of processor[s] or dedicated hardware systems, or any combination thereof). In addition, encoders E1 through En may operate sequentially on a given unbuffered or buffered input data block.'345 patent at 13:12-29 (emphasis added); see also '937 patent at 12:3-21; '300 patent at 7:17-35; '506 patent at 7:23-41. This particular portion of the specification not only contradicts Defendants' argument that compression must occur sequentially, but also dispels Defendants' arguments requiring such compression to occur in software; the cited portion states that compression may occur on "dedicated hardware systems." Because the specification expressly describes compression occurring simultaneously on separate encoders, the "sequential" limitation Defendants propose is improper.
In addition to agreeing to the construction of "data stream," the parties have agreed to the construction of "compressing." Therefore, the parties have essentially agreed to the constructions of the terms at issue, albeit in a piecemeal fashion. Therefore, the Court agrees with Realtime. Having resolved the claim scope dispute, the Court finds that these terms require no construction. O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1362 (Fed. Cir. 2008).
"Compressing" means "representing data with fewer bits." JOINT CLAIM CONSTRUCTION STATEMENT AT 2 (citing PACKETEER MARKMAN).
VI. "storing the compressed data stream in the target storage device" / "said compressed data stream is stored on said memory device"
This term is contained in Claims 1 and 11 of the '937 patent.
This term is contained in Claim 1 of the '530 patent.
--------
+-----------------------------------------------------------------------------+ ¦Plaintiffs Proposed Construction ¦Defendants' Proposed Construction ¦ +-------------------------------------+---------------------------------------¦ ¦Storing the compressed data stream in¦Storing in software, the compressed ¦ ¦the ¦received ¦ ¦ ¦ ¦ ¦identified memory device. ¦data blocks in the sequence received. ¦ +-----------------------------------------------------------------------------+
The parties reiterate the same arguments regarding "compressing" data for "storing" data; Defendants contend the storing step must be performed in software and stored in the sequence the data was received. See PLTFFS' BRIEF AT 13-14; RESPONSE AT 26-29.
For the reasons stated above, the Court declines to limit the "storing" step to "in software." Moreover, the claim language requires storing in a "target storage device" or "memory device." The Court has construed—and the parties agree—that a "target storage device" or "memory device" is "an identified memory device to which data is directed for recording and later retrieval." One of skill in the art would understand such devices to be implemented in hardware, as the specification suggests: "It is to be further understood that the present invention may be implemented in various forms of hardware, software, firmware, or a combination thereof." '506 patent at 6:26-28; '937 patent at 4:50-53. Thus, the compressed data cannot be stored in software, as Defendants suggest.
Moreover, the compressed data need not be stored in the sequence received. Figure 4a of the '530 and '937 patents diagrams the timing methods for accelerated data storage:
+--------------------------------------------------------------------------------------------------+ ¦Time Interval ¦T1 ¦T2 ¦T3 ¦T4 ¦T1 ¦ +---------------+---------------+---------------+---------------+---------------+------------------¦ ¦Receive ¦Receive ¦Receive ¦Receive ¦Receive ¦Receive ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦Data Block ¦Data Block 1 ¦Data Block 2 ¦Data Block 3 ¦Data Block 4 ¦Data Block ¦ +---------------+---------------+---------------+---------------+---------------+------------------¦ ¦METHOD 1 ¦ ¦ ¦ ¦ ¦ ¦ +---------------+---------------+---------------+---------------+---------------+------------------¦ ¦Compress ¦Compress ¦Compress ¦Compress ¦Compress ¦Compress ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦Data Block ¦Data Block 1 ¦Data Block 2 ¦Data Block 3 ¦Data Block ¦Data Block ¦ +---------------+---------------+---------------+---------------+---------------+------------------¦ ¦Slots Encoded ¦Store Encoded ¦Store Encoded ¦Store Encoded ¦Store Encoded ¦Store Encoded ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦Data Block ¦Data Block 1 ¦Data Block 2 ¦Data Block 3 ¦Data Block 4 ¦Data Block ¦ +---------------+---------------+---------------+---------------+---------------+------------------¦ ¦METHOD 2 ¦ ¦ ¦ ¦ ¦ ¦ +---------------+---------------+---------------+---------------+---------------+------------------¦ ¦Compress ¦ ¦Compress ¦Compress ¦Compres3 ¦Compress ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦Data Block ¦ ¦Data Block 1 ¦Data Block 2 ¦Data Block 3 ¦Data Block ¦ ¦ +---------------+---------------+---------------+---------------+------------------¦ ¦Store Encoded ¦ ¦ ¦Store Encoded ¦Store Encoded ¦Store Encoded ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦Data Block ¦ ¦ ¦Data Block ¦Data Block 2 ¦Data Block (i-2) ¦ +--------------------------------------------------------------------------------------------------+
FIGURE 4a
As Figure 4a shows, the compressed data need not be stored in the same sequence it is received. For example, data block 2 is received at (time) T2 and data block 3 is received at T3. When using Method 1 and Method 2 in conjunction—as warranted by the specification ('530 patent at 8:10-12; '937 patent at 8:19-21)—data block 3 is stored (at T3, Method 1) before data block 2 (at T4, Method 2). Thus, data blocks may be stored in a sequence different from the order in which they were received.
Having resolved the claim scope dispute, the Court finds that the trier of fact will understand the plain and ordinary meaning of the terms. Therefore, no construction is necessary.
CONCLUSION
For the foregoing reasons, the Court adopts the constructions set forth above.
______________________
JOHN D. LOVE
UNITED STATES MAGISTRATE JUDGE