`Tel: 571-272-7822
`
`Paper No.20
`Entered: January 17, 2019
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`NETFLIX, INC.,
`Petitioner,
`v.
`REALTIME ADAPTIVE STREAMING, LLC,
`Patent Owner.
`
`Case IPR2018-01169
`Patent 8,934,535 B2
`
`
`
`
`
`
`
`
`
`Before KEVIN W. CHERRY, GARTH D. BAER, and
`NABEEL U. KHAN, Administrative Patent Judges.
`KHAN, Administrative Patent Judge.
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`
`I.
`
`INTRODUCTION
`A. Background
`Netflix, Inc.1 (“Petitioner”) filed a Petition (Paper 8, “Pet.”) to
`institute an inter partes review of claims 1–14 (the “challenged claims”) of
`U.S. Patent No. 8,934,535 B2 (Exhibit 1001, “the ’535 Patent”). Realtime
`Adaptive Streaming, LLC (“Patent Owner”) has filed a Preliminary
`Response. (Paper 19, “Prelim. Resp.”). We have authority under 37 C.F.R.
`§ 42.4(a) and 35 U.S.C. § 314, which provides that an inter partes review
`may not be instituted unless the information presented in the Petition “shows
`that there is a reasonable likelihood that the petitioner would prevail with
`respect to at least 1 of the claims challenged in the petition.” Having
`considered the arguments and the associated evidence presented in the
`Petition, for the reasons described below, we institute inter partes review of
`all the challenged claims on the grounds set forth in the Petition.
`
`B. Related Proceedings
`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 Corporation 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.)
`
`
`1 The Board has granted Amazon.com Inc. and Hulu, LLC’s Joint Motion to
`Terminate Inter Partes Reviews as to Amazon.com, Inc. and Hulu, LLC.
`Paper 18. Thus, Netflix is the sole remaining Petitioner in this proceeding.
`
`2
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`
`• 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.)
`• 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 (D.C. 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.)
`
`3
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`
`• 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. 63–65; Paper 9, 2–4.
`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-01170
`
`
`
`C. The ʼ535 Patent
`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.
`
`4
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`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
`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
`
`5
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`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
`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 utilize
`an asymmetric algorithm that provides 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.
`
`6
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`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–
`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.
`
`
`D. Illustrative Claim
`Of the challenged claims, claims 1 and 14 are independent. Claims 2–
`13 depend directly or indirectly from claim 1.
`Claims 1 and 6, reproduced below, are 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
`
`7
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`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.
`
`
`
`The method of claim 1, further comprising:
`6.
`storing at least a portion of the one or more compressed
`
`data blocks.
`
`E. Asserted Grounds of Unpatentability
`Petitioner challenges claims 1–14 of the ʼ535 Patent on the following
`grounds:
`
`Basis Challenged Claims
`§ 103 1–14
`
`References
`Imai2 and Ishii3
`
`
`
`F. Level of Ordinary Skill
`Petitioner proposes that a person of ordinary skill
`would have a bachelor’s degree in electrical engineering,
`computer science, or a similar field with at least two years of
`experience in data compression or a person with a master’s
`degree in electrical engineering, computer science, or a similar
`field with a specialization in data compression. Ex. 1003 at 65.
`A person with less education but more relevant practical
`experience may also meet this standard. Ex. 1003 at 65.
`
`
`2 Imai, Japanese Patent Application Publication No. H11331305, published
`Nov. 30, 1999. (Ex. 1004). A Certified English translation of Exhibit 1004
`was submitted as Exhibit 1005. Citations to “Imai” herein refer to the
`translation.
`3 Ishii, U.S. Patent No. 5,675,789, Oct. 7, 1997 (Exhibit 1007, “Ishii”).
`
`8
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`Pet. 7. Patent Owner does not propose a level of ordinary skill. For
`purposes of this Decision, we adopt Petitioner’s proposed level of ordinary
`skill.
`
`G. Claim Interpretation
`In an inter partes review, we construe claim terms in an unexpired
`patent according to their broadest reasonable construction in light of the
`specification of the patent in which they appear. 37 C.F.R. § 42.100(b)4;
`Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–46 (2016)
`(upholding the use of the broadest reasonable interpretation standard).
`“Under a broadest reasonable interpretation, words of the claim must be
`given their plain meaning, unless such meaning is inconsistent with the
`specification and prosecution history.” Trivascular, Inc. v. Samuels, 812
`F.3d 1056, 1062 (Fed. Cir. 2016). Only terms that are in controversy need to
`be construed, and only to the extent necessary to resolve the controversy.
`See Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361 (Fed. Cir.
`2011); Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed.
`Cir. 1999).
`The determination made below with respect to each of the claim terms
`does not preclude the parties from arguing their proposed constructions of
`
`
`4 The revised claim construction standard for interpreting claims in inter
`partes review proceedings as set forth in the final rule published October 11,
`2018, does not apply to this proceeding, because the new “rule is effective
`on November 13, 2018 and applies to all IPR, PGR, and CBM petitions filed
`on or after the effective date.” 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) (to be codified at 37
`C.F.R. pt. 42).
`
`9
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`the claims during trial. Indeed, the parties are hereby given notice that claim
`construction, in general, is an issue to be addressed at trial. A final
`determination as to claim construction will be made at the close of the
`proceeding, after any hearing, based on all the evidence of record. The
`parties are expected to assert all their claim construction arguments and
`evidence in the Petition, Patent Owner’s Response, Petitioner’s Reply, or
`otherwise during trial, as permitted by our rules.
`
`1. asymmetric compressors / compressors using asymmetric data
`compression
`Petitioner argues that “[a] POSITA would have understood that the
`terms ‘asymmetric compressor(s)’ (Claims 12, 15, 16, and 24–26) and
`‘compressors using asymmetric data compression’ (Claims 1, 10, and 27) in
`view of the specification, mean ‘a compression algorithm in which the
`execution time for the compression and decompression routines differ
`significantly.’” Pet. 7.
`Patent Owner agrees with Petitioner’s construction, pointing out only
`that Petitioner’s construction is in singular form, while the terms being
`construed are in plural form. Prelim. Resp. 4. Thus, Patent Owner proposes
`the terms should be construed as “compressors in which the execution time
`for the compression and decompression routines differ significantly.”
`Prelim. Resp. 4.
`We determine that an explicit construction of the terms is not
`necessary for the purposes of determining whether there is a reasonable
`likelihood that the Petitioner would prevail with respect to at least one of the
`claims challenged in the Petition.
`
`10
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`
`2. data block
`Petitioner proposes that “data block” be construed as “a unit of data
`comprising more than one bit.” Pet. 8. Patent Owner largely “agrees with
`Petitioner’s construction except that a ‘data block’ can be a single bit.”
`Prelim. Resp. 4. Thus, Patent Owner proposes that a “data block” be
`construed as “a unit of data comprising one or more bits.” Prelim. Resp. 5.
`We determine that an explicit construction of the term is not necessary
`for the purposes of determining whether there is a reasonable likelihood that
`the Petitioner would prevail with respect to at least one of the claims
`challenged in the Petition.
`
`3. access profile
`Petitioner argues access profile should be construed as “information
`regarding the number or frequency of reads or writes.” Pet. 10.
`Specifically, Petitioner argues that an access profile “contains information
`regarding accesses—or a number or frequency of reads or writes.” In other
`words, Petitioner argues that the term “access” refers to either reads or
`writes. Pet. 11.
`Patent Owner does not propose a construction for the term, but argues
`that Petitioner’s construction is, nonetheless, incorrect. Prelim. Resp. 5–9.
`Initially, Patent Owner notes that “the ʼ535 patent describes access profiles
`without using any of the words in Petitioner’s construction,” namely, the
`ʼ535 Patent “description says nothing about ‘the number or frequency of
`reads or writes’—as Petitioner’s construction would require.” Prelim.
`Resp. 5–6. Patent Owner further argues that, in the embodiments of the ʼ535
`Patent, “the access profile contains information about writes and reads
`relative to each other . . . . But under Petitioner’s construction, an access
`
`11
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`profile could contain information only about reads or only about writes. This
`information would be insufficient to select a suitable compressor.” Prelim.
`Resp. 8.
`We construe the term “access profile” to mean “information regarding
`the number or frequency of reads or writes.” The ʼ535 Patent uses the term
`“access” to refer to either a read or write of data. See, e.g., Ex. 1001, 11:25–
`12:65 (describing access profiles as containing information regarding read
`and writes of data). Thus, information regarding a read or a write could be
`included in the access profile. We find no support for restricting the access
`profile to include information about both reads and writes or information
`about the two relative to each other. While it is true that the three access
`profile examples provided in the ʼ535 Patent each keep track of the
`frequency of both reads and writes, it is improper to import limitations from
`these examples into the claims. In re Am. Acad. of Science Tech Ctr., 367
`F.3d 1359, 1369 (Fed. Cir. 2004) (“We have cautioned against reading
`limitations into a claim from the preferred embodiment described in the
`specification, even if it is the only embodiment described, absent clear
`disclaimer in the specification.”) Instead, by tracking both reads and writes,
`the examples from the ʼ535 Patent illustrate that the access profile would
`certainly be able to track either one of them separately.
`
`II. DISCUSSION
`A. Overview of Imai
`Imai is related to encoding and transmitting digital signals to the
`receiving side where they are decoded and reproduced in real time.
`Ex. 1005 ¶ 1. Real time encoding, transmitting, and decoding can present
`several problems though. For example, the transmission rate of the network
`
`12
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`can vary and drop below the data rate of the coded data which leads to the
`encoded digital signals arriving too late. Ex. 1005 ¶ 3. The hardware
`capabilities or decoding method of the receiving device can also slow down
`real time decoding of the received signals. Ex. 1005 ¶ 4. To address these
`problems, Imai includes a plurality of coding methods and selects the
`appropriate coding method to encode the digital signals, or part of the digital
`signals, based on certain relevant factors. Ex. 1005 ¶ 7. The digital signals
`Imai is particularly concerned with are audio signals, and the plurality of
`coding methods can include PCM, ADPCM, layers 1, 2, 3, of MPEG,
`ATRAC, ATRAC2, and HVXC. See Ex. 1005 ¶ 67. The factors that can
`affect which coding method is used include the processing capability of the
`receiving device (see Ex. 1005, Fig. 9, ¶¶ 88–99), transmission rate of the
`network (see Ex. 1005 ¶¶ 145–166), and the audio content of the audio
`signals (see Ex. 1005 ¶¶ 101–102). For example, Imai describes a situation
`where the audio signal is predominantly voice, in which case HVXC may be
`appropriately used as the coding method. On the other hand, if the audio
`signal is predominantly instrument sounds, then ATRAC may be
`appropriately used as the coding method. Ex. 1005 ¶ 102.
`Imai discloses at least two embodiments of its invention. The first,
`illustrated in Figure 5, is an embodiment where audio signals are encoded
`(compressed) using a chosen encoder and transmitted to the client. See, e.g.,
`Ex. 1005 ¶¶ 65–74. This embodiment is referred to by the Petitioner as the
`“compress and transmit embodiment.” See, e.g., Pet. 18. The second,
`illustrated in Figure 16, is an embodiment where the audio signal is encoded
`using each of the available encoding methods and the resulting output is
`stored on the server. See, e.g., Ex. 1005 ¶¶ 165–171. This embodiment is
`
`13
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`referred to by Petitioner as the “compress and store embodiment.” See, e.g.,
`Pet. 18.
`
`B. Overview of Ishii
`Ishii is related to a file compression processor that records image and
`text data to a recording media after data compression. Ex. 1007, 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. Ex. 1007,
`Abstract, 1:56–60. When the current available file capacity is greater than
`the threshold value, files are not compressed and, in some embodiments,
`certain files with high access frequency are decompressed. Ex. 1007, 6:65–
`7:3. When the current available file capacity is below the threshold the
`system searches for files with a lower access frequency and compresses
`them. An appropriate data compression method is selected based on access
`frequency and file type. Ex. 1007, 5:43–50, 5:60–65. For example, a
`compression method with shorter compression and decompression times is
`selected for files that are accessed frequently and a compression method
`with a higher compression ratio (and typically longer compression times) is
`selected for files with lower access frequency. Ex. 1007, 6:12–17.
`
`C. Reason to Combine Imai and Ishii
`1. Petitioner’s Contentions
`Petitioner argues a person of ordinary skill in the art would have
`combined Imai with Ishii because the combination “would improve upon
`Imai’s system by adding the capability to track the frequency with which
`Imai’s digital signals are requested by the client as taught by Ishii and would
`
`14
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`modify Imai’s compression algorithm selection logic to consider the
`frequency of access as taught by Ishii.” Pet. 18.
`In Imai, the factors considered in determining which compression
`algorithm to select includes “the content of the data, the data type, the
`processing ability of the client, and the throughput of a communications
`channel.” Pet. 19 (citing Ex. 1005 ¶¶ 88–102, 149–160; Ex. 1003, ¶ 117).
`In Ishii, the factors considered “include a ‘data attribute (whether it is text
`data or binary data)’ and ‘access frequency.’” Pet. 20 (citing Ex. 1007,
`5:66–6:6). According to Petitioner, “[t]he combined system yields the
`predictable result of having a more complete set of compression algorithm
`selection criteria that will improve the system’s ability to choose the most
`suitable algorithm for compressing a given data set.” Pet. 20 (citing Ex.
`1003 ¶ 119).
`Petitioner also argues that one of ordinary skill would have used the
`number of reads and writes in selecting a compression algorithm, as taught
`in Ishii, with the selection criteria of Imai, because “a POSITA would have
`known and Imai in fact teaches, one of the limiting factors in compression
`systems would have been the processing capacity of the overall system.”
`Pet. 21 (citing Ex. 1005 ¶ 167; Ex. 1003 ¶ 120). Petitioner explains that
`“[u]sing the number of read/writes of a data file for selection of a more
`symmetric/less symmetric algorithm would assist in this goal by reducing
`the scale necessary for the server and the overall workload of the system.”
`Pet. 21 (citing Ex. 1005 ¶ 170).
`
`2. Patent Owner’s Arguments
`Patent Owner argues Petitioner has not explained “how a POSA
`would combine the system in Imai Fig. 5 with Ishii’s teachings of (i)
`
`15
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`tracking access frequency and (ii) encoder selection based on access
`frequency.” Prelim. Resp. 18–19. Patent Owner argues Imai discloses a
`real-time system that “create[s] frames on the fly.” Prelim. Resp. 19. Ishii,
`on the other hand, “describes a long-term static system in which the data
`blocks were created some time ago and monitored over time” so that the
`access frequency of the file can be determined and an appropriate
`compression algorithm can then be selected. Prelim. Resp. 19 (citing
`Ex. 1007, 5:51–56). Because the frames in Imai are newly created when a
`compression algorithm is selected, Patent Owner argues “Ishii’s long-term
`file monitoring features would not fit within this system.” Prelim. Resp. 20.
`Patent Owner also argues that combining Imai’s real-time system with
`Ishii’s long-term static system would render Imai inoperable for its intended
`purpose. Prelim. Resp. 21–23.
`Patent Owner also takes issue with the combination of Imai’s
`Figure 16 embodiment and Ishii. Patent Owner argues that there is no
`encoder selection at all in Imai’s Figure 16 embodiment, “[t]hus Ishii’s
`teachings of (i) tracking access frequency and (ii) encoder selection based on
`access frequency are irrelevant.” Prelim. Resp. 21.
`
`3. Analysis
`At this stage of the proceeding, we find Petitioner has “articulated
`reasoning with some rational underpinning” for combining Imai with Ishii.
`In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016)
`(“To satisfy its burden of proving obviousness . . . [t]he petitioner must . . .
`articulate specific reasoning, based on evidence of record, to support the
`legal conclusion of obviousness.” (citing KSR Int’l Co. v. Teleflex Inc., 550
`U.S. 398, 418 (2007))). Petitioner explains that Imai and Ishii are both
`
`16
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`directed to systems that select a compression algorithm from a plurality of
`algorithms, including asymmetric algorithms, based on a variety of factors.
`Pet. 18–19. Petitioner also explains that Ishii includes frequency of access
`as one factor when selecting a compression algorithm and that this factor
`could be added to Imai’s other factors by one of ordinary skill in the art.
`Petitioner provides motivation for doing so by indicating that the modified
`system would have a more complete set of selection criteria resulting in an
`improved ability to select the most suitable compression algorithm. Pet. 20.
`We disagree with Patent Owner’s argument that one of ordinary skill
`could not combine Imai’s real-time system with Ishii’s “static system.”
`Central to Patent Owner’s contention is the fact that Imai creates frames
`from an audio signal “on the fly” and that these frames, therefore, do not
`have an associated access frequency because they are newly created. Prelim.
`Resp. 19. However, this argument does not address Petitioner’s proposed
`combination. In particular, Petitioner appears to be relying on the frequency
`of requests for Imai’s digital signals, not requests for the frames that are
`created from those signals, in its combination. See Pet. 18. Ishii’s teaching
`of access frequency could be applied to Imai’s digital signals because they
`exist in advance of the client’s request and thus could be tracked for a long
`enough period of time to determine an access frequency.
`Moreover, Patent Owner’s argument is based on a strict incorporation
`of Ishii’s file attribute controller with Imai’s frame cutting circuit. See
`Prelim. Resp. 19. However, “[t]he test for obviousness is not whether the
`features of a secondary reference may be bodily incorporated into the
`structure of the primary reference. . . . Rather, the test is what the combined
`teachings of those references would have suggested to those of ordinary skill
`
`17
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`in the art.” In re Keller, 642 F.2d 413, 425 (CCPA 1981). Here, Ishii’s
`teaching of using access frequency as a factor in selecting an encoder would
`suggest to a person of ordinary skill that the frequency that a particular audio
`signal is requested (i.e. accessed) could be used as a factor in selecting the
`appropriate compression algorithm for the frames created from the audio
`signals.
`We also disagree with Patent Owner’s argument that Imai’s Figure 16
`embodiment could not be combined with Ishii. Prelim. Resp. 21. Again, the
`argument does not fully address the actual combination proposed by
`Petitioner. Petitioner does not propose a combination of the Figure 16
`embodiment directly with Ishii. Rather, Petitioner proposes to combine
`Imai’s Figure 5 embodiment, as modified by Imai’s Figure 16 embodiment,
`with Ishii. Pet. 43. In the modified embodiment, a selection of an encoder
`would actually occur, and thus frequency of access could be considered as a
`factor in such a selection.
`
`D. Independent Claims 1 and 14
`1. Petitioner’s Contentions
`Claim 1 recites “determining a parameter or attribute of at least a
`portion of a data block having audio or video data.” Claim 14 recites a
`similar limitation. Petitioner argues both Imai and Ishii teach this limitation.
`Imai does so by “consider[ing] the level of the voice as compared to a level
`of the instrument sounds in a portion of a data block[.]” Pet. 24 (citing
`Ex. 1005 ¶ 102). Ishii determines a parameter or attribute of a data block by
`tracking file attributes such as a data attribute (e.g., text data file, program
`file or image data file) and number of accesses of the file. Pet. 25 (citing
`Ex. 1007, 6:20–31). Petitioner argues that the data blocks of Imai have
`
`18
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`audio or video data (Pet. 25 (citing Ex. 1005 ¶¶ 67, 102, 172)) and that one
`of skill in the art would know that the binary data of Ishii could be audio or
`video data (Pet. 26–27).
`Claim 1 further recites “selecting an access profile from among a
`plurality of access profiles based upon the determined parameter or
`attribute.” Claim 14 recites a similar limitation. Petitioner argues Ishii
`teaches this limitation by selecting an appropriate compression method
`“based on the ‘access frequency and file type’ of the file to be compressed.”
`Pet. 27 (citing Ex. 1007, 5:60–65). In Ishii, “the ‘access frequency . . . is
`given as high, medium and low’ and is ‘set in the file search portion.’”
`Pet. 28 (citing Ex. 1007, 5:54–59). According to Petitioner the access
`frequency of high, medium, and low teaches the claimed “access profile”
`which is selected based on parameters or attributes such as file type and
`number of accesses. Pet. 28.
`Claim 1 further recites “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.”
`Claim 14 recites a similar limitation. Petitioner argues “Ishii teaches using
`the information from the selected access profile to choose the asymmetric
`data compressor and compress a data block.” Pet. 29 (citing Ex. 1003, 141–
`143). In particular, Petitioner points out that Ishii teaches “[t]he file
`compression method selection portion 104 . . . selects the method with
`suitable compression ratio and compression/decompression speed depending
`on the file access frequency and data attribute.” Pet. 29 (Ex. 1007, 7:17–20).
`
`19
`
`
`
`IPR2018-01169
`Patent 8,934,535 B2
`In other words, according to Petitioner, “Ishii stores information regarding
`how to classify a file as having ‘high, medium [or] low’ access frequency in
`the file search portion 102 and then that access frequency classification is
`used in Step 250 to pick the specific compressor to use.” Pet. 30.
`Both Ishii and Imai teach the use of asymmetric compressors,
`according to Petitioner. For example, Petitioner argues “Ishii identifies a
`number of exemplary compressors, including: . . . Lempel-Ziv” and that
`Lempel-Ziv is an asymmetric compression algori