Sling TV, L.L.C., et al. (Petitioners)
`v.
`Realtime Adaptive Streaming LLC (Patent Owner)
`
`Demonstratives
`Trial No. IPR2018-01342
`U.S. Patent No. 8,934,535
`
`Before Hon. Kevin W. Cherry, Garth D. Baer, and Nabeel U. Khan,
`Administrative Patent Judges
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`1
`
` 1
`
`DISH 1036
`Sling TV v. Realtime
`IPR2018-01342
`
`
`v.
`Realtime Adaptive Streaming LLC (Patent Owner)
`
`Demonstratives
`Trial No. IPR2018-01342
`U.S. Patent No. 8,934,535
`
`Before Hon. Kevin W. Cherry, Garth D. Baer, and Nabeel U. Khan,
`Administrative Patent Judges
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`1
`
` 1
`
`DISH 1036
`Sling TV v. Realtime
`IPR2018-01342
`
`
`
`Background and Summary of Issues
`
`Construction of “Access Profile”
`
`Grounds 1 and 2: Dvir
`
`Issue 1: Single Disclosure Demonstrates Anticipation
`
`Issue 2: “Access Profiles”
`
`Issue 3: “Compressors Using Asymmetric Data
`Compression”
`
`Issue 4: “Data Block”
`
`Ground 3: Dvir and Ishii
`
`Issue 1: Explicit and Art-Specific Motivations to Combine
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`2
`
` 2
`
`
`
`Summary of Grounds
`
`Ground
`
`Claims
`
`Basis for Rejection
`
`Ground 1 1, 2, 9, 10,
`14
`
`Ground 2 1, 2, 9, 10,
`14
`
`Anticipated by Dvir - 35 U.S.C. § 102
`
`Obvious over Dvir - 35 U.S.C. § 103
`
`Ground 3 3-6, 8, 11,
`12
`
`Obvious over Dvir in view of Ishii - 35
`U.S.C. § 103
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`3
`
` 3
`
`
`
`Alleged Innovation of the ’535 Patent – Selecting
`Compression Algorithms Suitable for the Data Type
`
`The ’535 Patent’s controller (11) uses data profiles (15) having
`“access profiles” for selecting suitable compression algorithms (13)
`for a particular data type
`
`DISH1001, 11:6-13, 11:25-38, Fig. 1; Paper 2 (Petition), pp. 8-14
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`4
`
` 4
`
`
`
`Alleged Innovation of the ’535 Patent – Selecting
`Compression Algorithms Suitable for the Data Type
`
`The ’535 Patent uses the “access profiles” to link the “data type” to
`the compression algorithm
`For example, the ’535 Patent links “Data Types” with “Access Profile
`1” to an “Asymmetrical (Slow compression)” compression algorithm
`
`DISH1001, 8:4-12, 11:31-39, 12:50-60; Paper 2 (Petition), pp. 8-14
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`5
`
` 5
`
`
`
`The ’535 Patent Claims Select an “Access Profile” Based on the
`Data and Compress Using Information from the “Access Profile”
`
`1. A method, comprising:
`
`determining, a parameter or an attribute of at least a
`portion of a data block having video or audio data;
`
`selecting an access profile from among a plurality of
`access profiles based upon the determined parameter or
`attribute; and
`
`compressing the at least the portion of the data block
`with one or more compressors using asymmetric data
`compression and information from the selected access
`profile to create one or more compressed data blocks, the
`information being indicative of the one or more
`compressors to apply to the at least the portion of the data
`block.
`
`DISH1001, 20:29-41; see Paper 2 (Petition), pp. 12-14, 27-35
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`6
`
` 6
`
`
`
`Summary of Dvir
`
`Dvir discloses a system for streaming compressed video from a home
`desktop computer (PC 34) to a remote monitor (36) with minimal
`processing power
`
`DISH1004, 1:12-19, Fig. 3a; Paper 2 (Petition), pp. 20-24
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`7
`
` 7
`
`
`
`Summary of Dvir
`
`Dvir determines “a parameter or an attribute of at least a portion of a
`data block having video or audio data”
`
`Dvir samples rasters and determines a
`parameter of the sample
`
`DISH1004, 5:29-42, Fig. 1b; Paper 2 (Petition), pp. 27-30
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`8
`
` 8
`
`
`
`Summary of Dvir
`
`Dvir selects “an access profile based upon the
`determined parameter or attribute”
`
`Dvir selects a compression profile
`based on the determined parameter
`
`DISH1004, 5:43-51, Fig. 1b; Paper 2 (Petition), pp. 30-32
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`9
`
` 9
`
`
`
`Summary of Dvir
`
`Dvir compresses the data “with one or more compressors using
`asymmetric data compression and information from the selected access
`profile to create one or more compressed data blocks”
`
`Dvir applies a compression algorithm
`based on the compression profile
`
`DISH1004, 5:14-22, 6:43-45, Fig. 1b; Paper 2 (Petition), pp. 32-35
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`10
`
`
`10
`
`
`
`Dvir Discloses All Limitations of Claim 1
`
`Claim 1
`
`Dvir
`
`1. A method, comprising:
`determining, a parameter or an attribute of at least
`a portion of a data block having video or audio
`data;
`
`selecting an access profile from among a plurality
`of access profiles based upon the determined
`parameter or attribute; and
`
`compressing the at least the portion of the data
`block with one or more compressors using
`asymmetric data compression and information from
`the selected access profile to create one or more
`compressed data blocks, the information being
`indicative of the one or more compressors to apply
`to the at least the portion of the data block.
`
`DISH1001, 20:29-41; see Paper 2 (Petition), pp. 27-35
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`11
`
`
`11
`
`
`
`Relevant Claim Constructions
`
`Claim Term
`
`Proposed Constructions
`
`DISH: “information that enables a controller to determine a compression
`routine that is associated with a data type of the data to be compressed”
`
`“Access
`Profile”
`
`Realtime: “information that enables the controller to select a suitable
`compression algorithm that provides a desired balance between execution
`speed (rate of compression) and efficiency (compression ratio)”
`
`Netflix (IPR2018-01169): “information regarding the number or frequency of
`reads or writes”
`
`DISH: “algorithm where the compression of data and decompression of that
`compressed data take different amounts of time”
`
`Realtime: “compression algorithm in which the execution time for
`compression and decompression differ significantly”
`
`“Compressors
`for Asymmetric
`Compression”
`
`“Data Block”
`
`“a single unit of data, which may range in size from individual bits through
`complete files or collection of multiple files”
`
`DISH: “any recognizable data token or descriptor”
`
`“Parameter”
`
`Realtime: No construction necessary
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`12
`
`
`12
`
`
`
`Background and Summary of Issues
`
`Construction of “Access Profile”
`
`Grounds 1 and 2: Dvir
`
`Issue 1: Single Disclosure Demonstrates Anticipation
`
`Issue 2: “Access Profiles”
`
`Issue 3: “Compressors Using Asymmetric Data
`Compression”
`
`Issue 4: “Data Block”
`
`Ground 3: Dvir and Ishii
`
`Issue 1: Explicit and Art-Specific Motivations to Combine
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`13
`
`
`13
`
`
`
`“Access Profile”
`
`Proposed Constructions
`
`DISH
`
`“information that enables a controller to determine a
`compression routine that is associated with a data
`type of the data to be compressed”
`
`Realtime
`
`“information that enables the controller to select a
`suitable compression algorithm that provides a desired
`balance between execution speed (rate of compression)
`and efficiency (compression ratio)”
`
`Netflix
`
`“information regarding the number or frequency of
`reads or writes”
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`14
`
`
`14
`
`
`
`“Access Profile” Must Be Construed
`
`Parties Agree “Access Profile” Is Not a Term of Art
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1029, 32:2-9; Paper 26 (Reply), p. 3
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`15
`
`
`15
`
`
`
`DISH’s Construction Is Supported by the Specification
`
`The specification explicitly states that “access profiles” are “information
`that enables a controller to determine a compression routine that is
`associated with a data type of the data to be compressed”
`
`DISH1001, 8:4-12, 11:31-40; Paper 2 (Petition), pp. 19-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`16
`
`
`16
`
`
`
`DISH’s Construction Is Supported by the Specification
`
`The specification shows that “Access Profiles” provide a link
`between “Data Types” and “Compression Algirthms”
`For example, the ’535 Patent links “Data Types” with “Access Profile
`1” to an “Asymmetrical (Slow compression)” compression algorithm
`
`DISH1001, 8:4-12, 11:31-40, 12:50-60; Paper 2 (Petition), pp. 19-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`17
`
`
`17
`
`
`
`DISH’s Construction Is Supported by the Specification
`
`Realtime takes issue with DISH’s use of “data type” but fails to identify a
`single instance where “access profile” is not tied to “data type”
`
`Paper 19 (POR), pp. 16-17; Paper 26 (Reply), pp. 3-4
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`18
`
`
`18
`
`
`
`“Access Profile”
`
`Proposed Constructions
`
`DISH
`
`“information that enables a controller to determine a
`compression routine that is associated with a data type
`of the data to be compressed”
`
`Realtime
`
`“information that enables the controller to select a
`suitable compression algorithm that provides a
`desired balance between execution speed (rate of
`compression) and efficiency (compression ratio)”
`
`Netflix
`
`“information regarding the number or frequency of reads
`or writes”
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`19
`
`
`19
`
`
`
`Realtime’s Construction—With Terms Like “Suitable” and
`“Desired”—Is Subjective and Aspirational
`
`While both parties’ constructions are found in the specification,
`Realtime’s construction is purely aspirational
`
`DISH
`
`Realtime
`
`DISH1001, 8:4-12; Paper 2 (Petition), pp. 19-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`20
`
`
`20
`
`
`
`Realtime’s Construction—With Terms Like “Suitable” and
`“Desired”—Is Subjective and Aspirational
`
`Realtime’s expert confirmed “desired balance between execution speed
`(rate of compression) and efficiency (compression ratio)” is subjective
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1029, 33:18-34:8; Paper 26 (Reply), pp. 1-3
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`21
`
`
`21
`
`
`
`Realtime’s Construction Is Subjective and Aspirational
`
`The Board should refrain from using subjective terms
`like “suitable” and “desired” to define “access profile”
`
`The term “unobtrusive manner” is “purely
`subjective” and therefore indefinite for failing to
`provide the “reasonable certainty”
`required
`under Nautilus.
`
`Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364, 1368 (Fed. Cir. 2014)
`(emphasis added)
`
`“Aesthetically pleasing” is a subjective term
`and claims reciting that limitation are indefinite.
`
`Datamize, LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1351 (Fed. Cir. 2005)
`(emphasis added)
`
`Paper 19 (POR), pp. 16-17; Paper 26 (Reply), pp. 1-3
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`22
`
`
`22
`
`
`
`Realtime’s Construction Improperly Inserts Limitations from
`the Specification into the Claims
`
`The claims say nothing about the algorithm or “compressor” being
`“suitable,” let alone one that meets a “desired balance between execution
`speed . . . and efficiency.”
`
`1. A method, comprising:
`
`determining, a parameter or an attribute of at least a portion of a data block
`having video or audio data;
`
`selecting an access profile from among a plurality of access profiles based
`upon the determined parameter or attribute; and
`
`compressing the at least the portion of the data block with one or more
`compressors using asymmetric data compression and information from the
`selected access profile to create one or more compressed data blocks, the
`information being indicative of the one or more compressors to apply to the at
`least the portion of the data block.
`
`“[L]imitations are not to be read into the claims
`from the specification.”
`
`Akamai Tech v. Limelight Networks, Inc., No. 2016-01011, 2017 WL
`4864813, at *4 (P.T.A.B. Oct. 27, 2017)
`
`Paper 19 (POR), pp. 16-17; Paper 26 (Reply), pp. 1-3
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`23
`
`
`23
`
`
`
`Examples in the Specification Support DISH’s Construction
`
`Realtime’s cited portions of the specification show “access profiles” are
`the link between data types and compression algorithms consistent with
`DISH’s construction
`
`DISH1001, 11:31-40; Paper 19 (Patent Owner Response), pp. 13-16; Paper 26 (Reply), pp. 2-3
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`24
`
`
`24
`
`
`
`“Access Profile”
`
`Proposed Constructions
`
`DISH
`
`“information that enables a controller to determine a
`compression routine that is associated with a data type
`of the data to be compressed”
`
`Realtime
`
`“information that enables the controller to select a
`suitable compression algorithm that provides a desired
`balance between execution speed (rate of compression)
`and efficiency (compression ratio)”
`
`Netflix
`
`“information regarding the number or frequency of
`reads or writes”
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`25
`
`
`25
`
`
`
`The Netflix Construction Is Not the Broadest Reasonable
`Interpretation
`
`The specification does not discuss “access profiles” in terms of a
`“number or frequency of reads or writes” but rather as providing links
`between data types and compression algorithms
`
`“A claim construction that excludes a preferred embodiment is
`a result that is rarely, if ever, correct.”
`
`Ex Parte Kowalski, No. 2014-001764, 2016 WL 738080, at *4 (P.T.A.B. Feb. 22, 2016)
`(internal quotations and citations omitted)
`
`DISH1001, 11:31-38; Paper 26 (Reply), pp. 4-5
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`26
`
`
`26
`
`
`
`The Netflix Construction Is Not the Broadest Reasonable
`Interpretation
`
`References to the number of frequency of reads or writes are
`inferences about the data types that motivate the use of
`different types of compression algorithms
`
`DISH1001, 11:41-47, 12:50-60; Paper 26 (Reply), pp. 4-5
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`27
`
`
`27
`
`
`
`Background and Summary of Issues
`
`Construction of “Access Profile”
`
`Grounds 1 and 2: Dvir
`
`Issue 1: Single Disclosure Demonstrates Anticipation
`
`Issue 2: “Access Profiles”
`
`Issue 3: “Compressors Using Asymmetric Data
`Compression”
`
`Issue 4: “Data Block”
`
`Ground 3: Dvir and Ishii
`
`Issue 1: Explicit and Art-Specific Motivations to Combine
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`28
`
`
`28
`
`
`
`Issue 1 (Grounds 1 and 2): Dvir Properly Anticipates
`
`DISH does not rely on different embodiments of Dvir to show
`anticipation as Realtime contends
`
`it
`reference will anticipate if
`“A prior art
`the
`disclose[s] each and every element of
`claimed invention . . . arranged or combined in
`the same way as in the claim. . . . However, a
`reference can anticipate a claim even if it d[oes]
`not expressly spell out all
`the limitations
`arranged or combined as in the claim,
`if a
`person of skill in the art, reading the reference,
`would
`at
`once
`envisage
`the
`claimed
`arrangement or combination.”
`
`Blue Calypso, LLC v. Groupon, Inc., 815 F.3d 1331, 1341 (Fed.
`Cir. 2016) (citations and internal quotation marks omitted)
`
`Paper 26 (Reply), p. 7
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`29
`
`
`29
`
`
`
`DISH Relies on a Single Embodiment
`
`Realtime’s assertions about multiple embodiments are unsupported; it
`does not provide any evidence Dvir has multiple, incompatible
`embodiments
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1029, 81:15-19, 82:13-24; Paper 26 (Reply), pp. 7-8
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`30
`
`
`30
`
`
`
`Dvir Discloses a Single Multimedia Data Compression and
`Transmission System that Anticipates the Challenged Claims
`
`Fig. 1A (block diagram) and Fig. 1B (flowchart) describe the same data
`compression and transmission system of “the present invention”
`
`Fig. 1b
`
`DISH1004, 4:38-42, 7:1-6, Figs. 1a, 1b, Paper 26 (Reply), pp. 8-9
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`31
`
`
`31
`
`
`
`Dvir Discloses a Single Multimedia Data Compression and
`Transmission System that Anticipates the Challenged Claims
`
`Fig. 2 works in conjunction with Fig. 1A
`•
`It shows the remote wireless monitor that receives the data from
`the multimedia data compression and transmission system of
`Fig. 1A
`
`DISH1004, 4:38-42, 7:1-6, Figs. 1a, 1b, 2; Paper 26 (Reply), pp. 8-9
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`32
`
`
`32
`
`
`
`Dvir Discloses a Single Multimedia Data Compression and
`Transmission System that Anticipates the Challenged Claims
`
`Figs. 3a-c show possible locations of the components of Figs. 1a, which
`does not affect anticipation of the ’535 Patent’s method claims
`
`DISH1004, 8:1-4, 8:38-42, 8:56-59, Figs. 3a-c; Paper 26 (Reply), pp. 8-9
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`33
`
`
`33
`
`
`
`Net MoneyIN Supports DISH’s Position, Not Realitme’s
`
`In Net MoneyIN, the Federal Circuit rejected an anticipation theory that
`relied on “two mutually exclusive” embodiments
`
`As illustrated by our colloquy with counsel at oral
`argument, it is not clear whether the payment models
`disclosed in the iKP reference are mutually exclusive.
`Viewing the facts in the light most favorable to NMI,
`however, as we must do at
`this stage in the
`proceedings, the reference is properly construed to
`show two mutually exclusive payment models.
`
`Net MoneyIN v. Verisign, Inc., 545 F.3d 1359, 1363 n.1 (Fed. Cir. 2008)
`
`Paper 26 (Reply), p. 8
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`34
`
`
`34
`
`
`
`Realtime’s Specific Criticisms Are Unfounded
`
`Realtime argues DISH’s citations to 3:9-21 and claim 11 of Dvir
`shows reliance on multiple embodiments,
`but these citations are nearly identical
`
`Realtime ignores DISH’s other cited support for the
`“access profile” limitations
`
`DISH1004, 3:9-21, 10:12-38; Paper 26 (Reply), pp. 9-10
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`35
`
`
`35
`
`
`
`Realtime’s Specific Criticisms Are Unfounded
`
`Realtime argues DISH’s citations to two paragraphs of the Summary of
`Invention shows reliance on multiple embodiments, but the only difference
`between the paragraphs is an inconsequential ordering of steps
`
`Again, Realtime ignores DISH’s other cited support for
`the “access profile” limitations
`
`DISH1004, 2:64-3:21; Paper 26 (Reply), pp. 10-11
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`36
`
`
`36
`
`
`
`The PTAB Has Already Rejected Realtime’s “Multiple
`Embodiments” Argument
`
`“That Tian itself includes what it characterizes as “one or
`more embodiments,” “one or more other embodiments,”
`“other exemplary embodiments,” or “additional embodiments”
`does not undermine Petitioner’s position. It is what the Petition
`relies on that matters.
`With respect to limitation 1.b, Patent Owner’s citations do not
`establish Petitioner
`is
`relying
`on
`separate
`and
`distinct
`embodiments. The use of “various implementations” in the table’s
`citation to Tian’s column 31 does not specify any embodiment. See
`Ex. 1004, 31:46–50. The other citation to Tian is directed to a
`particular embodiment (“[i]n this implementation”) and does not
`raise a separate and distinct embodiment from the first cite. See id.
`at 34:7–14. Significantly, the Petition does not rely on either of the
`citations identified by Patent Owner. Petitioner cites to various
`parts of Tian but, as noted above in our analysis of claim 1, the
`primary disclosures cited are not separate or distinct from the
`broadest disclosure of Tian. At this stage, additional citations
`to Tian beyond the primary disclosure are not required to
`establish unpatentability.”
`
`Amazon Inc. et al. v. Realtime Adaptive Streaming, LLC, IPR2018-01227, Paper 15
`(Institution Decision), 21; Paper 26 (Reply), p. 6
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`37
`
`
`37
`
`
`
`Issue 2 (Grounds 1 and 2): Dvir Discloses or Renders
`Obvious “Access Profile” Under All Constructions
`
`Proposed Constructions of “Access Profile”
`
`DISH
`
`“information that enables a controller to determine a
`compression routine that is associated with a data
`type of the data to be compressed”
`
`Realtime
`
`“information that enables the controller to select a
`suitable compression algorithm that provides a desired
`balance between execution speed (rate of compression)
`and efficiency (compression ratio)”
`
`Netflix
`
`“information regarding the number or frequency of reads
`or writes”
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`38
`
`
`38
`
`
`
`Dvir Satisfies DISH’s Construction of “Access Profile”
`
`Dvir’s “compression profiles” are “information that enables a
`controller to determine a compression routine that is associated with a
`data type of the data to be compressed”
`
`Dvir uses compression profiles to
`associate compression algorithms with
`data type
`
`DISH1004, 3:9-20, Fig. 1b; Paper 2 (Petition), pp. 30-32
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`39
`
`
`39
`
`
`
`Dvir Satisfies DISH’s Construction of “Access Profile”
`
`Like the ’535 Patent’s “access profiles,” Dvir’s “compression profiles”
`provide the link between data types and compression algorithms
`
`’535 Patent
`
`Dvir
`
`DISH1001, 8:4-13; DISH1004, 5:1-13, 10:21-24; Paper 2 (Petition), p. 31
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`40
`
`
`40
`
`
`
`“Access Profile”
`
`Proposed Constructions
`
`DISH
`
`“information that enables a controller to determine a
`compression routine that is associated with a data type
`of the data to be compressed”
`
`Realtime
`
`“information that enables the controller to select a
`suitable compression algorithm that provides a
`desired balance between execution speed (rate of
`compression) and efficiency (compression ratio)”
`
`Netflix
`
`“information regarding the number or frequency of reads
`or writes”
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`41
`
`
`41
`
`
`
`Dvir Satisfies Realtime’s Construction of “Access Profile”
`
`Dvir’s “compression profiles” allow for the selection of certain MPEG
`compression algorithms that provide an “optimal” balance between
`compression speed and efficiency
`
`DISH1004, 5:14-22, 10:21-24; Paper 2 (Petition), pp. 30-35; Paper 26 (Reply), pp. 15-17
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`42
`
`
`42
`
`
`
`Dvir Satisfies Realtime’s Construction of “Access Profile”
`
`MPEG was designed to balance compression speed and efficiency
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1031, ¶ 45; see generally DISH1031, ¶¶ 41-49; Paper 26 (Reply), pp. 15-17
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`43
`
`
`43
`
`
`
`Dvir at the Very Least Renders Obvious “Access Profile”
`Under Realtime’s Construction
`
`Balancing execution speed and compression ratio according to the
`application is a primary goal of designing compression algorithms
`like MPEG
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1031, ¶ 48; Paper 26 (Reply), pp. 16-17
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`44
`
`
`44
`
`
`
`“Access Profile”
`
`Proposed Constructions
`
`DISH
`
`“information that enables a controller to determine a
`compression routine that is associated with a data type
`of the data to be compressed”
`
`Realtime
`
`“information that enables the controller to select a
`suitable compression algorithm that provides a desired
`balance between execution speed (rate of compression)
`and efficiency (compression ratio)”
`
`Netflix
`
`“information regarding the number or frequency of
`reads or writes”
`
`Paper 2 (Petition), pp. 16-20; Paper 19 (Patent Owner Response), pp. 8-20
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`45
`
`
`45
`
`
`
`Dvir Renders Obvious “Access Profile” Under the Netflix
`Construction
`
`The ’535 Patent acknowledges that different data types have
`different read/write frequencies
`
`DISH1001, 12:50-62; Paper 26 (Reply), pp. 17-18
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`46
`
`
`46
`
`
`
`Dvir Renders Obvious “Access Profile” Under the Netflix
`Construction
`
`A POSITA would have found it obvious for Dvir’s selection based on data
`type to consider read/write access frequency
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1031, ¶ 51; see generally DISH1031, ¶¶ 50-55; Paper 26 (Reply), pp. 17-18
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`47
`
`
`47
`
`
`
`Issue 3 (Grounds 1 and 2): Dvir Discloses “Asymmetric”
`Compression Under Either Party’s Construction
`
`Claim Construction – the only substantive difference in the parties’
`proposed constructions is whether the compression/decompression
`speeds must differ “significantly”
`
`Realtime
`
`DISH
`
`“compression algorithm in which the
`execution time for compression and
`decompression differ significantly”
`
`“algorithm where the compression of
`data and decompression of that
`compressed data take different
`amounts of time”
`
`Paper 26 (Reply), p. 6
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`48
`
`
`48
`
`
`
`Realtime’s Construction Should Not Be Adopted
`
`The addition of “significantly” to the construction adds only
`unnecessary confusion
`In the related ‘’610 Patent proceeding, Realtime’s expert
`admitted the common specification does not explain which
`differences are “significant”
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1030, 35:16-23; Paper 26 (Reply), p. 6
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`49
`
`
`49
`
`
`
`Dvir Discloses Using Asymmetric Compression Under DISH’s
`Construction
`
`No dispute that MPEG is an “algorithm where the compression of data and
`decompression of that compressed data take different amounts of time”
`
`DISH1020, DVD Demystified, p. 127
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1020, p. 127; DISH1003, ¶¶ 66-67; DISH1030, 60:2-8; Paper 26 (Reply), pp. 18-19
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`50
`
`
`50
`
`
`
`Dvir Discloses Using Asymmetric Compression Under
`Realtime’s Construction
`
`The disclosed MPEG algorithms have computationally-intensive
`compression, which takes significantly longer than decompression
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1003, ¶ 113; see generally DISH1003, ¶¶ 105-117; Paper 2 (Petition), pp. 32-35; DISH1031, ¶ 62
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`51
`
`
`51
`
`
`
`Dvir Discloses Using Asymmetric Compression Under
`Realtime’s Construction
`
`Realtime’s expert has no opinion under Realtime’s construction
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1030, 60:2-8; Paper 26 (Reply), pp. 18-19
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`52
`
`
`52
`
`
`
`Issue 4 (Grounds 1 and 2): Dvir Discloses a “Data Block”
`
`Parties agree on the construction of “data block”
`
`Agreed-Upon Construction
`
`“a single unit of data, which may range in size
`from individual bits through complete files or
`collection of multiple files”
`
`See Paper 19 (Patent Owner Response), pp. 9-10
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`53
`
`
`53
`
`
`
`Dvir Discloses Numerous Examples of “Data Blocks”
`
`Dvir determines a parameter of a “sample”
`Dvir discloses that its “sample” may be a video frame, adjacent
`video frames, or an entire DVD movie—all examples of “data
`blocks”
`
`DISH1004, 5:23-51; Paper 2 (Petition), pp. 27-30; Paper 26 (Reply), pp. 11-15, 27; DISH1031, ¶¶ 34-37, 92-94
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`54
`
`
`54
`
`
`
`Realtime’s Arguments Disregard the Parties’ Agreed-Upon
`Construction of “Data Block”
`
`Realtime provides no support for its argument that a “data block”
`must be made up of contiguous pixels or have “common
`characteristics or functionality”
`The parties’ agreed-upon construction includes “complete files or
`collection of multiple files”
`
`Paper 19 (Patent Owner Response), p. 30
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`55
`
`
`55
`
`
`
`Realtime’s Arguments Disregard the Claim Language
`
`Claim 1 merely requires “determining, a parameter or an attribute of at
`least a portion of a data block”
`If a frame or adjacent frames constitute data blocks, a “sample” must be
`either the data block or a portion of a data block
`
`1. A method, comprising:
`
`determining, a parameter or an attribute of at least a portion of a data block
`having video or audio data;
`
`selecting an access profile from among a plurality of access profiles based
`upon the determined parameter or attribute; and
`
`compressing the at least the portion of the data block with one or more
`compressors using asymmetric data compression and information from the
`selected access profile to create one or more compressed data blocks, the
`information being indicative of the one or more compressors to apply to the at
`least the portion of the data block.
`
`Paper 26 (Reply), pp. 13-15
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`56
`
`
`56
`
`
`
`Realtime’s Arguments Disregard the Parties’ Agreed-Upon
`Construction of “Data Block”
`
`Realtime’s new interpretation would omit “complete files or collection of
`multiple files” in conflict with the agreed-upon construction
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1029, 59:18-60:5; Paper 26 (Reply), pp. 12-14; see also DISH1029, 75:2-17
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`57
`
`
`57
`
`
`
`Dvir’s Discloses a “Data Block” Even Under Realtime’s New Improper
`Interpretation
`
`Dvir’s “sample” (including frames and adjacent frames) are contiguous
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1031, ¶¶ 29-30; see generally DISH1031, ¶¶ 19-35; Paper 26 (Reply), pp. 11-14
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`58
`
`
`58
`
`
`
`Dvir Discloses a “Data Block” Even Under Realtime’s New
`Improper Interpretation
`
`Realtime’s expert admits that a frame could be a “data block” and has no
`opinion as to whether a frame of pixels in Dvir is a “data block”
`
`Dr. Zeger
`
`Realtime’s Technical
`Expert
`
`DISH1029, 75:3-17; Paper 26 (Reply), pp. 12-14
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`59
`
`
`59
`
`
`
`Background and Summary of Issues
`
`Construction of “Access Profile”
`
`Grounds 1 and 2: Dvir
`
`Single Disclosure Demonstrates Anticipation
`
`“Access Profiles”
`
`“Compressors Using Asymmetric Data Compression”
`
`“Data Block”
`
`Ground 3: Dvir and Ishii
`
`Explicit and Art-Specific Motivations to Combine
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`60
`
`
`60
`
`
`
`Issue 1 (Ground 3): a POSITA Would Be Motivated to
`Combine Dvir and Ishii
`
`Overview of Ishii: discloses a content delivery system that optimizes
`compression speed and efficiency based on files’ access frequency
`
`DISH1005, 7:15-34, Fig. 1
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`61
`
`
`61
`
`
`
`Dvir and Ishii Render Obvious Claims 3-6, 8, and 11-12
`
`DISH Relies on the combination of Dvir and Ishii for 3 claim elements
`
`1. Data storage (claims 3-6)
`
`2. Compression based on access frequency (claim 8)
`
`3. Compressed data comprises portions of files (claims 11-12)
`
`Paper 2 (Petition), pp. 52-65
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`62
`
`
`62
`
`
`
`Combining Dvir and Ishii
`
`Dvir’s base computer obtains files from Ishii’s storage system and is
`modified to also consider access frequency when selecting a
`compression algorithm as taught by Ishii
`
`Dvir
`
`Ishii
`
`Access
`Frequency
`
`Media
`Files
`
`DISH1004, Fig. 3c; DISH1005, Fig. 1; Paper 2 (Petition), pp. 42-52
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`63
`
`
`63
`
`
`
`Issue 1 (Ground 3): a POSITA Would Be Motivated to Combine
`Dvir and Ishii
`
`Realtime does not dispute that Ishii discloses:
`• data storage (claims 3-6)
`• compression algorithm selection based on access frequency (claim 8)
`• compressed data comprising portions of files (claims 11-12)
`
`Ishii stores and compresses
`files based on access
`frequency
`
`DISH1005, 7:15-34; Paper 2 (Petition), pp. 58-62
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`64
`
`
`64
`
`
`
`Issue 1 (Ground 3): a POSITA Would Be Motivated to
`Combine Dvir and Ishii
`
`Realtime’s three reasons why a POSITA would not combine Dvir and
`Ishii are unsupported
`
`1. Dvir and Ishii “have no overlap in functionality”
`
`2. Combining Dvir and Ishii would likely result in “added
`complexity”
`
`3. “Dvir and Ishii have different principles of operation”
`
`Paper 19 (Patent Owner Response), pp. 48-52
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`65
`
`
`65
`
`
`
`Realtime’s First Argument Fails: a POSITA Would Combine
`Dvir and Ishii
`
`Realtime’s argument why a POSITA would not combine Dvir and Ishii
`reveals the complementary nature of the two references:
`
`Dvir focuses on content delivery, not content storage
`
`Ishii focuses on content storage, not content delivery
`
`Paper 19 (Patent Owner Response), pp. 48-50; Paper 26 (Reply), pp. 22-24
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`66
`
`
`66
`
`
`
`Realtime’s First Argument Fails: a POSITA Would Combine
`Dvir and Ishii
`
`DISH’s expert explained how a POSITA would integrate Ishii’s storage
`teachings with Dvir’s content delivery system
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1031, ¶ 80; see generally DISH1031, ¶¶ 77-80; Paper 26 (Reply), pp. 22-24
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`67
`
`
`67
`
`
`
`Realtime’s Second Argument Fails: the Benefits of Storing
`Data Outweigh Any Added Complexity
`
`Dvir’s system would already include file storage,
`and Ishii’s storage system provides substantial performance benefits
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1031, ¶ 85; Paper 26 (Reply), 24-25
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`68
`
`
`68
`
`
`
`Realtime’s Second Argument Fails: the Benefits of Tracking
`Access Frequency Outweigh Any Added Complexity
`
`Tracking access frequency incurs minimal added complexity
`
`Dr. Scott Acton
`
`DISH’s Technical
`Expert
`
`DISH1027, ¶ 87; Paper 26 (Reply), 24-25
`
`DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`69
`
`
`69
`
`
`
`Dvir and Ishii Operate Under the Same Principles
`
`The difference identified by Realtime—decompressing on a server
`versus client—is not a significant difference in operation
`
`Pa
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
