Emblaze Ltd. v. Microsoft Corporation

Filing 93

CLAIM CONSTRUCTION ORDER. Signed by Judge Jon S. Tigar on July 29, 2014. (wsn, COURT STAFF) (Filed on 7/29/2014)

1
2
3
4

UNITED STATES DISTRICT COURT

5

NORTHERN DISTRICT OF CALIFORNIA

6
7

EMBLAZE LTD.,

Case No. 12-cv-05422-JST

Plaintiff,
8
v.

CLAIM CONSTRUCTION ORDER

9
10

MICROSOFT CORPORATION,

Re: ECF No. 52

Defendant.

United States District Court
Northern District of California

11
12

In this patent infringement action involving technology for streaming files over a network

13

in real-time, the parties seek construction of several terms used in U.S. Patent No. 6,389,473 (“the

14

patent-in-suit” or “the ’473 patent”).

15

I.

BACKGROUND

16

A.

17

Emblaze Ltd. alleges that Microsoft infringes the ’473 patent by manufacturing, selling,

18

and/or offering to sell products for streaming media in real-time over the internet. Compl. ¶ 17.

19

The following chart identifies the patent-in-suit and the remaining asserted claims:

20

Patent-in-Suit and Remaining Asserted Claims

Patent

Claims

21

22

U.S. Patent No. 6,389,473

1, 2, 8, 9, 10, 11, 12, 13, 14, 25, 23, 25, 26, 27,
29, 37, 40

23
The ’473 Patent

24

B.

25

The invention claimed in the ’473 patent enables the real-time, continuous streaming of

26

data over a network without the use of special servers, software, or network infrastructures. The

27

invention achieves this by requiring the transmitting computer to divide the data stream into slices

28

of a predetermined size and to include an index with each slice that contains information

1

pertaining to the proper synchronization of the slices. The transmitting computer uploads the

2

sequence of slices to a server in real-time, and clients download the data stream from the server

3

and use the information in the indices to ensure that the slices are played in the correct order.

4

To ensure that the transmission of data is in real-time, the claims require that the data

5

transfer rate and the playback rate be at least as fast as the rate at which the transmitting computer

6

can generate the data. For this reason, either the transmitting computer or the server must monitor

7

the data transfer rate to determine the appropriate rate of transfer in light of the available

8

bandwidth. Some preferred embodiments also contemplate compressing the data in each slice or

9

altering the size of each slice depending on the available bandwidth.

10

Yet other preferred embodiments involve opening a plurality of transfer links between the

United States District Court
Northern District of California

11

transmitting computer and the server and uploading different slices in the sequence over the

12

various links so long as the total data rate of the links is sufficient to enable uploading the

13

sequence of slices as the same rate as the data is generated. The client downloading the data also

14

can access these multiple links to download the data at the data rate. When a link has a data

15

transfer rate that is lower than the predetermined level, then the transmission over this link can be

16

stopped so that a new link with a better transmission rate can be opened.

17

Another embodiment permits including in a data stream multiple versions of each slice,

18

each with a different quality level. The client selects or is assigned the quality level that is most

19

appropriate in light of the available bandwidth when downloading the stream.

20

In some preferred embodiments, the client reads an index file, which contains the file name

21

of the last slice that was uploaded to the server. The user using the client computer can then

22

decide the appropriate point in the stream at which to begin downloading. This can be

23

accomplished through the use of a slider in the playback program used by the client.

24

Prior methods for broadcasting in real-time known in the art require the compression of the

25

data stream by a dedicated encoder and the broadcasting of data to clients by a broadcast server.

26

The encoders and broadcast servers required by these prior methods are costly and therefore

27

typically cannot be offered by internet service providers to their general customers. The present

28

invention thus improves upon these prior methods by permitting the real-time broadcasting of data
2

1

without special or high-cost encoders or servers.

2

II.

LEGAL STANDARD

3

