throbber
Trials@uspto.gov
`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

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