Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 1 of 14
`
`
`
`
`
`
`
`
`
`
`
`UNITED STATES DISTRICT COURT
`
`NORTHERN DISTRICT OF CALIFORNIA
`
`EMBLAZE LTD.,
`
`Plaintiff,
`
`v.
`
`MICROSOFT CORPORATION,
`
`Defendant.
`
`Case No. 12-cv-05422-JST
`
`
`CLAIM CONSTRUCTION ORDER
`
`Re: ECF No. 52
`
`
`
`
`
`In this patent infringement action involving technology for streaming files over a network
`
`in real-time, the parties seek construction of several terms used in U.S. Patent No. 6,389,473 (“the
`
`patent-in-suit” or “the ’473 patent”).
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`I.
`
`BACKGROUND
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`A.
`
`Patent-in-Suit and Remaining Asserted Claims
`
`Emblaze Ltd. alleges that Microsoft infringes the ’473 patent by manufacturing, selling,
`
`and/or offering to sell products for streaming media in real-time over the internet. Compl. ¶ 17.
`
`The following chart identifies the patent-in-suit and the remaining asserted claims:
`
`Patent
`
`Claims
`
`
`U.S. Patent No. 6,389,473
`
`
`B.
`
`The ’473 Patent
`
`
`1, 2, 8, 9, 10, 11, 12, 13, 14, 25, 23, 25, 26, 27,
`29, 37, 40
`
`
`The invention claimed in the ’473 patent enables the real-time, continuous streaming of
`
`data over a network without the use of special servers, software, or network infrastructures. The
`
`invention achieves this by requiring the transmitting computer to divide the data stream into slices
`
`of a predetermined size and to include an index with each slice that contains information
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0001
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 2 of 14
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`pertaining to the proper synchronization of the slices. The transmitting computer uploads the
`
`sequence of slices to a server in real-time, and clients download the data stream from the server
`
`and use the information in the indices to ensure that the slices are played in the correct order.
`
`To ensure that the transmission of data is in real-time, the claims require that the data
`
`transfer rate and the playback rate be at least as fast as the rate at which the transmitting computer
`
`can generate the data. For this reason, either the transmitting computer or the server must monitor
`
`the data transfer rate to determine the appropriate rate of transfer in light of the available
`
`bandwidth. Some preferred embodiments also contemplate compressing the data in each slice or
`
`altering the size of each slice depending on the available bandwidth.
`
`Yet other preferred embodiments involve opening a plurality of transfer links between the
`
`transmitting computer and the server and uploading different slices in the sequence over the
`
`various links so long as the total data rate of the links is sufficient to enable uploading the
`
`sequence of slices as the same rate as the data is generated. The client downloading the data also
`
`can access these multiple links to download the data at the data rate. When a link has a data
`
`transfer rate that is lower than the predetermined level, then the transmission over this link can be
`
`stopped so that a new link with a better transmission rate can be opened.
`
`Another embodiment permits including in a data stream multiple versions of each slice,
`
`each with a different quality level. The client selects or is assigned the quality level that is most
`
`appropriate in light of the available bandwidth when downloading the stream.
`
`In some preferred embodiments, the client reads an index file, which contains the file name
`
`of the last slice that was uploaded to the server. The user using the client computer can then
`
`decide the appropriate point in the stream at which to begin downloading. This can be
`
`accomplished through the use of a slider in the playback program used by the client.
`
`Prior methods for broadcasting in real-time known in the art require the compression of the
`
`data stream by a dedicated encoder and the broadcasting of data to clients by a broadcast server.
`
`The encoders and broadcast servers required by these prior methods are costly and therefore
`
`typically cannot be offered by internet service providers to their general customers. The present
`
`invention thus improves upon these prior methods by permitting the real-time broadcasting of data
`
`2
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0002
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 3 of 14
`
`
`
`without special or high-cost encoders or servers.
`
`II.
`
`LEGAL STANDARD
`
`
`
`The construction of patent claim terms is a matter of law for the court. Markman v.
`
`Westview Instruments, Inc., 517 U.S. 370, 372 (1996). A “bedrock principle” of patent law is that
`
`“the claims of a patent define the invention to which the patentee is entitled the right to exclude.”
`
`Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc). In construing a term, the
`
`“objective baseline” is the “ordinary and customary meaning,” which is “the meaning that the term
`
`would have to a person of ordinary skill in the art in question at the time of the invention[.]” Id. at
`
`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
`
`patent, including the specification” and the prosecution history. Id.
`
`The “primary basis for construing [a] claim” and “the best source for understanding a
`
`technical term” is a patent’s intrinsic evidence. Id. at 1314. Intrinsic evidence includes the patent
`
`and its file history, including any reexaminations and reissues, related patents and their
`
`prosecution histories, and the prior art that is cited or incorporated by reference in the patent‐in‐
`
`suit and prosecution history. Id. Extrinsic evidence refers to all other types of evidence, including
`
`inventor testimony, expert testimony, documentary evidence of how the patentee and alleged
`
`infringer have used the claim terms, dictionaries, treatises, and other similar sources. Id. at 1318.
`
`Intrinsic evidence trumps any extrinsic evidence that would contradict it. Id. at 1314.
`
`III. DISCUSSION
`
`A.
`
`“file” / “files” (Term 1)
`
`
`
`Terms
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“file” / “files”
`(claims 1, 8, 9,
`10, 11, 25, 40)
`
`
`
`
`Does not need construction.
`Alternatively: “a slice of data that
`has a file descriptor.”
`
`
`“the collection of data stored in a
`directory and accessed by a file name
`for editing and saving”
`
`The parties’ dispute with respect to this term is over (1) whether “file” should be construed
`
`3
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0003
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 4 of 14
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`at all; and if it is construed, (2) whether “file” should be treated as being synonymous with “slice,”
`
`and (3) whether “file name” should be used in the construction.
`
`
`
`The court adopts the following construction: “an item containing a single slice of data
`
`that has an identifier that is recognizable by a file system.” This construction reflects the
`
`specification’s description of a file as the item that contains a single slice of data. ’473 patent col.
`
`2 ll. 22-27 (“Preferably, each segment or slice is contained in a separate, respective file.”). It also
`
`reflects the specification’s description of a slice as containing identifiers, including a level
`
`identifier, a presentation time stamp, and a size identifier. Id. col. 8 ll. 47-51 (“Each slice is
`
`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
`
`system” during oral argument. The court finds that the use of this phrase is appropriate in light of
`
`Microsoft’s own definition of a file system as “the overall structure in which files are named,
`
`stored, and organized. A file system consists of files, directories, or folders, and the information
`
`needed to locate and access those items . . . .”). See Resp. Br. at 7 (citing the Microsoft Computer
`
`Dictionary, Ex. C at 213).
`
`The term “descriptor” is not used in the specification, and for that reason, the court finds
`
`that its use in construing the term at issue could result in jury confusion. Additionally, the court is
`
`not persuaded that the term “file” is used as a synonym for “slice” in the specification. As
`
`discussed above, the specification describes a file as containing a slice, and not as being a slice.
`
`Microsoft’s proposed construction seeks to add limitations to the term that are not required
`
`by the claims or the specification, such as “stored in a directory,” “accessed by a file name,” and
`
`“for editing and saving.” Accordingly, this construction is improperly narrow.
`
`The parties dispute whether a “file” can contain all of the slices of a data stream as
`
`opposed to just a single slice based on the following preferred embodiment: “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.” ’473 patent col. 2 ll. 22-27.
`
`Microsoft contends that this embodiment is not covered by the claims. The court agrees. The
`
`claims containing the term at issue expressly claim a “sequence of files” that correspond to the
`
`4
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0004
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 5 of 14
`
`
`
`“sequence of slices” (plural). These claims therefore do not cover the embodiment in which all of
`
`the slices are “contained in a single indexed file.”
`
`B.
`
`“data rate” (Term 2)
`
`
`
`Term
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“data rate” (claims
`1, 8, 25, 26)
`
`
`“an amount of data per unit of
`time”
`
`
`“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.
`
`Microsoft also notes that Emblaze itself argued in another case involving the same patent that data
`
`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
`
`bandwidth is measured in bits per second. See Resp. Br., Ex. C at 144. Additionally, the claims at
`
`issue require comparing the upload data rate with the stream data rate, but this can be
`
`accomplished only if the rate is measured in bits as opposed to other units of measurement such as
`
`frames. See, e.g., ’473 patent col. 14 ll. 28–29. This is because bits have a consistent volumetric
`
`value, whereas frames do not.
`
`C.
`
`“a data stream having a given data rate” (Term 3)
`
`
`
`Term
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“a data stream having a given
`amount of data per unit of time”
`
`
`“a data sequence with a uniform
`data rate”
`
`
`“a data stream
`having a given
`data rate” (claims
`1, 25)
`
`
`
`
`
`The parties’ dispute with respect to this term centers on the meaning of the word “given.”
`
`5
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0005
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 6 of 14
`
`
`
`Emblaze contends that “given” means “assigned” or “specified.” In its responsive brief, Microsoft
`
`agrees with this characterization of “given” and urges the court to use either “assigned” or
`
`“specified” in its construction instead of “given.” Resp. Br. at 12. Microsoft argues, however,
`
`that the modifier “uniform” also must be included in the construction because the “density (rate)
`
`of the compressed data must be uniform.” Resp. Br. at 12. Microsoft bases this argument on the
`
`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
`
`court declines to adopt the extraneous limitation “uniform” in its construction. Accordingly, the
`
`court construes the term at issue as “a data stream having an assigned data rate.” The
`
`claims in which the term at issue appears make clear that the upload and download rates must
`
`equal the assigned data rate of the data stream, which both parties agree is a critical aspect of the
`
`invention. In light of this claim language, no further clarification is necessary in the construction
`
`of the term at issue.
`
`D.
`
`“providing at the transmitting computer a data stream” (Term 4)
`
`
`
`Term
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“the transmitting computer provides
`a data stream having a given
`amount of data per unit of time”
`
`
` “the transmitting computer provides a
`data stream for slicing” [having a
`given data rate]”
`
`
`“providing at the
`transmitting
`computer a data
`stream [having a
`given data rate]”
`(claim 1)
`
`
`
`
`The parties agree that the term at issue requires the transmitting computer to provide a data
`
`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
`
`6
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0006
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 7 of 14
`
`
`
`“providing” step comes before the “dividing” step. See E-Pass Technologies, Inc. v. 3Com Corp.,
`
`473 F.3d 1213, 1222 (Fed. Cir. 2007) (“Substantively, because the language of most of the steps
`
`of its method claim refer to the completed results of the prior step, . . . all of those steps [must be]
`
`performed in order”). Accordingly, the court construes the term at issue as “before slicing, the
`
`transmitting computer provides a data stream.”
`
`//
`
`E.
`
`“predetermined data size” (Terms 5 & 6)
`
`
`
`Terms
`
`Emblaze’s proposed construction Microsoft’s proposed 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”
`
`
`
`
`“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”
`
`
`“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.)
`
`
`“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”
`
`
`“each slice having
`a predetermined
`data size
`associated
`therewith” (claims
`1, 25)
`
`
`
`
`“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)
`
`“wherein the
`predetermined data
`size of each of the
`slices corresponds
`to a time duration
`of the slice” (claim
`37)
`
`
`The court adopts Emblaze’s proposed constructions, because they are consistent with
`
`7
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0007
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 8 of 14
`
`
`
`the specification’s teaching that the size of each slice may be based on time. See, e.g., ’473 Patent
`
`col. 2 ll 4-5) (“The data stream is divided into a sequence of segments or slices of the data,
`
`preferably time slices . . .”); id. col. 3 ll. 40-43 (“Preferably, dividing the stream into the sequence
`
`of slices includes dividing the stream into a sequence of time slices, each having a predetermined
`
`duration associated therewith.”).
`
`Microsoft’s construction unjustifiably limits the terms at issue to a “number of bits.”
`
`Microsoft also asks the court to tie the term at issue with the “encoding” of each slice. Because
`
`the “encoding” portion of the method is addressed in the next part of the claims in which the terms
`
`at issue appear, the inclusion of language pertaining to “encoding” is unnecessary.
`
`F.
`
`“encoding the slices” (Terms 7, 8 & 9)
`
`
`
`Term 7
`
`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”
`
`
`“encoding the
`slices in a
`corresponding
`sequence of files”
`(claim 1)
`
`“encodes the slices
`in a corresponding
`sequence of files”
`(claim 25)
`
`
`
`
`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
`
`embodiments. See, e.g., id. col. 11 ll. 26–28 (“In encoding data stream 40, computer 34 preferably
`
`compresses the data using any suitable compression method known in the art.”) (emphasis added).
`
`Because nothing in the claims that contain the term at issue limits “encoding” to “compressing” in
`
`all circumstances, particularly with respect to slices, Microsoft’s proposed construction must be
`
`rejected.
`
`Accordingly, the court adopts the following modified version of Emblaze’s proposed
`
`8
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0008
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 9 of 14
`
`
`
`construction: “forming each slice as a file in a corresponding sequence of files, wherein the
`
`sequence of files corresponds to the sequence of slices.”
`
`Term 8
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“forming slices at more than one
`quality level”
`
`
`“compressing the slices from the data
`stream at more than one quality level”
`
`
`“encoding slices in
`a plurality of
`different quality
`levels” (claim 11)
`
`
`“slices are encoded
`at a plurality of
`different quality
`levels” (claim 40)
`
`
`
`
`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.”
`
`
`
`Term 9
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“decode the
`sequence” (claims
`8, 26)
`
`
`
`“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).
`
`9
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0009
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 10 of 14
`
`
`
`
`
`Accordingly, the court adopts Emblaze’s proposed construction.
`
`G.
`
`“each file having a respective index” (Term 10)
`
`Term
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“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”
`
`
`“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
`
`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.
`
`Emblaze’s proposed construction uses the term “indicator” as a synonym for “index,” but
`
`this is not supported by the specification.
`
`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.
`
`/ / /
`
`/ / /
`
`/ / /
`
`/ / /
`
`/ / /
`
`/ / /
`
`/ / /
`
`10
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0010
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 11 of 14
`
`
`
`H.
`
`“uploading the sequence” (Term 11)
`
`
`
`Terms
`
`Emblaze’s proposed construction Microsoft’s proposed construction
`
`
`“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”
`
`
`“uploading the
`sequence to a
`server at an upload
`rate generally
`equal to the data
`rate of the stream
`(claim 1)
`
`“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
`
`specification’s description of “uploading.” See, e.g., ’473 patent col. 3 ll. 43-45 (“Preferably,
`
`uploading the sequence includes comparing the upload rate to the data rate and adjusting the
`
`upload rate responsive to the comparison.”).
`
`Microsoft’s proposed construction includes a limitation that is not reflected in the claims or
`
`the specification. Specifically, this construction requires that the upload rate be generally equal to
`
`the stream’s data rate “at all points in time,” purportedly in order to “capture the idea that the data
`
`rate of the encoded stream must track the actual upload rate that was achieved during the actual
`
`upload transfer.” Resp. Br. at 23-24. The relevant claim language is not limited to this concept.
`
`Additionally, the inclusion of this concept could lead to jury confusion in light of the specification,
`
`which describes the upload rate as fluctuating depending on the available bandwidth. See, e.g.,
`
`’473 patent col. 12 ll. 13-17 (“[I]f it is determined that the upload time for file 42 . . . is
`
`substantially shorter than duration T1, the duration of subsequent files may be extended, and/or
`
`the compression ratio may be decreased, so as to take better advantage of the available
`
`bandwidth.”).
`
`/ / /
`
`11
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0011
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 12 of 14
`
`
`
`
`
`I.
`
`“download rate generally equal to the data rate” (Term 13)
`
`Term
`
`Emblaze’s proposed construction Microsoft’s proposed 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”
`
`
`“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”
`
`
`“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)
`
`
`
`
`
`The dispute over this term centers on whether the client has the capacity to select the files
`
`it will download and whether the download rate must be equal to the data rate “at all points in
`
`time.”
`
`The court adopts Emblaze’s proposed construction. This interpretation of the term at
`
`issue is consistent with the specification, which teaches that the client is capable of choosing
`
`which file to download next. See, e.g., ’473 patent ll. 45-48 (“Responsive to a user input, client 30
`
`selects an appropriate starting slice and begins to download and decode (decompress) files 42, 44,
`
`46, etc.”); id. col. 11 ll. 4-7 (“Responsive to a user input, client 30 selects an appropriate starting
`
`slice and begins to download and decode (decompress) files 42, 44, 46, etc.”); id. col. 8 ll. 7-9 (“A
`
`user. . . may choose to begin downloading . . . from an earlier point in time).
`
`The inclusion of the phrase “equal at all points in time” is not supported by the claim
`
`language or the specification. Additionally, the court finds that the use of this phrase could lead to
`
`jury confusion, because the specification teaches that the download rate varies depending on the
`
`available bandwidth.
`
`J.
`
`Other terms (Terms 14 through 17)
`
`
`
`The parties have identified four other terms for construction. The parties, however, have
`
`not indicated in their joint claim construction statement that these terms would have a dispositive
`
`effect (or any effect) on the disputes in this action. See ECF No. 46. As such, the Court declines
`
`12
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0012
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 13 of 14
`
`
`
`to construe these terms at this juncture.
`
` CONCLUSION
`
`The court construes the terms at issue as follows:
`
`IV.
`
`
`
`
`Term
`
`Construction
`
`
`“an item containing a single slice
`of data that has an identifier that
`is recognizable by a file system.”
`
`
`“an amount of data (i.e. number
`of bits) per unit of time”
`
`
`“a data stream having an assigned
`data rate”
`
`
`“before slicing, the transmitting
`computer provides a data stream”
`
`
`“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”
`
`“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”
`
`
`“forming each slice as a file in a
`corresponding sequence of files,
`wherein the sequence of files
`corresponds to the sequence of
`slices”
`
`
`“forming each slice at more than
`one quality level”
`
`
`“file” / “files”
`
`
`
`“data rate”
`
`
`
`“a data stream having a given
`data rate”
`
`
`“providing at the transmitting
`computer a data stream”
`
`
`“predetermined data size”
`
`
`Term
`Number
`
` 1
`
`
`
` 2
`
`
`
` 3
`
`
`
`
`
` 4
`
`
`
`
`
` 5
`
` & 6
`
`
`“encoding the slices in a
`corresponding sequence of
`files”
`
`
`
`“encoding slices in a plurality
`of different quality levels”
`
` 7
`
`
`
`
`
` 8
`
`
`
`
`
`
`13
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0013
`
`

`

`Case 3:12-cv-05422-JST Document 93 Filed 07/29/14 Page 14 of 14
`
`
`
`
`“decompressing any compressed
`data in the sequence”
`
`
`“sequence of files, wherein each
`file has an index that represents a
`respective slice’s location in 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”
`
`
`“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”
`
`
`“each file having a respective
`index”
`
`
`
`“uploading the sequence”
`
`
`
`“download rate generally
`equal to the data rate”
`
`
` 9
`
`
`
`
`
`
`10
`
`
`
`11
`
`
`13
`
`
`IT IS SO ORDERED.
`
`Dated: July 29, 2014
`
`______________________________________
`JON S. TIGAR
`United States District Judge
`
`
`
`14
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`Petitioner's Exhibit 1110
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0014
`
`