The construction of patent claim terms is a matter of law for the court. Markman v.

4

Westview Instruments, Inc., 517 U.S. 370, 372 (1996). A “bedrock principle” of patent law is that

5

“the claims of a patent define the invention to which the patentee is entitled the right to exclude.”

6

Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc). In construing a term, the

7

“objective baseline” is the “ordinary and customary meaning,” which is “the meaning that the term

8

would have to a person of ordinary skill in the art in question at the time of the invention[.]” Id. at

9

1313. “[T]he person of ordinary skill in the art is deemed to read the claim term not only in the
context of the particular claim in which the disputed term appears, but in the context of the entire

11
United States District Court
Northern District of California

10

patent, including the specification” and the prosecution history. Id.
The “primary basis for construing [a] claim” and “the best source for understanding a

12
13

technical term” is a patent’s intrinsic evidence. Id. at 1314. Intrinsic evidence includes the patent

14

and its file history, including any reexaminations and reissues, related patents and their

15

prosecution histories, and the prior art that is cited or incorporated by reference in the patent‐in‐

16

suit and prosecution history. Id. Extrinsic evidence refers to all other types of evidence, including

17

inventor testimony, expert testimony, documentary evidence of how the patentee and alleged

18

infringer have used the claim terms, dictionaries, treatises, and other similar sources. Id. at 1318.

19

Intrinsic evidence trumps any extrinsic evidence that would contradict it. Id. at 1314.

20

III.

21

DISCUSSION
A.

“file” / “files” (Term 1)

22
23
24
25

Terms
“file” / “files”
(claims 1, 8, 9,
10, 11, 25, 40)

Emblaze’s proposed construction
Does not need construction.
Alternatively: “a slice of data that
has a file descriptor.”

Microsoft’s proposed construction
“the collection of data stored in a
directory and accessed by a file name
for editing and saving”

26
27

The parties’ dispute with respect to this term is over (1) whether “file” should be construed

28
3

1

at all; and if it is construed, (2) whether “file” should be treated as being synonymous with “slice,”

2

and (3) whether “file name” should be used in the construction.

3

The court adopts the following construction: “an item containing a single slice of data

4

that has an identifier that is recognizable by a file system.” This construction reflects the

5

specification’s description of a file as the item that contains a single slice of data. ’473 patent col.

6

2 ll. 22-27 (“Preferably, each segment or slice is contained in a separate, respective file.”). It also

7

reflects the specification’s description of a slice as containing identifiers, including a level

8

identifier, a presentation time stamp, and a size identifier. Id. col. 8 ll. 47-51 (“Each slice is

9

preferably identified by a level identifier 57, a presentation time stamp (PTS) index 59 and, as
appropriate, a size identifier.”). Emblaze proposed the phrase “that is recognizable by a file

11
United States District Court
Northern District of California

10

system” during oral argument. The court finds that the use of this phrase is appropriate in light of

12

Microsoft’s own definition of a file system as “the overall structure in which files are named,

13

stored, and organized. A file system consists of files, directories, or folders, and the information

14

needed to locate and access those items . . . .”). See Resp. Br. at 7 (citing the Microsoft Computer

15

Dictionary, Ex. C at 213).

16

The term “descriptor” is not used in the specification, and for that reason, the court finds

17

that its use in construing the term at issue could result in jury confusion. Additionally, the court is

18

not persuaded that the term “file” is used as a synonym for “slice” in the specification. As

19

discussed above, the specification describes a file as containing a slice, and not as being a slice.

20

Microsoft’s proposed construction seeks to add limitations to the term that are not required

21

by the claims or the specification, such as “stored in a directory,” “accessed by a file name,” and

22

“for editing and saving.” Accordingly, this construction is improperly narrow.

23

The parties dispute whether a “file” can contain all of the slices of a data stream as

24

opposed to just a single slice based on the following preferred embodiment: “Alternatively, the

25

segments or slices may all be contained in a single indexed file, which is streamed to the client in a

26

series of packets, each covering a range of one or more indices.” ’473 patent col. 2 ll. 22-27.

27

Microsoft contends that this embodiment is not covered by the claims. The court agrees. The

28

claims containing the term at issue expressly claim a “sequence of files” that correspond to the
4

1

“sequence of slices” (plural). These claims therefore do not cover the embodiment in which all of

2

the slices are “contained in a single indexed file.”

3

B.

“data rate” (Term 2)

4
5
6
7
8
9
10

Emblaze’s proposed construction

Term
“data rate” (claims
1, 8, 25, 26)

“an amount of data per unit of
time”

Microsoft’s proposed construction
“an amount of data (i.e. number of
bits) per unit of time”

The parties agree that this term involves an “amount of data” per unit of time, but
Microsoft contends that the amount of data should be defined as a “bit.” Microsoft notes that two
dictionaries define data rate as being “usually measured in bits per second (bps).” Resp. Br. at 10.

11
United States District Court
Northern District of California

Microsoft also notes that Emblaze itself argued in another case involving the same patent that data
12
13
14

rate as contemplated by the ’473 patent is measured in bits. Id., Ex. H at 62:17–63:7, 77:17–25.
The court adopts Microsoft’s proposed construction. The ’473 patent consistently
refers to “data rate” in the context of available bandwidth, and here, no party disputes that

15
bandwidth is measured in bits per second. See Resp. Br., Ex. C at 144. Additionally, the claims at
16
issue require comparing the upload data rate with the stream data rate, but this can be
17
accomplished only if the rate is measured in bits as opposed to other units of measurement such as
18

frames. See, e.g., ’473 patent col. 14 ll. 28–29. This is because bits have a consistent volumetric

19
value, whereas frames do not.
20
21

C.

“a data stream having a given data rate” (Term 3)

22
23
24
25
26

Term
“a data stream
having a given
data rate” (claims
1, 25)

Emblaze’s proposed construction
“a data stream having a given
amount of data per unit of time”

Microsoft’s proposed construction
“a data sequence with a uniform
data rate”

27
28

The parties’ dispute with respect to this term centers on the meaning of the word “given.”
5

1

Emblaze contends that “given” means “assigned” or “specified.” In its responsive brief, Microsoft

2

agrees with this characterization of “given” and urges the court to use either “assigned” or

3

“specified” in its construction instead of “given.” Resp. Br. at 12. Microsoft argues, however,

4

that the modifier “uniform” also must be included in the construction because the “density (rate)

5

of the compressed data must be uniform.” Resp. Br. at 12. Microsoft bases this argument on the

6

representations that Emblaze made to Judge Grewal in another case involving the same patent.
Because the patent is devoid of any mention “uniform” data rates or of data “density,” the

8

court declines to adopt the extraneous limitation “uniform” in its construction. Accordingly, the

9

court construes the term at issue as “a data stream having an assigned data rate.” The

10

claims in which the term at issue appears make clear that the upload and download rates must

11
United States District Court
Northern District of California

7

equal the assigned data rate of the data stream, which both parties agree is a critical aspect of the

12

invention. In light of this claim language, no further clarification is necessary in the construction

13

of the term at issue.

14

D.

“providing at the transmitting computer a data stream” (Term 4)

15
16
17
18
19
20

Term
“providing at the
transmitting
computer a data
stream [having a
given data rate]”
(claim 1)

Emblaze’s proposed construction

Microsoft’s proposed construction

“the transmitting computer provides “the transmitting computer provides a
a data stream having a given
data stream for slicing” [having a
amount of data per unit of time”
given data rate]”

21
The parties agree that the term at issue requires the transmitting computer to provide a data

22
23
24
25
26
27

stream, but they disagree as to whether a purpose must be associated with the “providing.”
Microsoft contends that the purpose of “providing” a data stream is to enable the slicing of the
data stream, because the “providing” of the data stream always comes before the step of
“dividing” the data stream.
The court concludes that nothing in the patent limits “providing” to the purpose of
“slicing,” but the court nevertheless finds that it would be appropriate to indicate that the

28
6

1

“providing” step comes before the “dividing” step. See E-Pass Technologies, Inc. v. 3Com Corp.,

2

473 F.3d 1213, 1222 (Fed. Cir. 2007) (“Substantively, because the language of most of the steps

3

of its method claim refer to the completed results of the prior step, . . . all of those steps [must be]

4

performed in order”). Accordingly, the court construes the term at issue as “before slicing, the

5

transmitting computer provides a data stream.”

6

//

7

E.

“predetermined data size” (Terms 5 & 6)

8
9

Terms

Emblaze’s proposed construction

Microsoft’s proposed construction

10

“each slice having
a predetermined
data size
associated
therewith” (claims
1, 25)

“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”

“each slice having a data size (i.e.
number of bits) assigned in advance of
the slice being encoded.” (A slice’s
data size may be assigned by
assigning a time duration that would
necessarily produce a slice of a certain
data size given the data rate of the
stream.)

“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” (claim
23)

“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, where the predetermined
data size of a slice is established by
assigning a time duration that would
necessarily produce a slice of a certain
data size given the data rate of the
stream”

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21

22
23
24
25
26

“wherein the
predetermined data
size of each of the
slices corresponds
to a time duration
of the slice” (claim
37)

27
28

The court adopts Emblaze’s proposed constructions, because they are consistent with
7

1

the specification’s teaching that the size of each slice may be based on time. See, e.g., ’473 Patent

2

col. 2 ll 4-5) (“The data stream is divided into a sequence of segments or slices of the data,

3

preferably time slices . . .”); id. col. 3 ll. 40-43 (“Preferably, dividing the stream into the sequence

4

of slices includes dividing the stream into a sequence of time slices, each having a predetermined

5

duration associated therewith.”).

6

Microsoft’s construction unjustifiably limits the terms at issue to a “number of bits.”

7

Microsoft also asks the court to tie the term at issue with the “encoding” of each slice. Because

8

the “encoding” portion of the method is addressed in the next part of the claims in which the terms

9

at issue appear, the inclusion of language pertaining to “encoding” is unnecessary.

10

F.

“encoding the slices” (Terms 7, 8 & 9)

United States District Court
Northern District of California

11
12
13
14
15
16
17
18

Term 7
“encoding the
slices in a
corresponding
sequence of files”
(claim 1)

Emblaze’s proposed construction

Microsoft’s proposed 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”

“compressing the data from each slice
and saving the compressed data from
each slice into a file corresponding to
that one slice”

“encodes the slices
in a corresponding
sequence of files”
(claim 25)

19
20
21

22

The parties’ dispute with respect to this term is based on whether “encoding” requires
“compressing.” Microsoft argues that it does, and Emblaze argues that it does not.
The specification describes encoding as involving compression only in certain preferred

23

embodiments. See, e.g., id. col. 11 ll. 26–28 (“In encoding data stream 40, computer 34 preferably

24

compresses the data using any suitable compression method known in the art.”) (emphasis added).

25

Because nothing in the claims that contain the term at issue limits “encoding” to “compressing” in

26

all circumstances, particularly with respect to slices, Microsoft’s proposed construction must be

27

rejected.

28

Accordingly, the court adopts the following modified version of Emblaze’s proposed
8

1

construction: “forming each slice as a file in a corresponding sequence of files, wherein the

2

sequence of files corresponds to the sequence of slices.”

3

Term 8

4

“encoding slices in
a plurality of
different quality
levels” (claim 11)

5
6
7
8
9

United States District Court
Northern District of California

12
13
14

“forming slices at more than one
quality level”

Microsoft’s proposed construction
“compressing the slices from the data
stream at more than one quality level”

