throbber
Trials@uspto.gov
`571.272.7822
`
`
`
`
`
` Paper No. 47
`Date: February 27, 2020
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`GOOGLE LLC, and COMCAST CABLE COMMUNICATIONS, LLC,
`Petitioner,
`v.
`REALTIME ADAPTIVE STREAMING, LLC,
`
`Patent Owner.
`____________
`
`IPR2018-013421
`Patent 8,934,535 B2
`____________
`
`
`Before KEVIN W. CHERRY, GARTH D. BAER, and
`NABEEL U. KHAN, Administrative Patent Judges.
`
`CHERRY, Administrative Patent Judge.
`
`JUDGMENT
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a)
`Determining All of the Challenged Claims Unpatentable
`
`
`1 GOOGLE LLC, who filed a petition in IPR2019-00748, and COMCAST
`CABLE COMMUNICATIONS, LLC, who filed a petition in IPR2019-
`00760, were joined as petitioners to this proceeding. On January 17, 2020,
`we terminated the original Petitioner in IPR2018-01342 (see section I.A
`below), but for administrative convenience we kept IPR2018-01342 open to
`serve as the consolidated docket for IPR2019-00748 and IPR2019-00760.
`See Paper 45.
`
`
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`I.
`
`INTRODUCTION
`A. Background
`Google LLC (“Google”) and Comcast Communications, LLC
`(“Comcast”) (collectively, “Petitioner”) filed Petitions (IPR2019-00748,
`Paper 1; IPR2019-00760, Paper 1) to institute an inter partes review of
`claims 1–6, 8–12, and 14 (the “challenged claims”) of U.S. Patent
`No. 8,934,535 B2 (Exhibit 1001, “the ’535 Patent”). Google and Comcast
`also filed timely motions for joinder to the already instituted proceeding in
`IPR2018-01342, which we granted. See Papers 24, 25.
`The Petition in IPR2018-01342 was originally filed by Sling TV
`L.L.C., Sling Media L.L.C., DISH Network L.L.C., and DISH Technologies
`L.L.C. (collectively, “Sling”) (Paper 2, “Petition” or “Pet.”).2 Sling’s
`Petition requested that we institute an inter partes review of the challenged
`claims. Realtime Adaptive Streaming, LLC (“Patent Owner”) filed a
`Preliminary Response. Paper 6 (“Prelim. Resp.”). We also allowed Sling
`and Patent Owner to file additional briefing on the issue of whether Sling’s
`Petition was barred under 35 U.S.C. § 315(b). See Papers 7, 8.
`
`
`2 Google and Comcast have represented and we have found (see Paper 24, 3;
`Paper 25, 3) that the Petitions in IPR2019-00748 and IPR2019-00760 are
`substantially identical to the Petition in IPR2018-01342. Patent Owner
`acknowledges this. See Paper 30, 7. Although Sling is no long a party, we
`have maintained IPR2018-01342 to serve as the consolidated docket for
`IPR2019-00748 and IPR2019-00760. See Paper 45, 14. For sake of clarity
`and simplicity, we treat the Petition in IPR2018-01342 (Paper 2) as
`representative and all citations are to it, and the papers filed in IPR2018-
`01342, unless otherwise expressly noted.
`
`2
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`The Petition asserts the following grounds:
`
`Claim(s) Challenged 35 U.S.C. § Reference(s)/Basis
`1, 2, 9, 10, 14
`102
`Dvir3
`1, 2, 9, 10, 14
`103
`Dvir
`3–6, 8, 11, 12
`103
`Dvir and Ishii4
`
`
`On January 31, 2019, we instituted an inter partes review of all claims
`challenged in the Petition and on all of the asserted grounds. See Paper 9, 26
`(“Dec. on Inst.”).
`After institution of trial, Patent Owner filed a Patent Owner Response
`(Paper 19, “PO Resp.”), and Sling filed a Reply (Paper 26, “Reply”). Patent
`Owner also filed a Sur-Reply (Paper 34, “Sur-Reply”).
`Petitioner supports its arguments with a declaration by Scott T. Acton,
`Ph.D., dated July 3, 2018 (Ex. 1003), and a supplemental declaration by
`Dr. Acton, dated August 30, 2019 (Ex. 1031). Patent Owner supports its
`Response with a declaration by Kenneth A. Zeger, Ph.D., dated May 30,
`2019 (Ex. 2010). Oral argument was held on December 5, 2019, a transcript
`of which is included in the record. Paper 43 (“Tr.”).
`We have jurisdiction under 35 U.S.C. § 6. Petitioner bears the burden
`of proving unpatentability of the challenged claims, and the burden of
`persuasion never shifts to Patent Owner. Dynamic Drinkware, LLC v. Nat’l
`Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015). To prevail, Petitioner
`must prove unpatentability by a preponderance of the evidence. See
`
`
`3 Dvir, U.S. Patent No. 6,557,001 B1, iss. Apr. 29, 2003, filed Nov. 12, 1999
`(Exhibit 1004, “Dvir”).
`4 Ishii, U.S. Patent No. 5,675,789, iss. Oct. 7, 1997 (Exhibit 1005, “Ishii”).
`
`3
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d). This Final Written Decision is
`issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the
`reasons that follow, we determine that Petitioner has shown by a
`preponderance of the evidence that claims 1–6, 8–12, and 14 of the ’535
`Patent are unpatentable. See 35 U.S.C. § 316(e).
`
`Related Proceedings
`B.
`The parties inform us that the ʼ535 Patent is involved in the following
`litigations:
`
`• Realtime Data, LLC v. Echostar Corp., No. 6:17-cv-84 (E.D. Tex.)
`• Realtime Data LLC d/b/a IXO v. DISH Network Corp. et al., 6:17-cv-
`00421 (E.D. Tex.)
`• Realtime Adaptive Streaming, LLC v. Sling TV, LLC, No. 1:17-cv-
`2097 (D. Colo.)
`• Realtime Adaptive Streaming, LLC v. Amazon.com, Inc., No. 6:17-cv-
`549 (E.D. Tex.)
`• Realtime Adaptive Streaming LLC v. EchoStar Technologies, LLC et
`al., No. 6:17-cv-00567 (E.D. Tex.).
`• Realtime Adaptive Streaming, LLC v. Hulu, LLC, No. 2:17-cv-7611
`(C.D. Cal.)
`• Realtime Adaptive Streaming, LLC v. Cisco Systems, Inc., No. 6:17-
`cv-591 (E.D. Tex.)
`• Realtime Adaptive Streaming, LLC v. Brightcove, Inc., No. 1:17-cv-
`1519 (D. Del.)
`• Realtime Adaptive Streaming, LLC v. Haivision Network Video, Inc.,
`No. 1:17-cv-1520 (D. Del.)
`• Realtime Adaptive Streaming, LLC v. Polycom, Inc., No. 1:17-cv-
`2692 (D. Colo.)
`• Realtime Adaptive Streaming, LLC v. Netflix, Inc., No. 1:17-cv-1692
`(D. Del.)
`
`4
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`• Realtime Adaptive Streaming, LLC v. Sony Elecs., Inc., No. 1:17-cv-
`1693 (D. Del.)
`• Realtime Adaptive Streaming, LLC v. Apple, Inc., No. 1:17-cv-2869
`(D. Colo.)
`• Realtime Adaptive Streaming, LLC v. Adobe Sys. Inc., No. 1:18-cv-
`10355 (D. Mass.)
`• Realtime Adaptive Streaming, LLC v. Samsung Elec. Co., Ltd., No.
`6:18-cv-00113 (E.D. Tex.)
`• Realtime Adaptive Streaming LLC v. Wowza Media Systems LLC, No.
`1:18-cv-00927 (D. Colo.)
`• Realtime Adaptive Streaming LLC v. Google LLC et al, No. 2:18-cv-
`03629 (C.D. Cal.)
`• Realtime Adaptive Streaming LLC v. Avaya Inc., No. 1:18-cv-01046
`(D. Colo.)
`• Realtime Adaptive Streaming LLC v. Broadcom Corporation et al.,
`No. 1:18-cv-01048 (D. Colo.)
`• Realtime Adaptive Streaming LLC v. LG Electronics Inc. et al, No.
`6:18-cv-00215 (E.D. Tex.)
`• Realtime Adaptive Streaming LLC v. Advanced Micro Devices, Inc.,
`No. 1:18-cv-01173 (D. Colo.)
`• Realtime Adaptive Streaming LLC v. Intel Corporation, No. 1:18-cv-
`01175 (D. Colo.)
`• Realtime Adaptive Streaming LLC v. Mitel Networks, Inc., No. 1:18-
`cv-01177 (D. Colo.)
`• Realtime Adaptive Streaming LLC v. Charter Communications, Inc. et
`al, No. 1:18-cv-01345 (D. Colo.)
`• Realtime Adaptive Streaming LLC v. Cox Communications, Inc., No.
`8:18-cv-00942 (C.D. Cal.)
`• Realtime Adaptive Streaming LLC v. Comcast Cable
`Communications, LLC, No. 1:18-cv-01446 (D. Colo.)
`Pet. 4–6; Paper 3, 2–4.
`
`5
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`Petitioner further informs us that the ʼ535 Patent is involved in the
`following inter partes review proceedings:
`
`• Unified Patents Inc. v. Realtime Adaptive Streaming LLC, IPR2018-
`00883
`• Hulu, LLC, Amazon.com, Inc., and Netflix, Inc. v. Realtime Adaptive
`Streaming LLC, IPR2018-01169
`• Hulu, LLC, Amazon.com, Inc., and Netflix, Inc. v. Realtime Adaptive
`Streaming LLC, IPR2018-01170
`• Sling TV L.L.C., Sling Media L.L.C., DISH Network L.L.C., and DISH
`Technologies L.L.C. v. Realtime Adaptive Streaming LLC, IPR2018-
`01332
`
`The ’535 Patent
`C.
`The ʼ535 Patent relates generally to compressing and decompressing
`data based on an actual or expected throughput (bandwidth) of a system.
`Ex. 1001, 1:21–25. The ʼ535 Patent explains that data compression
`algorithms can have varied performance characteristics. Ex. 1001, 1:32–35.
`For example, with a typical dictionary-based compression algorithm, such as
`Lempel-Ziv, the size of the dictionary can affect the performance of the
`algorithm. Ex. 1001, 1:35–38. A large dictionary may yield very good
`compression ratios, but may make the algorithm take a long time to execute.
`On the other hand, a smaller dictionary would yield a faster compression
`time but at the expense of lower compression ratio. Ex. 1001, 1:38–44.
`Thus, one challenge in employing data compression is selecting the
`appropriate algorithm from a variety of algorithms for a given application or
`system. The desired balance between speed and efficiency is an important
`factor in determining which algorithm to select for data compression. A
`system that provides dynamic modification of compression system
`
`6
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`parameters to provide an optimal balance between speed and compression
`ratio is highly desirable. Ex. 1001, 1:56–60.
`The ʼ535 Patent describes two categories of compression
`algorithms—asymmetrical and symmetrical. An asymmetrical data
`compression algorithm is “one in which the execution time for the
`compression and decompression routines differ significantly.” Ex. 1001,
`9:64–66. Thus, in an asymmetrical algorithm, either the compression time is
`fast with the decompression time being slow, or vice versa. An example of
`an asymmetric algorithm is Lempel-Ziv. Ex. 1001, 10:2–4. A symmetric
`compression algorithm, on the other hand, is “one in which the execution
`time for the compression and the decompression routines are substantially
`similar. Examples of symmetrical algorithms include table-based
`compression schemes such as Huffman.” Ex. 1001, 10:5–9. The total
`execution time of the compression and decompression portions of
`asymmetrical algorithms is typically higher than the total time for
`symmetrical algorithms. But an asymmetric algorithm typically achieves
`higher compression ratios. Ex. 1001, 10:10–14.
`The invention described in the ʼ535 Patent “is directed to a system and
`method for compressing and decompressing based on the actual or expected
`throughput (bandwidth) of a system employing data compression and a
`technique of optimizing based upon planned, expected, predicted, or actual
`usage.” Ex. 1001, 7:51–55. A bandwidth sensitive data compression routine
`may be selected based on access profiles that enable the controller to
`determine a compression routine associated with a data type of the data to be
`compressed. Ex. 1001, 8:4–8. The access profiles comprise information
`that enables the controller to select a suitable compression algorithm that
`
`7
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`provides the desired balance between speed and compression ratio.
`Ex. 1001, 8:8–13.
`These access profiles may take into account the overall throughput of
`a system as one factor in deciding whether to use an asymmetric or
`symmetric algorithm. Ex. 1001, 11:25–29. Another factor the access profile
`may track is the type of data to be processed. Ex. 1001, 11:29–31. For
`example, different data types (the type may be determined by a file
`extension of the data) may be associated with different compression
`algorithms. Ex. 1001, 11:35–40.
`The ʼ535 Patent illustrates this concept with three categories of access
`profiles. In a first category, the access profile of a particular data type may
`specify that the data may be decompressed significantly more times than it is
`compressed. This is typical with operating systems, applications, and
`websites. Ex. 1001, 12:1–12. In such a situation it may be suitable to use an
`asymmetric algorithm that provides a slow compression routine and a fast
`decompression routine. Ex. 1001, 12:14–20. Thus, the compression ratio
`achieved by using an asymmetric algorithm with slow compression will be
`higher than if a symmetric algorithm was used. Ex. 1001, 12:20–24.
`A second category is one in which the data would be compressed
`significantly more times than decompressed. Ex. 1001, 12:25–27. This is
`typical for automatically updating an inventory database. Here, an
`asymmetric algorithm with a fast compression routine and a slow
`decompression routine would be most appropriate. Ex. 1001, 12:27–35.
`A third category is one in which the data is accessed with a similar
`number of reads and writes and, thus, would be compressed and
`decompressed approximately the same number of times. Ex. 1001, 12:36–
`
`8
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`39. This is typical of most user-generated data such as documents and
`spreadsheets. Ex. 1001, 12:40–41. In this case, a symmetric algorithm that
`provides relatively fast compression and decompression would be
`preferable. Ex. 1001, 12:41–43.
`In this way, the ʼ535 Patent describes a system that automatically
`selects an appropriate compression algorithm to optimize system throughput
`based on the type of data being installed or stored. Ex. 1001, 14:27–39.
`
`Illustrative Claim
`D.
`Of the challenged claims, claims 1 and 14 are independent. Claims 2–
`6 and 8–12 depend directly or indirectly from claim 1.
`Claim 1, reproduced below, is illustrative:
`1.
`A method, comprising:
`determining a parameter or attribute of at least a portion
`of a data block having audio or video 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.
`
`
`
`LEVEL OF ORDINARY SKILL IN THE ART
`II.
`Petitioner proposes that a person of ordinary skill “would have had a
`bachelor’s degree in electrical engineering, computer engineering, computer
`science, or the equivalent and 2–3 years of work experience with data
`compression, storage, retrieval, processing, and transmission, or the
`
`9
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`equivalent.” Pet. 15 (citing Ex. 1003 ¶¶ 34–39). For purposes of this
`proceeding, Patent Owner adopts Petitioner’s proposed level of skill in the
`art. PO Resp. 8. We agree with the parties that this represents the
`appropriate level of skill in the art, and we adopt Petitioner’s proposed level
`of ordinary skill.
`
`III. CLAIM CONSTRUCTION
`In an inter partes review based on a petition filed prior to
`November 13, 2018, claim terms in an unexpired patent are construed
`according to their broadest reasonable interpretation in light of the
`specification of the patent in which they appear. See 37 C.F.R. § 42.100(b)
`(2017); Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–46 (2016).
`Under that standard, there is a presumption that claim terms are given their
`ordinary and customary meaning, as would be understood by a person of
`ordinary skill in the art in the context of the specification. See In re
`Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Nonetheless,
`if the specification “reveal[s] a special definition given to a claim term by
`the patentee that differs from the meaning it would otherwise possess[,] . . .
`the inventor’s lexicography governs.” Phillips v. AWH Corp., 415 F.3d
`1303, 1316 (Fed. Cir. 2005) (en banc) (citing CCS Fitness, Inc. v. Brunswick
`Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002)). Another exception to the
`general rule that claims are given their ordinary and customary meaning is
`“when the patentee disavows the full scope of a claim term either in the
`specification or during prosecution.” Uship Intellectual Props., LLC v.
`United States, 714 F.3d 1311, 1313 (Fed. Cir. 2013) (quoting Thorner v.
`Sony Computer Entm’t Am., LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012)).
`
`10
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`Because IPR2018-01342 was filed before November 13, 2018, the
`recent amendment to this rule did not apply. See Changes to the Claim
`Construction Standard for Interpreting Claims in Trial Proceedings Before
`the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018)
`(amending 37 C.F.R. § 42.100(b) effective Nov. 13, 2018) (codified at 37
`C.F.R. pt. 42). However, as we discussed above, we terminated Sling and
`are proceeding on IPR2019-00748 and IPR2019-00760, which were filed
`after November 13, 2018. Under the new claim construction standard, “[i]n
`an inter partes review proceeding, a claim of a patent . . . shall be construed
`using the same claim construction standard that would be used to construe
`the claim in a civil action under 35 U.S.C. 282(b).” 37 C.F.R. § 42.100(b)
`(2019). Specifically, under the new standard, we apply the principles set
`forth in Phillips v. AWH Corp., 415 F.3d 1303, 1312–17 (Fed. Cir. 2005) (en
`banc). Under that standard, the words of a claim are generally given their
`“ordinary and customary meaning,” which is the meaning the term would
`have to a person of ordinary skill at the time of the invention, in the context
`of the entire patent including the specification. See Phillips, 415 F.3d at
`1312–13. Additionally, only terms that are in controversy need to be
`expressly construed, and these need be construed only to the extent
`necessary to resolve the controversy. See Nidec Motor Corp. v. Zhongshan
`Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017).
`Because we are proceeding on IPR2019-00748 and IPR2019-00760,
`which were filed after November 13, 2018, we apply the standard set forth in
`Phillips. We note, however, that we would reach the same results under
`either standard.
`
`11
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`“Data Block”
`1.
`Petitioner asks that we construe “data block” as “a single unit of data
`which may range in size from individual bits through complete files or
`collection of multiple files.” Pet. 16–17. Patent Owner agrees with this
`construction. PO Resp. 9. For purposes of this decision, we agree and adopt
`Petitioner’s construction of “data block.”
`
`“Parameter”
`2.
`The parties dispute the correct construction of the term “parameter,”
`which is found in the independent claims. Petitioner contends that the term
`should be construed as “any recognizable data token or descriptor.” Pet. 17–
`18. Patent Owner argues that Petitioner is incorrect and that a person of
`ordinary skill in the art “would readily understand ‘parameter’ in the context
`of the ’535 [P]atent and understand that no construction is necessary.” PO
`Resp. 10. We determine that an explicit construction of the term is not
`necessary for determining whether Petitioner has demonstrated that the
`challenged claims are unpatentable.
`
`3. asymmetric compressors / “asymmetric data compression”
`Petitioner argues that the terms asymmetric compressor and
`asymmetric data compression refer to “an algorithm where compression of
`data and decompression of that compressed data take different amounts of
`time.” Pet. 19. Patent Owner, relying on what it contends is a definition of
`the terms, argues that the terms should be construed to mean a “compression
`algorithm in which the execution time for compression and decompression
`differ significantly.” PO Resp. 12.
`
`12
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`We determine that an explicit construction of the terms is not
`necessary for determining whether Petitioner has demonstrated that the
`challenged claims are unpatentable.
`
`4. access profile
`Petitioner asks the Board to construe “access profile” as “information
`that enables a controller to determine a compression routine that is
`associated with a data type of the data to be compressed.” Pet. 19–20.
`Patent Owner proposes construing the term to mean: “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).” PO Resp. 12–13. We also asked the
`parties to address the construction for “access profile” proposed by the
`petitioner in IPR2018-01169, Netflix, Inc. See Paper 17, 4. Netflix argued
`that the term should be construed as “information regarding the number of
`reads or writes.” PO Resp. 18.
`Both parties take their constructions from the same paragraph of the
`Specification. In particular, the Specification states:
`In another aspect, a system for providing bandwidth
`sensitive data compression comprises a plurality of
`access profiles, operatively accessible by the
`controller that enables the controller to determine a
`compression routine that is associated with a data
`type of the data to be compressed. The access
`profiles comprise information that enables the
`controller to select a suitable compression algorithm
`that provides a desired balance between execution
`
`13
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`speed (rate of compression) and efficiency
`(compression ratio).
`Ex. 1001, 8:4–12.
`
`
`Citing additional portions of the Specification, Petitioner argues that
`an access profile “is information that associates a compression routine with a
`data type.” Pet. 19 (citing Ex. 1001, 13:1–4, 11:25–40). Patent Owner
`responds that its construction (also taken from the ’535 Patent) is consistent
`with how the Specification uses “access profiles.” PO Resp. 13. Patent
`Owner contends that the system may select an appropriate compression
`algorithm to optimize system throughput based on the data being
`compressed and that “[b]y allowing the controller to select a suitable
`compression algorithm that provides a desired balance between compression
`speed and efficiency, access profiles allow the system to optimize system
`throughput.” Id. (citing Ex. 1001, 7:51–55, 14:27–39). Patent Owner
`submits that its construction is consistent with the claim language and the
`examples in the Specification. Id. at 13–16 (citing Ex. 1001, 11:19–12:67);
`Sur-Reply 2. Patent Owner objects to Petitioner’s construction for
`improperly importing limitations from the Specification into the claims. Id.
`at 16. Patent Owner argues that the Specification does not define “access
`profile” in terms of “data type” and there is no definition or disclaimer in the
`Specification or prosecution history that supports Petitioner’s construction.
`Id. In particular, Patent Owner objects to the inclusion of “data type” as
`improper. Id. at 16–17. Patent Owner also objects to the claim construction
`proposed by the petitioner in IPR2018-01169—“information regarding the
`number or frequency of reads or writes”—as improperly narrow. Id. at 18.
`
`14
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`Patent Owner argues that information about reads and writes alone is
`insufficient to select a suitable compressor. Id. at 19–20.
`As an initial matter, we agree with both parties that Netflix’s proposed
`construction from IPR2018-01169 is too narrow. As we explained in detail
`in our Final Written Decision in IPR2018-01169, the term “access profile” is
`broad enough to include information regarding reads or writes, but not
`limited to that. IPR2018-01169, Paper 45, 12–13 (Final Written Decision).
`Thus, for the reasons explained in IPR2018-01169, we decline to adopt
`Netflix’s proposed construction for purposes of this proceeding. See id.
`at 14.
`
`We also agree with Patent Owner that Petitioner’s construction is too
`narrow in that it seems to limit “access profile” to “data type,” when there
`are examples in the Specification using access frequency. See Ex. 1001,
`11:25–12:67. The specification of the ’535 Patent provides several
`examples of access profiles that use the number and/or frequency of reads or
`writes to enable controller 11 to select a suitable compression algorithm
`based on data type. See Ex. 1001, 11:29–12:50. Yet, we agree with
`Petitioner that “data type” can be information included in an “access
`profile.” The Specification includes access profiles based on data type. See
`id. at 11:29–44; 14:37–49 (“Alternatively, the system can detect the type of
`data being installed or stored to disk (via file extension, etc.) and
`automatically select an appropriate algorithm using the Access Profile
`information as described above.”). Patent Owner’s arguments that the
`references to “data type” are only in the context of “data profiles,” not
`“access profiles,” is not persuasive because the Specification indicates that
`“data profiles” are a type of access profile and should be included in the
`
`15
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`broader category. See Ex. 1001, 11:32–35 (“[D]ata profiles 15 comprise
`information regarding predetermined access profiles of different data sets
`. . . .”); see also id. at 11:35–49 (using “access profile” and “data profile”
`interchangeably). Therefore, although we decline to limit the claim
`construction to data type or number of reads or writes, we note that data type
`and number of reads or writes are examples of such “access profile”
`information. Similarly, the Specification does not indicate that “access
`profiles” must be correlated with a “balance between execution speed (rate
`of compression) and efficiency (compression ratio)” as proposed by Patent
`Owner. Although the ʼ535 Patent states “[t]he access profiles comprise
`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),” the Specification also
`states that the “plurality of access profiles” is “operatively accessible by the
`controller that enables the controller to determine a compression routine that
`is associated with a data type of the data to be compressed.” Ex. 1001, 8:4–
`13. Thus, in context, the statement Patent Owner relies upon is merely
`descriptive of the intended use of the access profiles, rather than a definition.
`See IPR2018-01169, Paper 45, 13.
`Therefore, based on our reading of the ’535 Patent and its prosecution
`history, we determine that “access profile” encompasses “information, such
`as the number or frequency of reads or writes or data type, that enables
`selection of a suitable compression algorithm.”5
`
`5 After the oral hearing and in response to our questions about whether there
`were any other constructions we should be aware of (see Tr. 18:6–19:7),
`Patent Owner submitted a paper apprising us of Judge Wu’s construction in
`Realtime Adaptive Streaming LLC v. Google LLC, CV 2:18-3629-GW(JCx))
`
`16
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`IV. ANALYSIS
`Petitioner contends Dvir anticipates claims 1, 2, 9, 10, and 14, and
`also would have rendered the subject matter of claims 1, 2, 9, 10, and 14
`obvious to one of ordinary skill in the art at the time of the invention.
`Pet. 27–42. Petitioner further contends that the combination of Dvir and
`Ishii would have rendered the subject matter of claims 3–6, 8, 11, and 12
`obvious to one of ordinary skill in the art at the time of the invention. Id.
`at 42–65.
`Petitioner bears the burden of establishing the unpatentability of any
`claim by a preponderance of the evidence. 35 U.S.C. § 316 (e); 37 C.F.R.
`§ 42.1(d). This burden of persuasion never shifts to the patent owner.
`Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378
`(Fed. Cir. 2015). With that burden in mind, we turn now to Petitioner’s
`challenges.
`
`
`(C.D. Cal.). See Paper 42. Although this construction had issued five
`months earlier and before Patent Owner submitted its Sur-Reply, Patent
`Owner offered to submit additional briefing on whether to adopt the district
`court’s construction. We decline to allow Patent Owner an opportunity to
`re-open the claim construction briefing over something it was aware of for
`months and submitted only after our prompting. See Tr. 18:6–19:7.
`Moreover, Patent Owner has repeatedly opposed the adoption of a
`construction related to number of reads/writes before the Board. See PO
`Resp. 18–20. Because no party advocated for it, and we do not agree that
`“access profile” should be limited to number of reads/writes, we decline to
`adopt Judge Wu’s construction for purposes of this proceeding. See Paper
`42, 1–2. Although we generally agree with Judge Wu’s point that the
`construction should reflect not only what an “access profile” is intended to
`do, see Ex. 2019, 12, but also what it contains, we believe that limiting the
`construction to only read and writes is too narrow.
`
`17
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`A. Overview of Dvir
`Dvir is entitled “Method for Enhancing Video Compression Through
`Automatic Data Analysis and Profile Selection.” Ex. 1004, code [54]. Dvir
`discloses a system and method “for rapid video data compression and
`transmission for a wireless remote monitor.” Id. at Abstract. Dvir’s method
`allows the compression method to be adjusted according to the type of
`software application which generated the video data, and according to the
`characteristics of the data itself. Id. Dvir discloses that the type and profile
`of video data compression is selected by a profile manager, which detects
`the characteristics of the video data to determine the character of the data,
`and then selects the video data compression method and profile according to
`the video data character. Id.
`Dvir matches the compression algorithm to a data type by performing
`the following steps:
`(a) providing a plurality of different multimedia data compression
`procedures, each of the compression procedures being associated with a
`profile of characteristics of the multimedia data;
`(b) receiving the multimedia data to be compressed to form received
`
`data;
`
`(c) determining at least one characteristic of the received data;
`(d) selecting a profile according to the at least one characteristic; and
`(e) compressing the received data according to a compression
`procedure associated with the profile.
`Ex. 1004, 2:64–3:21.
`Dvir shows this compression selection technique in Figure 1b,
`reproduced below.
`
`18
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`
`
`Figure 1b shows a flow chart of the compression selection technique of Dvir.
`Id. at 5:6–11.
`Dvir explains that for each received data “sample,” Dvir’s
`compression system determines a “parameter” or “characteristic” of the data
`such as “a number of unique colors in the screen, a presence of static dark
`thin rows of pixels or large static blocks, and a level of motion in the screen
`between one frame and the next frame.” Id. at 5:36–42; see also id. at
`4:66–5:11. A “compression profile manager” then “selects a suitable
`compression profile for compressing the video data, according to the
`characteristics of the display data.” Id. at 5:8–10; see also id. at 5:43–5:51.
`Dvir’s selected compression algorithms include an asymmetric compression
`algorithm. For example, Dvir states that “the actual process of compression
`is performed by an MPEG (Motion Picture Expert Group) encoder . . . or
`other type of compression algorithm.” Ex. 1004, 5:14–24; see also id. at
`Fig. 3a.
`Finally, Dvir uses the “compression profile” to “select the particular
`type of video compression method for compressing the display data.”
`
`19
`
`

`

`IPR2018-01342
`Patent 8,934,535 B2
`
`Ex. 1004, 4:66–5:3; see also id. at 6:43–45. Dvir, therefore, automatically
`creates a specifically tailored “compression procedure” for each set of
`multimedia data. Id. at 2:31–49; Ex. 1003 ¶¶ 67–72.
`
`B. Overview of Ishii
`Ishii is entitled “File Compression Processor Monitoring Current
`Available Capacity and Threshold Value” and relates to a file compression
`processor that records image and text data to a recording media after data
`compression. Ex. 1005, code [54], 1:10–15. Ishii’s file compression
`processor comprises a file status monitor that keeps track of the current
`available capacity on the file unit and an upper limit threshold value of
`available capacity that is always to be ensured. Id. at Abstract, 1:56–60.
`When the current available file capacity is greater than the threshold value,
`files are not

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket