Summary
In Apple I, Judge Grewal addressed two arguments about the construction of “real-time broadcasting,” both of which are relevant here.
Summary of this case from BSD Crown, Ltd. v. Amazon.comOpinion
Case No. 5:11-cv-01079-PSG
10-09-2014
EMBLAZE LTD., Plaintiff, v. APPLE INC., Defendant.
CLAIM CONSTRUCTION ORDER
(Re: Docket No. 169)
In this patent infringement suit, Plaintiff Emblaze Ltd. ("Emblaze") alleges that Defendant Apple, Inc. ("Apple") infringes U.S. Patent No. 6,389,473. The parties submitted 16 claim construction disputes for resolution by the court. Two days after the hearing, the court issued a summary construction order and explained that a more complete order would follow providing the court's reasoning. The court now provides that reasoning.
See Docket No. 169.
I. BACKGROUND
A. The Parties and Disputed Technology
Emblaze is an Israeli corporation dedicated to the "development and marketing of innovative high-tech technologies and products." Apple is a California-based corporation that, among other things, markets phones, tablets and computers that incorporate "HTTP Live Streaming technology" capable of "real-time" broadcasting. Emblaze owns the sole patent at issue in this case: U.S. Patent No. 6,389,473 ("the '473 patent").
Docket No. 143 at ¶ 1.
Id. at ¶ 11.
See id. at ¶ 6; Docket No. 143-1, Ex. A.
The '473 patent claims methods and apparatuses that allow "transmission of live audio and video to multiple devices" without requiring "devoted streaming servers" and permitting adjustment to "different bandwidths" where necessary. As the abstract of the '473 patent puts it, the invention disclosed is:
See Docket No. 143 at ¶ 9.
A method for real-time broadcasting from a transmitting computer to one or more client computers over a network, including providing at the transmitting computer a data stream having a given data rate, and dividing the stream into a sequence of slices, each slice having a predetermined data size associated therewith. The slices are encoded in a corresponding sequence of files, each file having a respective index, and the sequence is uploaded to a server at an upload rate generally equal to the data rate of the stream, such that the one or more client computers can download the sequence over the network from the server at a download rate generally equal to the data rate.Independent Claim 1 of the '473 patent is representative:
A method for real-time broadcasting from a transmitting computer to one or more client computers over a network, comprising:Emblaze claims that Apple's HTTP Live Streaming, which Apple introduced into its products around 2009, infringes asserted '473 patent claims 23, 28, 37, and 40.
providing at the transmitting computer a data stream having a given data rate; dividing the stream into a sequence of slices, each slice having a predetermined data
size associated therewith;encoding the slices in a corresponding sequence of files, each file having a respective
index; anduploading the sequence to a server at an upload rate generally equal to the data rate of
the stream, such that the one or more client computers can download the sequence over the network from the server at a download rate generally equal to the data rate.
See Docket No. 143-1, Ex. A at 14:18-32.
See Docket No. 143 at ¶ 12.
B. Procedural History
Emblaze kicked off this case by filing a complaint for patent infringement in the Southern District of New York. Several months later, the case was transferred to this district. After the parties initially declined to consent to magistrate judge jurisdiction, the case was assigned to United States District Judge Saundra Brown Armstrong. Emblaze thereafter sought leave to amend its complaint to:
See Docket No. 1.
See Docket No. 24.
See Docket No. 31.
(1) amend the list of claims of the '473 Patent that are asserted by Emblaze so as to conform the allegations to what Emblaze has asserted in its Infringement Contentions;After Apple filed a statement of non-opposition, Judge Armstrong granted Emblaze's motion for leave to amend the complaint. Apple then moved to dismiss the amended complaint pursuant to Fed. R. Civ. P. 12(b)(6). Judge Armstrong dismissed Emblaze's indirect infringement claims with leave to amend, but denied Apple's related request to dismiss Emblaze's direct infringement or willfulness claims. Emblaze's responded with a second amended complaint claiming direct, induced, contributory and willful infringement.
(2) amend the products that Emblaze is accusing of infringement so as to conform the allegations of the complaint to what Emblaze has learned in its ongoing investigation and from discovery thus far;
(3) remove certain allegations concerning Apple's presence in the Southern District of New York (no longer relevant now that the action has been transferred to the Northern District of California);
(4) update the firm affiliation of counsel for Emblaze and the change of venue from the Southern District of New York to the Northern District of California; and
(5) make minor editing changes to the text.
See Docket No. 75 at 2-3 (verb tenses modified).
See Docket No. 137.
See Docket No. 143.
Pursuant to the parties' stipulation, the case was reassigned to the undersigned. Following this latest reassignment and a tutorial and hearing, the court construed the disputed claim terms as follows:
See Docket No. 150.
See Docket No. 169 at 1-3.
| CLAIM TERM | CONSTRUCTION |
| "real-time broadcasting" | simultaneous transmission of data to one or more clients matching the human perception of time or proceeding at the same rate as a physical or external process |
| "providing at the transmitting computer a data stream having a given data rate" | the transmitting computer provides a data stream having a given amount of data per unit of time |
| "data stream having a given data rate" | a data stream having a given amount of data per unit of time |
| "slice" | a discrete segment of the data stream |
| "each slice having a predetermined data size associated therewith" | each slice having a data size, which may be a time duration, assigned in advance of the stream being divided |
| "encoding the slices in a corresponding sequence of files" | forming each slice as a file, wherein a file includes compressed data from the slice and a file descriptor, and wherein the sequence of files corresponds to the sequence of slices |
| "sequence of files, each file having a respective index" | sequence of files, wherein each file has an indicator that represents a respective slice's location in the sequence |
| "uploading the sequence to a server at an upload rate generally equal to the data rate of the stream" | transmitting the files from the transmitting computer to the server at an upload rate generally equal to the data rate of the stream |
| "such that one or more client computers can download the sequence over the network from the server at a download rate generally equal to the data rate" | such that one or more client computers are able to select individual files corresponding to the slices for download over the network at a download rate generally equal to the data rate |
| "decode the sequence" | decompressing any compressed data in the sequence |
| "play back the data stream responsive to the indices of the files" | playing back the data stream based on the indices of the files to be played back |
| "at a replay rate generally equal to the data rate" | the rate at which the client plays back the data stream is generally equal to the data rate of the stream |
| "uploading and updating an index file containing the index of the file in the sequence that was most recently uploaded" | uploading to a server an index file, and updating the index file with the index of the most recently uploaded file |
| "encoding slices at a different plurality of different quality levels" | forming slices at more than one quality level |
| "determining a data bandwidth of the network between the server and the client computer" | the client determines a data rate at which a client can download a file from the server |
| "wherein dividing the stream into the sequence of slices comprises dividing the stream into a sequence of time slices, each having a predetermined duration associated therewith" | the stream is divided into a sequence of slices, where the predetermined data size of the slices is established by setting the time duration of the slices |
A few months later, Apple moved the court to reconsider or clarify its prior construction that the term "each slice having a predetermined data size associated therewith" means "each slice having a data size, which may be a time duration, assigned in advance of the stream being divided." The court agreed that reconsideration was warranted but further construed the term as meaning "each slice having a data size, which may be established by setting a time duration of the slice, assigned in advance of the stream being divided."
See Docket No. 207.
Docket No. 214 at 1.
Apple next moved for leave to amend its invalidity contentions, which the court granted. Pursuant to a stipulation between the parties, the court also held that it would consider Emblaze's revised patent disclosures to be its operative patent disclosures.
See Docket No. 216.
See Docket No. 248.
See Docket No. 300.
As the case turned toward dispositive motion practice, the court denied Apple's motion to stay in light of the Supreme Court's decision to grant certiorari in Akami v. Limelight Networks. The court also held that although portions of Emblaze expert Vijay Madisetti's report would not be struck, Emblaze was precluded from introducing later-model accused products in its report that were not disclosed in Emblaze's original or revised infringement contentions.
See Docket No. 361; Akamai Technologies, Inc. v. Limelight Networks, Inc., 692 F.3d 1301 (Fed. Cir. 2012) cert. granted, 134 S. Ct. 895 (2014).
See Docket No. 394.
Apple next filed four summary judgment motions. After a hearing, the court granted Apple's motion for summary judgment of no willful infringement, granted-in-part Apple's motion for summary judgment of non-infringement as to all accused streams, denied Apple's motion for summary judgment of non-infringement of specific content providers, and denied Apple's motion for summary judgment of invalidity. In granting-in-part Apple's motion for summary judgment of non-infringement as to all accused streams, the court additionally construed the term "upload rate." The court found that "'upload rate' in the context of the '473 patent should be understood to include wait time between the transmission of files within a sequence."
See Docket No. 424.
See id. at 11-14.
Id. at 14.
Following the Supreme Court's decision in Akamai, the court permitted Apple to file a motion for summary judgment of non-infringement as to Emblaze's asserted method claims. After considering Apple's motion, the court granted it in-part.
See Docket No. 468.
See Docket No. 520.
The parties then filed their pre-trial motions, including three Daubert motions. Subsequent to the pre-trial conference, the court ruled on the pre-trial motions, including granting-in-part Apple's two Daubert motions and denying Emblaze's Daubert motion. The case proceeded to trial, and after eight days of testimony, statements, arguments and deliberations, the jury returned a verdict finding that none of Apple's accused products infringed the '473 patent. Now that trial is complete, the court provides the parties with the reasoning underlying the court's claim construction rulings.
See Docket Nos. 519, 544.
See Docket No. 609.
II. LEGAL STANDARDS
Nine years after the Federal Circuit's seminal Phillips decision, the canons of claim construction are now well-known—if not perfectly understood—by parties and courts alike. "To construe a claim term, the trial court must determine the meaning of any disputed words from the perspective of one of ordinary skill in the pertinent art at the time of filing." This requires a careful review of the intrinsic record, comprised of the claim terms, written description, and prosecution history of the patent. While claim terms "are generally given their ordinary and customary meaning," the claims themselves and the context in which the terms appear "provide substantial guidance as to the meaning of particular claim terms." Indeed, a patent's specification "is always highly relevant to the claim construction analysis." Claims "must be read in view of the specification, of which they are part." Although the patent's prosecution history "lacks the clarity of the specification and thus is less useful for claim construction purposes," it "can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be." The court also has the discretion to consider extrinsic evidence, including dictionaries, learned treatises, and testimony from experts and inventors. Such evidence, however, is "less significant than the intrinsic record in determining the legally operative meaning of claim language."
Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc).
Chamberlain Group, Inc. v. Lear Corp., 516 F.3d 1331, 1335 (Fed. Cir. 2008).
See id. ("To construe a claim term, the trial court must determine the meaning of any disputed words from the perspective of one of ordinary skill in the pertinent art at the time of filing. Intrinsic evidence, that is the claims, written description, and the prosecution history of the patent, is a more reliable guide to the meaning of a claim term than are extrinsic sources like technical dictionaries, treatises, and expert testimony.") (citing Phillips, 415 F.3d at 1312).
Phillips, 415 F.3d at 1312-15.
Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995); see also Ultimax Cement Mfg. Corp v. CTS Cement Mfg. Corp., 587 F. 3d 1339, 1347 (Fed. Cir. 2009).
Phillips, 415 F.3d at 1317 (internal quotations omitted).
See id. ("Although we have emphasized the importance of intrinsic evidence in claim construction, we have also authorized district courts to rely on extrinsic evidence, which 'consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises.'") (quoting Markman, 52 F.3d at 980).
Id. (citing C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 862 (Fed. Cir. 2004)) (internal quotations and additional citations omitted).
III. DISCUSSION
A. Dispute #1: "Real-Time Broadcasting"
| CLAIM TERM 1 | |
| "real-time broadcasting" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "a broadcast data stream that is received at one or more clients without substantial delay after the broadcast" | "communicating a data stream that is received at one or more clients simultaneously with minimal delay" |
| CONSTRUCTION | |
| "simultaneous transmission of data to one or more clients matching the human perception of time or proceeding at the same rate as a physical or external process" |
The parties' dispute over the construction of "real-time broadcasting" has two components. First, Apple and Emblaze contest whether "real-time broadcasting" requires simultaneous receipt of the data stream by clients (Apple's position), or only simultaneous transmission of the data stream (Emblaze's position). In support of its narrower construction, Apple cites to the first sentence of the background section of the '473 patent, which states: "In network broadcasting, data are transmitted over a network in real time from a single transmitting computer to a plurality of clients simultaneously." Apple argues that "[i]t is illogical to read the above passage as emphasizing simultaneous transmission only, while the clients can receive the data in a staggered or otherwise unsystematic fashion as Emblaze contends."
'473 patent, at 1:16-18.
Docket No. 118, at 7.
The court finds Apple's position unpersuasive for two reasons.
First, Apple's quoted excerpt from the specification refers to simultaneous transmission, not simultaneous receipt. The adverb "simultaneously" in the passage modifies the verb "transmitted" rather than receipt by clients. Second, the background section of the '473 patent describes the prior art, not the invention. Without some indication in the background section that this statement also describes the patented invention, the court will not assume statements about the prior art apply to the claimed invention. Moreover, the fact that Apple fails to identify any other portions of the specification that imply that the invention as claimed requires simultaneous receipt of the data stream by clients strongly counsels against importing this limitation into the "real-time broadcasting" term. Accordingly, the court's construction requires simultaneous transmission of the data stream, but not simultaneous receipt.
Second, Apple and Emblaze essentially dispute the immediacy with which the invention must deliver the event stream to the user. This disagreement centers on the degree of delay allowable in "real-time" transmission. Apple requests that the court construe "real-time" to require "minimal delay," whereas Emblaze contends that "real-time" means "without substantial delay." There is not much difference between these two constructions, but the court must nevertheless resolve the conflict. The parties cite four passages of the specification as informing the construction of "real-time." The '473 patent explains that "[t]he division of the data stream into slices . . . allows the broadcast to go on substantially in real time without the use of special-purpose hardware." The specification repeats this "substantially in real time" language later: "Clients 30 connect to server 36 and receive the multimedia sequence, substantially in real time." The third and fourth passages are similar, but they add that any delay is preferably minimal: "When one of computers 30 connects to server 36 and begins to download the data stream, it first reads the index file in order to identify at what point in stream 40 to begin and to start receiving the data stream substantially in real time, preferably with only a minimal lag, as it is transmitted from computer 34."
'473 patent, at 2:17-21.
Id. at 7:4-5.
Id. at 8:1-7; see also id. at 10:49-54 ("Time stamps in the data stream are used to synchronize the data, so that the multimedia sequence is played back just as it was input at computer 34, preferably with only a minimal necessary transmission and decoding delay.").
Unfortunately, these specification excerpts do not especially inform the court as to the meaning of "real-time." Instead, they describe two characteristics of the invention: (1) the invention transmits the data stream to the client "substantially in real time," and (2) a preferred embodiment of the invention transmits the data stream to the client "with minimal lag." The first characteristic is unhelpful in defining "real-time" because it uses the term itself. The second characteristic is also unhelpful because Federal Circuit law is clear that courts typically should not import limitations from a preferred embodiment into a claim.
See id. at 2:17-21, 7:4-5, 8:1-7.
See id. at 8:1-7, 10:49-54.
See, e.g., Phillips, 415 F.3d at 1323 ("[A]lthough the specification often describes very specific embodiments of the invention, we have repeatedly warned against confining the claims to those embodiments."); Kara Tech. Inc. v. Stamps.com Inc., 582 F.3d 1341, 1348 (Fed. Cir. 2009) ("The patentee is entitled to the full scope of his claims, and we will not limit him to his preferred embodiment or import a limitation from the specification into the claims.").
Without further citations to the intrinsic evidence from the parties, the court turns to the specification for other clues as to the meaning of "real-time." One passage overlooked by the parties is especially helpful. The '473 patent states that "[f]urther preferably, the client compares the times stamped in the data stream to a local real-time clock and, if it determines that there is a significant lag in the time codes relative to the real-time clock, opens additional links with server 36 in order to increase the overall data rate." While the steps of recording and comparing time stamps are part of a preferred embodiment and should not be imported into a basic claim term like "real-time," inherent in this excerpt is the idea that the delivery of the data stream to the client should generally match the procession of the event being broadcast. The specification also mentions that applications of the invention include "an interview program or an entertainment or sports event" and "video teleconferencing." Applications such as these require a transmission system rapid enough to proceed in "real-time" with the live event. The Microsoft Computer Dictionary's definition of "real-time" expresses this requirement well: "Real-time operations are those in which the machine's activities match the human perception of time or those in which computer operations proceed at the same rate as a physical or external process."
'473 patent, at 10:59-63.
Id. at 6:58-59.
Id. at 13:49.
Docket No. 119-6, Handy Decl. Ex. F, Microsoft Computer Dictionary 441 (5th ed. 2002).
This language best captures the meaning of "real-time" as it is used by the '473 patent. The Federal Circuit "ha[s] especially noted the help that technical dictionaries may provide to a court 'to better understand the underlying technology' and the way in which one of skill in the art might use the claim terms." As such, the court construes "real-time broadcasting" to mean "simultaneous transmission of data to one or more clients matching the human perception of time or proceeding at the same rate as a physical or external process."
Phillips, 415 F.3d at 1318 (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1584 n.6 (Fed. Cir. 1996)).
B. Dispute #2: "Providing at the Transmitting Computer a Data Stream Having a Given Data Rate"
| CLAIM TERM #2 | |
| "providing at the transmitting computer a data stream having a given data rate" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "providing from the transmitting computer a data stream [having an assigned data rate, where a data rate is an amount of data per unit of time]" | "inputting a data stream to the transmitting computer from a source of broadcast data" |
| CONSTRUCTION | |
| "the transmitting computer provides a data stream [having a given amount of data per unit of time]" |
The limitation, "providing at the transmitting computer a data stream having a given data rate," appears in claim 1, upon which asserted claim 23 depends. Apple and Emblaze contest whether "providing at the transmitting computer a data stream" requires a data stream to be input to the transmitting computer from a source of broadcast data (Apple's position), or whether the data stream can be generated by the transmitting computer itself (Emblaze's position).
The specification is clear that some embodiments of the invention broadcast data that is generated by the transmitting computer. For example, the summary of the invention section states that "[i]n some preferred embodiments of the present invention, the data stream comprises multimedia data captured or generated by the transmitting computer." Later, the specification takes care to say that although the transmitting computer "preferably receives audiovisual input from input devices," "data inputs of other types may be generated at or by computer 34 using any suitable means known in the art." The specification thus considers a data stream generated by the transmitting computer to be within the scope of the invention. The disputed term also appears in claim 1, rather than a dependent claim more likely to claim a narrower embodiment of the invention. Nothing in the plain claim language—"providing at the transmitting computer a data stream" —indicates that the data stream must come from an external source. Accordingly, as Emblaze argues, the claim should not be so limited.
'473 patent, at 2:29-31 (emphasis added).
Id. at 6:32-35.
Rather than argue that the claim excludes the more minor embodiments of the invention that allow for the transmitting computer to generate the data stream, Apple simply points to other embodiments in which a data stream is input to the transmitting computer from an external source. For example, describing Figure 5, the specification states that "[t]o begin the broadcast, computer 34 connects to server 36, optionally opening the plurality of links shown in Fig. 4. Broadcast data are then input to the computer, for example, from input devices 22, or from a video, audio or animation sequence stored on disk or tape." Apple's two other citations to the specification are similarly unpersuasive. Considering the specification as a whole, the court finds that the invention is principally directed toward improving streaming of external events. However, the specification is unequivocal that the claims are not limited to only data streams input to the transmitting computer. The court therefore construes "providing at the transmitting computer a data stream [having a given data rate]" to mean "the transmitting computer provides a data stream [having a given amount of data per unit of time]."
Id. at 9:62-66.
See id. at 1:23-28 ("Fig. 1 is a schematic illustration showing a real-time broadcasting system 20, as is known in the art. One or more input devices 22 (for example, a video camera and/or microphone) are used to generate a multimedia data stream representing an entertainment or informational program to be transmitted to a plurality of clients 30 via a network 28."), 7:36-42 ("Computer 34 monitors the time codes as file 40 is transmitted, and clients 30 similarly monitor the time codes as the file is received, in order to ensure that the transmission or reception is 'keeping up' with the input of the data to the computer.").
See id. at 6:58-59 (mentioning "an interview program or an entertainment or sports event"), 13:49 (mentioning video teleconferencing).
C. Dispute #3: "Data Stream Having a Given Data Rate"
| CLAIM TERM #3 | |
| "data stream having a given data rate" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "[providing from the transmitting computer a data stream] having an assigned data rate, where a data rate is an amount of data per unit of time" | "the speed, as measured in bits per second, at which the data stream is input to the transmitting computer" |
| CONSTRUCTION | |
| "a data stream having a given amount of data per unit of time" |
Apple and Emblaze appear to agree that a "data rate" is an "amount of data per unit of time." Apple argues that this definition should be more specific, and contends that a data rate is a "speed, as measured in bits per second." Emblaze responds that Apple's proposed requirement that "data rate" be measured in bits per second is unsupported by the intrinsic and extrinsic evidence. The court agrees with Emblaze. Apple points to only one sentence in the specification that purportedly supports its construction. In the detailed description of preferred embodiments section of the specification, the'473 patent states that "[a]ssuming that computer 34 communicates over network 28 through a 28.8 Kbaud modem and maintains a typical FTP upload rate of 2 Kbytes/sec (allowing for moderate Internet bottlenecks), data stream 40 will be uploaded to server 36 over link 60 (Fig. 4) substantially at the rate that the audio data are input to computer 34." Apple asserts that because the above passage refers to an upload rate in kilobytes per second, the patent claims should be limited to data rates measured in bits per second. But as discussed earlier in this order, "[t]he patentee is entitled to the full scope of his claims, and [the Federal Circuit] will not limit him to his preferred embodiment or import a limitation from the specification into the claims." Consistent with Federal Circuit case law, this court will not turn one passing mention of a bits per second data rate in the context of a preferred embodiment into a limitation on all of the '473 patent's method claims.
'473 patent, at 11:59-64 (emphasis added).
Kara, 582 F.3d at 1348.
Apple also cites the Microsoft Computer Dictionary's definition of "data rate" as support for its "bits per second" limitation. The Microsoft Computer Dictionary defines "data rate" as "[t]he speed at which a circuit or communications line can transfer information, usually measured in bits per second (bps)." This definition only confirms that the '473 patent's method claims should not be limited to measuring data rate in bits per second—data rate is "usually" measured in bits per second, but not always. Apple finally asserts that Emblaze's construction "is too general, and leaves open the very real possibility that Emblaze will use this general definition (divorced from any actual units of measure) to expand the meaning of 'data rate' beyond the bounds of what is actually contemplated by the '473 patent." However, Apple fails to provide a single example of how Emblaze might expand the meaning of "data rate" beyond the intended scope of the '473 patent. Instead, the court finds that Apple's proposed construction is too narrow. As both parties agree with the general premise that a "data rate" is an "amount of data per unit of time," the court construes "data stream having a given data rate" as "a data stream having a given amount of data per unit of time."
Docket No. 119-6, Handy Decl. Ex. F, Microsoft Computer Dictionary 144 (5th ed. 2002).
Docket No. 118, at 10.
D. Dispute #4: "Slice"
| CLAIM TERM #4 | |
| "slice" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "a segment of the data stream" | "a discrete segment of the data stream that results from the data stream being divided" |
| CONSTRUCTION | |
| "a discrete segment of the data stream" |
Both independent claims of the '473 patent recite "dividing the stream into a sequence of slices." Apple argues that a "slice" is "a discrete segment of the data stream that results from the data stream being divided," but Emblaze contends that a "slice" is simply "a segment of the data stream." The parties' dispute revolves around whether a "segment" of the data stream is a single (or, in Apple's words, "discrete") slice of the data stream, or whether a "segment" of the data stream could contain a group of slices.
'473 patent, claim 1; see '473 patent, claim 25 (reciting "divides the stream into a sequence of slices").
Apple also briefly argues that the construction of "slice" should specify that a "slice" "results from the data stream being divided." However, claims 1 and 25 state that the data stream is divided into a sequence of slices. The court finds the claim language sufficiently clear such that construing "slice" as "a discrete segment of the data stream" captures the '473 patent's usage of the word "slice."
The court agrees with Apple. The '473 patent does not contemplate that a "slice" could contain a group of adjacent slices. Instead, the '473 patent's specification explains that "[d]ata stream 40 comprises a series of data slices 42, 44, 46, 48, etc. Each slice contains a segment of video and/or audio data . . . ." This passage indicates that a data stream is made up of several data slices, but that each slice includes only a single segment of data. Apple cites an excerpt of the specification also supporting this interpretation. Notably, Emblaze cannot point the court to any part of the specification that suggests that a slice can comprise multiple segments of data.
'473 patent, at 7:22-24.
See id. at 2:22-26 ("Preferably, each segment or slice is contained in a separate, respective file. Alternatively, the segments or slices may all be contained in a single indexed file, which is streamed to the client in a series of packets, each covering a range of one or more indices.").
Moreover, allowing "slice" to mean both a single segment of the data stream and multiple segments of the data stream would inappropriately introduce ambiguity into the term where there is none. Under Emblaze's construction, a slice could itself contain several slices. Apple contends that its construction clarifies that a "slice" is a single segment. Emblaze provides no response to this argument other than to assert without warrant that "that 'clarification' is not helpful." The court disagrees. Clarifying that a slice is a discrete segment is necessary to avoid the ambiguity that a slice could itself contain several slices. Therefore, the court construes "slice" to mean "a discrete segment of the data stream."
Docket No. 127, at 6.
E. Dispute #5: Predetermined Data Size of the Slice and Associated Time Duration
| CLAIM TERM #5 | |
| "each slice having a predetermined data size associated therewith" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "each slice having an assigned data size which may be an assigned time duration" | "each slice has an amount of data, measured in bits, that is assigned in advance of the stream being divided" |
| CONSTRUCTION | |
| "each slice having a data size, which may be established by setting a time duration of the slice, assigned in advance of the stream being divided" |
| CLAIM TERM #16 | |
| "wherein divided the stream into the sequence of slices comprises dividing the stream into a sequence of time slices, each having a predetermined duration associated therewith" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "the stream is divided into a sequence of slices, where the predetermined data size of the slices is established by setting the time duration of the slices" | "the stream is divided into a sequence of slices, each slice having an assigned data size and an assigned time duration, with both the data size and the time duration of each slice being assigned in advance of the stream being divided" |
| CONSTRUCTION | |
| "the stream is divided into a sequence of slices, where the predetermined data size of the slices is established by setting the time duration of the slices" |
On claim terms 5 and 16, Apple and Emblaze have the same two disputes: (1) whether "predetermined" means that the data size is determined in advanced of the data stream being divided, and (2) whether the data size can be established by setting a time duration of the slice. The court considers each issue in turn.
First, the court finds that the term "predetermined" requires that the data size of each slice must be assigned in advance of the stream being divided. Under Phillips, the court begins by examining the claim language itself. In independent claims 1 and 25, the word "predetermined" modifies "data size," indicating that the data size must be determined before some other event. The rest of the claim element provides further context: "dividing the stream into a sequence of slices, each slice having a predetermined data size associated therewith; . . . ." If the stream is divided into a sequence of slices, and slices have an associated, predetermined data size, the slice size must be determined before the stream is divided. The plain claim language thus strongly supports Apple's suggestion that the court specify that the data size is "assigned in advance of the stream being divided."
See Phillips, 415 F.3d at 1312-13.
'473 patent, claim 1.
The specification and associated figures bolster this construction. Emblaze cites to a specification passage stating that "[t]he data are compressed at step 80, and are then 'sliced' at step 82 into files 42, 44, 46, 48, etc., as shown in Fig. 3A." According to Emblaze, this excerpt indicates that "slicing" is a single step that includes assigning a data size. However, Figure 7 of the '473 patent, which is a flowchart of the claimed algorithm, depicts step 82 as two separate steps: an initial "set slice duration" step, and a following "prepare slice I" step. Figure 7 and the above specification passage therefore are consistent with the claim language, which makes clear that the slice data size is assigned in advance of the stream being divided.
Id. at 9:66-10:1.
Not including the "I = I + 1" increment step.
Second, the parties contest whether the predetermined data size can be established by setting a time duration of the slice. Emblaze argues that setting a time duration of the slice can result in setting a predetermined data size because the data size can be calculated given a time duration and a data transfer rate. Specifically, at the Markman hearing Emblaze explained:
[I]f we know the given data rate and we're going to have a predetermined data size in that slice, there's a couple of ways to do it, right? One way is if you know the rate, you can set the amount of data and that's going to fix the amount of time of each slice; or you can simply set the duration of the slices. Once you know the data rate, that's going to fix how much data willEmblaze later provided an example: "You can say 'I'm going to slice it for two seconds,' so if it's 100 kilobytes per second and it's a two second slice, I know it's going to be 200 kilobytes." Apple disagrees with Emblaze's interpretation, and instead argues that the data size must be measured in bits.
be in each slice because, again, there's [sic] only three variables in that equation."
Docket No. 181, at 77:18-25.
Id. at 85:14-17.
Again the court begins with the claim language. Claim 1 recites the element of "dividing the stream into a sequence of slices, each slice having a predetermined data size associated therewith." Claim 23, which depends from claim 1, adds the limitation that "dividing the stream into the sequence of slices comprises dividing the stream into a sequence of time slices, each having a predetermined duration associated therewith." Claim 23 therefore introduces a further limitation on the "dividing the stream into a sequence of slices" element: that the slices are time slices having a predetermined duration. Based on this claim language and the rule that dependent claims are narrower than independent claims, the "predetermined data size" should encompass the possibility that a time duration could be considered a "data size" within the scope of claim 1. The court recognizes that there is an alternate explanation for the language of claims 1 and 23—it could also be interpreted as requiring that each slice have both a predetermined bit size and a predetermined time duration—but the court finds this alternate interpretation inferior. The invented algorithm requires a decision rule instructing it where to divide the data stream. The '473 patent's specification does not disclose an embodiment of the invention in which the algorithm divides the data stream into slices based on both a bit size and a time duration. As will be detailed below, the specification consistently describes the dividing step as being based on either a bit size or a time duration, but not both. This observation is consistent with the '473 patent's teaching that data rate may vary over the course of the broadcast. If the data rate varies over the course of the broadcast, dividing the data stream based on both a predetermined bit size and a predetermined time duration would force these decision rules to conflict. Therefore, claim 1 encompasses two ways of predetermining data size—setting a bit size and setting a time duration—and claim 23 excludes the bit size embodiment of the invention.
See AK Steel Corp. v. Sollac & Ugine, 344 F.3d 1234, 1242 (Fed. Cir. 2003) ("Under the doctrine of claim differentiation, dependent claims are presumed to be of narrower scope than the independent claims from which they depend.").
See '473 patent, at 9:31-47.
The specification further confirms that the ability to predetermine a data size based on a set time duration is a prominent feature of the invention that should be encompassed by claim 1. For example, the summary of the invention section teaches that "[t]he data stream is divided into a sequence of segments or slices of the data, preferably time slices, wherein the data are preferably compressed." In the briefing, "Apple agrees that a predetermined data size might ultimately 'correspond' to a time duration"—a notion strongly supported by the specification—but Apple argues that this correspondence "does not mean that 'data size' and 'time duration' are the same parameter." However, as described above, Emblaze does not assert that "data size" and "time duration" are the same. Rather, Emblaze explained at the Markman hearing that the data size can be calculated by setting a time duration. It is in this sense that data size "corresponds" to a time duration. Therefore, based on the claim language and the specification, the court finds that the data size may be established by setting a time duration of the slice. Consequently, the court construes "each slice having a predetermined data size associated therewith" to mean "each slice having a data size, which may be established by setting a time duration of the slice, assigned in advance of the stream being divided."
Id. at 2:4-6.
Docket No. 118, at 13.
'473 patent, at 5:34-35, 7:23-25, 9:33-35.
Docket No. 118, at 12.
Disputed claim term #16 is the claim language from claim 23 discussed throughout this section. The parties' disagreement as to claim term #16 is resolved by the above analysis. Accordingly, the court construes "wherein divided the stream into the sequence of slices comprises dividing the stream into a sequence of time slices, each having a predetermined duration associated therewith" to mean "the stream is divided into a sequence of slices, where the predetermined data size of the slices is established by setting the time duration of the slices."
F. Dispute #6: Encoding
| CLAIM TERM #6 | |
| "encoding the slices in a corresponding sequence of files" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "forming each slice as a file, wherein a file includes data from a corresponding slice and a file descriptor, and wherein the sequence of files corresponds to the sequence of slices" | "compressing each slice and saving each compressed slice as a file after the dividing step" |
| CONSTRUCTION | |
| "forming each slice as a file, wherein a file includes compressed data from the slice and a file descriptor, and wherein the sequence of files corresponds to the sequence of slices" |
| CLAIM TERM #10 | |
| "decode the sequence" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "retrieving at least a portion of the data stream from the downloaded file" | "decompress the files in the sequence" |
| CONSTRUCTION | |
| "decompressing any compressed data in the sequence" |
| CLAIM TERM #14 | |
| "encoding slices at a different plurality of different quality levels" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "forming slices at more than one quality level" | "compressing each slice at two or more different compression levels" |
| CONSTRUCTION | |
| "forming slices at more than one quality level" |
The parties dispute whether the encoding step includes compressing the data. The court finds that compression is a necessary aspect of the invention, and that data in the encoded files is compressed data.
The background of the invention section of the '473 patent's specification explains that compression is required "[b]ecause of bandwidth limitations of the network." The invention does not lift the bandwidth limitations of the network, but is instead directed principally at eliminating the need for high-cost, special purpose broadcast computer equipment. The specification confirms that the slice data must be compressed. For example, the specification repeatedly refers to the "set compression ratio" and "compress data" steps in Figure 7 as "encoding." In addition, nearly every time the specification describes "encoding," compression or a "quality level" (which necessarily involves compression) is also discussed.
'473 patent, at 1:29-33 ("Because of bandwidth limitations of the network, the data stream from host 22 must first be compressed by a real-time encoder 24 and then routed to appropriate clients 30 by a broadcast server 26 (since not all clients on the network are necessarily intended to receive the broadcast).").
See id. at 1:34-2:21.
Id. at 11:23-24 ("Fig. 7 is a flow chart that schematically illustrates details of encoding step 80 . . . ."), 10:19-22 ("Alternatively or additionally, the encoding/quality level (step 80) or slicing (step 82) of the data may be adjusted, as described hereinbelow with reference to Fig. 7."), 13:23-26 ("The process shown in FIG. 5, including the interdependent steps of encoding 80, slicing 82, FTP upload 84, updating 86 and checking link function 88 thus continues until the entire data stream 40 is uploaded . . . .").
See, e.g., id. at 3:45-48 ("Further preferably, encoding the stream includes compressing data in the stream at a desired compression ratio, and adjusting the upload rate includes changing the compression ratio."), 4:39-43 ("In still another preferred embodiment, encoding the slices includes encoding slices at a plurality of different quality levels, such that the files corresponding to a given one of the slices have a different, respective data size for each of the quality levels."), 11:26-31 ("In encoding data stream 40, computer 34 preferably compresses the data using any suitable compression method known in the art. For example, if data stream 40 comprises audio data, GSM 6.10 standard encoding may be used, as is known in the art, to compress the data by about 10:1.").
Emblaze cites to one sentence of the specification, which reads, "[p]referably, the data in the sequence are compressed, although compression is not essential to implementation of the present invention." However, the claims govern the scope of the intellectual property right. While this excerpt states that compression is not essential to the invention, "encoding" is a limitation in every claim of the '437 patent. As outlined above, the specification consistently refers to compression as "encoding," and in at least seven different places the '473 patent explains that encoding includes compressing data. Consequently, compression may not be essential to the implementation of the invention, but it is required by every claim.
Id. at 6:54-56.
Phillips, 415 F.3d at 1312 ("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.") (internal quotation omitted).
See supra notes 77, 79, 80.
Emblaze also makes a claim differentiation argument, contending that a compression element is added only in claim 16. Claim 1 recites the step of "encoding the slices in a corresponding sequence of files, each file having a respective index." Claim 15 depends from claim 1 and adds a limitation irrelevant to the present dispute. Claim 16 in turn depends from claim 15. Claim 16 recites "[a] method according to claim 15, wherein encoding the stream comprises compressing data in the stream at a desired compression ratio, and wherein adjusting the upload rate comprises changing the compression ratio." Emblaze argues that "'encoding' is used in two different contexts in the claims of the '473 patent": "encoding the slice" (claim 1), and "encoding the stream" (claim 16). Apple responds that "encoding the slice" and "encoding the stream" are used interchangeably throughout the '473 patent, and that "[c]laim 16 may fairly be read as only adding the requirement of a particular 'desired compression ratio' (as opposed to, for example, variable rate compression) and not the step of compression itself."
Docket No. 111, at 14.
Docket No. 118, at 15.
Apple has the better argument. The '473 patent throughout the specification uses the terms "encoding the slice" and "encoding the stream" interchangeably. Claim 16 only adds an additional limitation onto the same encoding recited by claim 1. At best for Emblaze, it is ambiguous whether that limitation is an entirely new compressing step, or whether that limitation merely specifies the use of "a desired compression ratio." As a result, Emblaze's claim differentiation argument cannot overcome the clear specification teaching that compressing is an element of claim 1.
See, e.g., 3:45-48 ("Further preferably, encoding the stream includes compressing data in the stream at a desired compression ratio, and adjusting the upload rate includes changing the compression ratio."), 4:39-43 ("In still another preferred embodiment, encoding the slices includes encoding slices at a plurality of different quality levels, such that the files corresponding to a given one of the slices have a different, respective data size for each of the quality levels.").
Other than the omission of a compressing step, the court finds Emblaze's proposed construction more descriptive and consistent with the specification than Apple's proposed construction. Therefore, the court modifies Emblaze's proposed instruction to specify that the data formed into a file is compressed. "Encoding the slices in a corresponding sequence of files" is construed as "forming each slice as a file, wherein a file includes compressed data from the slice and a file descriptor, and wherein the sequence of files corresponds to the sequence of slices."
Having resolved the dispute between the parties in the construction of "encoding the slices in a corresponding sequence of files," constructions for related claim terms #10 and #14 follow naturally. The court thus construes "decode the sequence" to mean "decompressing any compressed data in the sequence," and "encoding slices at a different plurality of different quality levels" to mean "forming slices at more than one quality level."
G. Dispute #7: Indexing
| CLAIM TERM #7 | |
| "sequence of files, each file having a respective index" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "a sequence of files, wherein each file has an indicator that distinguishes the file from other files" | "a sequence of files, wherein each file contains an alphanumeric indicator stored therein that represents a respective slice's location in the sequence" |
| CONSTRUCTION | |
| "sequence of files, wherein each file has an indicator that represents a respective slice's location in the sequence" |
| CLAIM TERM #11 | |
| "play back the data stream responsive to the indices of the files" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "playing back the data stream based on the indices of the files to be played back" | "play back the data stream in the order of the indices by reading the index contained in each file" |
| CONSTRUCTION | |
| "playing back the data stream based on the indices of the files to be played back" |
| CLAIM TERM #13 | |
| "uploading and updating an index file containing the index of the file in the sequence that was most recently uploaded" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "uploading to a server an index file, and updating the index file with the index of the most recently uploaded file" | "uploading to the server a file that contains a single alphanumeric index variable and changing the variable to equal the index of the most recently uploaded file" |
| CONSTRUCTION | |
| "uploading to a server an index file, and updating the index file with the index of the most recently uploaded file" |
Two disagreements are at the heart of disputed claim terms 7, 11, and 13: (1) whether the index merely distinguishes the file from other files, or whether it represents a respective slice's location in the sequence, and (2) whether the "index" must be "alphanumeric." Apple and Emblaze cite the same specification passages and agree that the specification resolves these claim term disputes.
First, the '473 patent teaches that the purpose of the index is to represent a respective slice's location in the sequence. Claim 1 itself refers to a "sequence of files," with "each file having a respective index." This sequence is not independent from the index—rather, the index is used to identify a slice's order in the sequence: "The symbols J, J + 1, J + 2, . . . N in the figure are the indices of the slices of stream 40 that are stored on server 36, wherein N is the index of the most recent slice, and J is the index of the earliest stored slice." Furthermore, "[w]hen one of computers 30 connects to server 36 and begins to download the data stream, it first reads the index file in order to identify at what point in stream 40 to begin and to start receiving the data stream substantially in real time . . . ." The index must indicate where in the stream the slice is located, so that during playback the client device can download the data in the correct order. As such, Emblaze's proposed construction—which requires that the index only distinguish each file from the other files—is not sufficiently descriptive. The index represents a respective slice's location in the sequence.
'473 patent, at 8:23-26.
Id. at 8:1-5.
Second, the specification only provides examples of indices with alphanumeric characters. For instance, the '473 patent teaches that "[c]omputer 34 stores each slice as a corresponding file, having a running slice index 1, 2, 3 . . . N." "Preferably, ID 52 holds the file name of the new file, wherein the name typically comprises a string followed by the index of the file." Other excerpts explain the operation of an "index" similarly. However, Apple can point to no evidence indicating that the claim term "index" should be limited to the preferred embodiments disclosed in the specification. The plain meaning of "index" is versatile, so other types of data could perform the index's function of representing a respective slice's location in the sequence. Even though the specification only discloses alphanumeric examples of an index, and even though such an index is likely the most efficient implementation of the invention, the court will not limit the construction of "index" to just the disclosed embodiments. Accordingly, the court adopts a portion of each party's proposed construction and construes "sequence of files, each file having a respective index" as "sequence of files, wherein each file has an indicator that represents a respective slice's location in the sequence."
Id. at 7:27-28.
Id. at 7:66-8:1. Note that in computer science, a string is typically a data type comprised of a sequence of characters.
See, e.g., id. at 7:59-64, 8:1-5, 8:23-26.
See Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 906 (Fed. Cir. 2004) ("Even when the specification describes only a single embodiment, the claims of the patent will not be read restrictively unless the patentee has demonstrated a clear intention to limit the claim scope using words or expressions of manifest exclusion or restriction.").
The above analysis also resolves the parties' disputes as to claim terms 11 and 13. The court specifies that the index reflects the slice's location in the sequence. Consequently, Emblaze's proposed construction that "play back the data stream responsive to the indices of the files" means "playing back the data stream based on the indices of the files to be played back" sufficiently communicates that the files are played back in the order given by the indices. As to claim 13, given that the court rejected Apple's argument that "index" should be limited to alphanumeric indicators, the court can adopt Emblaze's proposed construction. Therefore, the court construes "uploading and updating an index file containing the index of the file in the sequence that was most recently uploaded" to mean "uploading to a server an index file, and updating the index file with the index of the most recently uploaded file."
H. Dispute #8: Generally equal to the data rate of the stream (terms 8, 9, 12)
| CLAIM TERM #8 | |
| "uploading the sequence to a server at an upload rate generally equal to the data rate of the stream" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "uploading files in the sequence from the transmitting computer to a server at an upload rate generally equal to the data rate of the stream" | "transmitting the files from the transmitting computer to the server at a speed, as measured in bits per second, that closely matches 'the data rate' [as defined in Apple's Term #3 above]" |
| CONSTRUCTION | |
| "transmitting the files from the transmitting computer to the server at an upload rate generally equal to the data rate of the stream" |
| CLAIM TERM #9 | |
| "such that one or more client computers can download the sequence over the network from the server at a download rate generally equal to the data rate" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "one or more client computers are capable of selecting individual files corresponding to the slices for download over the network at a download rate generally equal to the data rate" | "each client receiving the broadcast requests and receives each file of the sequence from the server at a transmission speed, as measured in bits per second, that closely matches 'the data rate' [as defined in Apple's Term #3 above]" |
| CONSTRUCTION | |
| "such that one or more client computers are able to select individual files corresponding to the slices for download over the network at a download rate generally equal to the data rate" |
| CLAIM TERM #12 | |
| "at a replay rate generally equal to the data rate" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "the rate at which the client plays back the data stream is generally equal to the data rate of the stream" | "the speed the client computer plays back the downloaded slices, as measured in bits per second, closely matches 'the data rate' [as defined in Apple's Term #3 above]" |
| CONSTRUCTION | |
| "the rate at which the client plays back the data stream is generally equal to the data rate of the stream" |
The court next turns to Apple and Emblaze's disagreement as to the meaning of "generally equal to the data rate of the stream." This term appears in disputed claim terms 8, 9, and 12, and it presents the same issues in each term. In particular, the parties especially contest the meaning of "data rate of the stream" and "generally equal." The court considers these issues in turn.
The term "a given data rate" is the antecedent basis for "data rate of the stream." Apple argues that the construction of "a given data rate" in claim term #3 controls the court's construction of "data rate of the stream." However, the court rejected Apple's construction of "a given data rate" in the section on claim term #3, finding that nothing in the specification requires that the data rate be expressed in bits per second. Accordingly, the court need not provide further construction of the term "data rate."
See supra Section III.C.
Apple next contends that the court should construe "generally equal" to mean "closely matches." Apple does not explain how substituting "closely matches" for "generally equal" provides any further clarification of the claim term. Instead, Apple asserts that its interpretation is supported by the specification and the dictionary definition of "real-time." The court finds Apple's position unpersuasive. Notably, Apple cites to no source that uses Apple's proposed "closely matches" language. Apple directs the court to specification excerpts that refer to "upload[ing] the sequence of slices to the server substantially in real time . . . ." and "monitor[ing] the time codes as the file is received, in order to ensure that the transmission or reception is 'keeping up' with the input of data to the computer." These passages, along with all others cited by Apple, express only the concept of real-time broadcasting, which the court construed above. Apple's reference to the dictionary definition of real-time similarly is most relevant to the court's construction of "real-time broadcasting." As described by Emblaze, "[t]he ordinary meaning of 'generally equal' is clear—it means approximately, but not necessarily exactly, equal." "Generally equal" is a common phrase easily understood by persons of ordinary skill in the art and the reasonable juror. Further, neither the intrinsic evidence nor extrinsic evidence suggest that the '473 patent's use of "generally equal" deviates in any way from the term's ordinary meaning. Therefore, the court provides no further construction of "generally equal."
'473 patent, at 2:8-9.
Id. at 7:37-39.
See supra Section III.A.
Docket No. 111, at 17.
Finally, although the parties do not argue over the significance of the language, the court finds Apple's proposed "transmitting the files from the transmitting computer" language to be helpful in clarifying the "uploading" step. The court thus construes "uploading the sequence to a server at an upload rate generally equal to the data rate of the stream" to mean "transmitting the files from the transmitting computer to the server at an upload rate generally equal to the data rate of the stream." The above discussion also resolves the parties' disputes with respect to claim term #12. As such, the court construes "at a replay rate generally equal to the data rate" to mean "the rate at which the client plays back the data stream is generally equal to the data rate of the stream."
As to claim term #9, Apple makes the additional argument that the "such that" clause requires that the client computers actually download the sequence, and not that clients just have the ability to download the sequence, as proposed by Emblaze. Beginning with the claim language, the court observes that the claim recites "uploading the sequence . . . such that one or more client computers can download the sequence . . . ." The word "can" in the claim explicitly requires only the ability to download the sequence, not actual downloading. Apple does not point to anything in the specification indicating that a third party client must download the data for the method to be completed. In fact, the first sentence of the summary of the invention section of the '473 patent states that "[i]t is an object of some aspects of the present invention to provide substantially continuous, high-bandwidth data streaming over a network using common, existing server and network infrastructure." The '473 patent thus discloses that the invention is principally directed toward providers of the data stream and not clients. Apple contends that Hoffer v. Microsoft Corp. holds that a "whereas" or "such that" clause requires more than capability. However, the issue in Hoffer was whether a "whereas" clause limited the claim at all—not whether actual performance of the "whereas" clause by a third party was required. In Hoffer, both parties and the court agreed that if the "whereas" clause was limiting, only capability was required. As such, in this case the express claim language governs, and the court construes "such that one or more client computers can download the sequence over the network from the server at a download rate generally equal to the data rate" to mean "such that one or more client computers are able to select individual files corresponding to the slices for download over the network at a download rate generally equal to the data rate."
'473 patent, claim 1 (emphasis added).
Id. at 1:50-53 (emphasis added).
See 405 F.3d 1326 (Fed. Cir. 2005).
See Hoffer, 405 F.3d at 1329-30.
See id. at 1330.
I. Dispute #9: Bandwidth (term 15)
| CLAIM TERM #15 | |
| "determining a data bandwidth of the network between the server and the client computer" | |
| Emblaze's Preferred Construction | Apple's Preferred Construction |
| "the client determines a data rate at which a client can download a file from the server" | "the client measures the data transfer capacity, in bits per second, of the network connection between the server to which the sequence of files is uploaded and the client computer operated by the user requesting the download" |
| CONSTRUCTION | |
| "the client determines a data rate at which a | client can download a file from the server" |
Apple uses the word "bandwidth" in claim term #15 as another vehicle to insert a "bits per second" limitation into the claim. Apple's argument—the entirety of which encompasses only one short paragraph of briefing—points to a sole dictionary definition of "bandwidth" as support. Specifically, the Microsoft Computer Dictionary defines bandwidth as "[t]he data transfer capacity, or speed of transmission, of a digital communications system as measured in bits per second (bps)." As detailed above, nothing in the '473 patent's specification indicates that any data rate must be measured in bits per second. The court thus construes "determining a data bandwidth of the network between the server and the client computer" to mean "the client determines a data rate at which a client can download a file from the server."
Docket No. 119-6, Handy Decl. Ex. F, Microsoft Computer Dictionary 50 (5th ed. 2002).
See supra Section III.C.
--------
IT IS SO ORDERED.
Dated: October 9, 2014
/s/_________
PAUL S. GREWAL
United States Magistrate Judge