“slices are encoded
at a plurality of
different quality
levels” (claim 40)

10
11

Emblaze’s proposed construction

The dispute over this term also is based on Microsoft’s proposed use of “compressing” as a
synonym for “encoding.” The court rejects Microsoft’s proposed construction for the same
reasons described above in connection with Term 7, and it thus adopts the following modified
version of Emblaze’s proposed construction: “forming each slice at more than one quality
level.”

15
16

Term 9

Emblaze’s proposed construction

Microsoft’s proposed construction

17
18
19

“decode the
sequence” (claims
8, 26)

20
21

22
23
24
25
26
27

“decompressing any compressed
data in the sequence”

“decompressing compressed data
in the sequence”

The parties dispute the inclusion of the word “any” in the construction of the term at issue.
Microsoft’s construction omits this word, but its brief does not provide any justification for doing
so.
The court concludes that “any” must be included in the construction, because the
specification teaches that the invention can decode or decompress portions of the compressed data
in the sequence but it does not necessarily require the decoding or decompression of all of the
compressed data. See, e.g., Figure 6B & ’473 patent col. 10 ll. 64–68 & col. 11 l. 8
(decompressing only one quality level in a multi-level sequence).

28
9

1

Accordingly, the court adopts Emblaze’s proposed construction.

2

G.

“each file having a respective index” (Term 10)

3
4

Term

Emblaze’s proposed construction

5

“sequence of files,
each file having a
respective index”
(claims 1, 25)

“sequence of files, wherein each
file has an indicator that represents
a respective slice’s location in the
sequence”

6
7
8
9
10

United States District Court
Northern District of California

11

14
15

indicator that represents the slice location in the sequence. The parties disagree as to whether the
indicator must be an index and whether the index should be further defined as “a running slice
index 1, 2, 3 … N.”
The court adopts a modified version of Emblaze’s proposed construction, namely
“sequence of files, wherein each file has an index that represents a respective slice’s location
in the sequence.” This construction tracks the specification’s description of the index as the item
that permits each file to be read and played in the correct order. Id. col 7 ll 18-34.

16
17

Emblaze’s proposed construction uses the term “indicator” as a synonym for “index,” but
this is not supported by the specification.

18
19
20
21

22
23
24
25
26
27

“sequence of files, wherein each file
has an index from a running slice
index 1, 2, 3 … N indicating its
location in the sequence”

Both parties agree that this term involves a sequence of files, and that each file has an

12
13

Microsoft’s proposed construction

Though Microsoft is correct that the term “index” is further described in the patent as
“index 1, 2, 3 . . . N,” the court declines to adopt this additional description in the construction
because it could result in jury confusion.
///
///
///
///
///
///
///

28
10

H.

1

“uploading the sequence” (Term 11)

2
3

Terms

Emblaze’s proposed construction

Microsoft’s proposed construction

4

“uploading the
sequence to a
server at an upload
rate generally
equal to the data
rate of the stream
(claim 1)

“transmitting the files from the
transmitting computer to the server
at an upload rate generally equal to
the data rate of the stream”

“uploading the sequence from the
transmitting computer to the server at
a data rate (as construed above) that is
generally equal at all points in time to
the data rate of the stream”

5
6
7
8
9
10

United States District Court
Northern District of California

11
12

“uploads the
sequence to a
server at an upload
rate generally qual
to the data rate”
(claim 25)
The court adopts Emblaze’s proposed construction, because it is fully in line with the

13
14

specification’s description of “uploading.” See, e.g., ’473 patent col. 3 ll. 43-45 (“Preferably,

15

uploading the sequence includes comparing the upload rate to the data rate and adjusting the

16

upload rate responsive to the comparison.”).
Microsoft’s proposed construction includes a limitation that is not reflected in the claims or

17
18

the specification. Specifically, this construction requires that the upload rate be generally equal to

19

the stream’s data rate “at all points in time,” purportedly in order to “capture the idea that the data

