This is the first in a series of articles discussing recent orders of interest issued by the
In Long Hua Tech. Co., Ltd. v. A123 Sys., LLC, No. 1:20-cv-11887-RGS,
The Court quickly rejected the motion to the extent that it was moot for seeking already-produced documents and because two interrogatories at issue sought answers to "technical/theoretical questions of a high order of abstraction [that] ... do not specifically relate to an accused product and are the types of general questions that are better directed to an expert witness."
"The only dispute that remain[ed] is whether Long Hua may obtain discovery of A123's products beyond the two specifically accused models" identified in the infringement contentions. The Court briefly surveyed precedent from other Districts, agreeing with the District of
Turning to the facts before it, the Court found that Plaintiff failed to make a sufficient showing that the non-accused products are "reasonably similar" to the accused products such that they are relevant to the infringement claims. More specifically, because Plaintiff failed to show that it had conducted at least "some reasonable inquiry and an understandable calculation that [the products on which discovery was sought], in [its] view, likely infringe the patents at issue," its motion to compel discovery on non-accused products was denied. Quoting Invensas, 287 F.R.D. at 284.
The Court construed five terms: (i) variations of "compressed data"; (ii) "descriptor / token"; (iii) "data stream"; (iv) "excludes analyzing based solely on a descriptor that is indicative of the one or more parameters or attributes of the data within the data block"; and (v) "data accelerator."
1. "compressed data"
The parties requested construction of the terms "compressed data," "compressed data block," "compressed data stream," "compressed form," "compressing," and "compression" as those terms are used in the claims:
The Court conducted a detailed analysis of the claims and specifications, exploring the disclosures of lossy and lossless compression and finding that "the ability to decode data—whether as an exact replica of the original data or an approximation—is intricately tied up with the idea of compression." The Court thus agreed in part with Defendants, but stopped short of adopting their proposal entirely because it could be understood to exclude lossy compression.
Accordingly, the Court construed "compressed [data]" as "[data] encoded to reduce its size, such that the encoded [data] can be decoded to reconstruct the original [data] exactly or approximately."
2. "descriptor / token"
The parties requested construction of the terms "descriptor" and "token" as those terms are used in the claims:
The Parties agreed that "descriptor" and "token" as used in three asserted patents are synonymous and include "recognizable data." Id. at 12. Defendants contended that the remainder of their proposal comports with a construction affirmed by the Federal Circuit addressing a "parent" patent. Citing Realtime Data, LLC v.
The Court rejected Defendants' contention that the
The Court then rejected Defendants' proposal as seeking to improperly import limitations from the specification.
Accordingly, the Court construed "descriptor" or "token" as "recognizable data."
3. "data stream"
The parties requested construction of the term "data stream":
"The parties agree[d] that a 'data stream' refers to "one or more data blocks transmitted in sequence,' but they dispute[d] whether the data blocks in the stream must be (1) 'uncompressed' and (2) transmitted 'from an external source whose characteristics are not controlled by the data encoder or decoder.'"
As to the issue of compression, the Court rejected Plaintiff's contention that the claims required that the data stream could be compressed, finding support throughout the specification that the data stream is uncompressed when it is received. The Court rejected the second additional limitation proposed by Defendants, finding that they had identified no supporting language in the claims or specification.
Accordingly, the Court construed "data stream" as "one or more uncompressed data blocks transmitted in sequence."
4. "excludes analyzing based solely on a descriptor that is indicative of the one or more parameters or attributes of the data within the data block"
The parties requested construction of the phrase "excludes analyzing based solely on a descriptor that is indicative of one or more parameters or attributes of the data within the data block":
Plaintiff contended that no construction is necessary, while Defendants argued that "inclusion of the words 'based solely on' in the claim language means that the analysis of the 'data within the data block' (i.e., the content of the data) is in addition to analyzing the descriptor (i.e., file type descriptor)" (quoting Defendants' memorandum).
The Court found that "the phrase is written in plain, albeit awkward, English" and that Defendants' proposal improperly imported a limitation from the specification. As such, it construed the term according to its plain and ordinary meaning.
5. "data accelerator"
The parties requested construction of the term "data accelerator" as the term is used in the claims:
The Parties first disputed whether the term "data accelerator" in a mean-plus-function term. Plaintiff conceded at the Markman hearing that "data accelerator" is not a term of art, but nevertheless contended through its expert that "a person of ordinary skill in the art would understand the meaning of 'data accelerator' in the context of the asserted patents." The Court explored the uses of the term in the specifications, and rejected Plaintiff's position to conclude that "a 'data accelerator,' as used in the asserted patents, stands in for the abstract idea that certain combinations of known compression techniques can speed up storage and retrieval. Because the patents provide no direction regarding how the proposed speed result is to be achieved, the court concludes that the term 'data accelerator' is purely functional as used in the claims and invokes means-plus-function construction pursuant to 35 U.S.C. § 112."
Because the Parties largely agreed on the functions for the claims at issue, the Court next turned to the structure used to perform those functions. The Plaintiff proposed "hardware or software with one or more compression encoders," while the Defendants proposed "[a] processor programmed to compress data by" various claim-specific methodologies. Referencing
Accordingly, the Court found that the structure for the term "data accelerator" is "a processor programmed to:
- count the size of an incoming data block, see '530 Patent at Fig. 8 (element 20), 11:23-32; '908 Patent at Fig. 8 (element 20), 11:49-58;
- encode the data block with one or more encoders, see '530 Patent at Fig. 8 (element 25), 11:40-12:13; '908 Patent at Fig. 8 (element 25), 11:65-12:39;
- count the size of the encoded data block or blocks, see '530 Patent at Fig. 8 (element 30), 12:14-20; '908 Patent at Fig. 8 (element 30), 12:40-46;
- calculate a compression ratio for each encoded data block, see '530 Patent at Fig. 8 (element 35), 12: 20-25; '908 Patent at Fig. 8 (element 35), 12:46-51;
- compare the calculated compression ratio or ratios against a prespecified threshold, see &rrsquo;530 Patent at Fig. 8 (element 35), 12: 25-33; '908 Patent at Fig. 8 (element 35), 12:51-59; and
- select the encoded data block having the greatest compression ration if the threshold limit is exceeded by at least one encoded data block, see '508 Patent at 12:46-49; '908 Patent at 13:5-8."
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
20001-4413
Tel: 2024084000
Fax: 2024084400
E-mail: info@finnegan.com
URL: www.finnegan.com
© Mondaq Ltd, 2022 - Tel. +44 (0)20 8544 8300 - http://www.mondaq.com, source