`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