20

rate of the encoded stream must track the actual upload rate that was achieved during the actual

21

upload transfer.” Resp. Br. at 23-24. The relevant claim language is not limited to this concept.

22

Additionally, the inclusion of this concept could lead to jury confusion in light of the specification,

23

which describes the upload rate as fluctuating depending on the available bandwidth. See, e.g.,

24

’473 patent col. 12 ll. 13-17 (“[I]f it is determined that the upload time for file 42 . . . is

25

substantially shorter than duration T1, the duration of subsequent files may be extended, and/or

26

the compression ratio may be decreased, so as to take better advantage of the available

27

bandwidth.”).

28

///
11

I.

1

“download rate generally equal to the data rate” (Term 13)

2

4
5
6
7
8
9

Emblaze’s proposed construction

Term

3

“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”
(claims 1, 25)

“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”

Microsoft’s proposed construction
“such that one or more client
computers can received the sequence
over the network from the server at a
data rate that is generally equal at all
points in time to the data rate of the
stream”

10
The dispute over this term centers on whether the client has the capacity to select the files

United States District Court
Northern District of California

11
12

it will download and whether the download rate must be equal to the data rate “at all points in

13

time.”

14

The court adopts Emblaze’s proposed construction. This interpretation of the term at

15

issue is consistent with the specification, which teaches that the client is capable of choosing

16

which file to download next. See, e.g., ’473 patent ll. 45-48 (“Responsive to a user input, client 30

17

selects an appropriate starting slice and begins to download and decode (decompress) files 42, 44,

18

46, etc.”); id. col. 11 ll. 4-7 (“Responsive to a user input, client 30 selects an appropriate starting

19

slice and begins to download and decode (decompress) files 42, 44, 46, etc.”); id. col. 8 ll. 7-9 (“A

20

user. . . may choose to begin downloading . . . from an earlier point in time).

21

The inclusion of the phrase “equal at all points in time” is not supported by the claim

22

language or the specification. Additionally, the court finds that the use of this phrase could lead to

23

jury confusion, because the specification teaches that the download rate varies depending on the

24

available bandwidth.

25

J.

Other terms (Terms 14 through 17)

26

The parties have identified four other terms for construction. The parties, however, have

27

not indicated in their joint claim construction statement that these terms would have a dispositive

28

effect (or any effect) on the disputes in this action. See ECF No. 46. As such, the Court declines
12

1

to construe these terms at this juncture.

2

IV.

3

CONCLUSION
The court construes the terms at issue as follows:

4
5
6

Term
Number

Term

Construction

1

“file” / “files”

“an item containing a single slice
of data that has an identifier that
is recognizable by a file system.”

2

“data rate”

“an amount of data (i.e. number
of bits) per unit of time”

3

“a data stream having a given
data rate”

“a data stream having an assigned
data rate”

4

“providing at the transmitting
computer a data stream”

“before slicing, the transmitting
computer provides a data stream”

5&6

7

“predetermined data size”

“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”

8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18

“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”

19
20
21

22

7

“encoding the slices in a
corresponding sequence of
files”

“forming each slice as a file in a
corresponding sequence of files,
wherein the sequence of files
corresponds to the sequence of
slices”

8

“encoding slices in a plurality
of different quality levels”

“forming each slice at more than
one quality level”

23
24
25
26
27
28

13

1

9

“decode the sequence”

“decompressing any compressed
data in the sequence”

10

“each file having a respective
index”

“sequence of files, wherein each
file has an index that represents a
respective slice’s location in the
sequence”

11

“uploading the sequence”

“transmitting the files from the
transmitting computer to the
server at an upload rate generally
equal to the data rate of the
stream”

13

“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”

2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16

IT IS SO ORDERED.
Dated: July 29, 2014
______________________________________
JON S. TIGAR
United States District Judge

17
18
19
20
21

22
23
24
25
26
27
28
14