IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––
`
`ARRIS SOLUTIONS, INC.,
`Petitioner,
`
`v.
`
`REALTIME ADAPTIVE STREAMING LLC,
`Patent Owner
`
`––––––––––
`
`Case IPR2019-00674
`Patent 8,934,535
`
`––––––––––
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 8,934,535
`
`

`

`IV.
`
`V.
`
`VI.
`
`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`TABLE OF CONTENTS
`
`I.
`II.
`III.
`
`Introduction ...................................................................................................... 1
`Grounds for Standing ....................................................................................... 1
`Identification of Challenge .............................................................................. 2
`A.
`Priority Date .......................................................................................... 2
`B.
`Prior Art ................................................................................................. 2
`C.
`Statutory Grounds.................................................................................. 3
`D.
`This Petition is Not Redundant ............................................................. 3
`Summary of the ’535 Patent ............................................................................ 4
`A.
`Overview ............................................................................................... 4
`B.
`Prosecution History ............................................................................... 5
`Claim Construction .......................................................................................... 6
`A.
`Level of Ordinary Skill in the Art ......................................................... 7
`B.
`“asymmetric compressors” / “compressors using asymmetric data
`compression” ......................................................................................... 7
`C.
`“data block” ........................................................................................... 8
`D.
`“access profiles” ..................................................................................10
`Summary of the Prior Art ..............................................................................12
`A.
`Overview of Imai (Ex. 1005) ..............................................................12
`B.
`Overview of Ishii (Ex. 1007)...............................................................15
`VII. Challenged Claims 1-14 are Unpatentable ....................................................18
`A.
`Ground 1: Claims 1-14 are Obvious in View of Imai and Ishii ..........18
`1. A POSITA Would Have Combined Imai and Ishii .......................18
`2. Independent Claim 1 is Obvious ....................................................22
`3. Independent Claim 14 is Obvious ..................................................35
`4. Dependent Claim 2 is Obvious ......................................................38
`5. Dependent Claim 3 is Obvious ......................................................40
`6. Dependent Claims 10 and 11 are Obvious .....................................41
`7. Dependent Claim 6 is Obvious ......................................................42
`
`- i -
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`8. Dependent Claims 4 and 5 are Obvious .........................................50
`9. Dependent Claim 7 is Obvious ......................................................51
`10.Dependent Claim 8 is Obvious ......................................................55
`11.Dependent Claim 9 is Obvious ......................................................58
`12.Dependent Claim 12 is Obvious ....................................................60
`13.Dependent Claim 13 is Obvious ....................................................61
`VIII. Conclusion .....................................................................................................62
`IX. Mandatory Notices and Fees .........................................................................63
`
`- ii -
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`Exhibit No.
`1001
`1002
`1003
`1004
`
`1005
`1006
`1007
`1008
`
`1009
`
`1010
`
`1011
`1012
`1013
`
`1014
`
`1015
`1016
`
`EXHIBIT LIST
`
`Description
`U.S. Patent No. 8,934,535 to Fallon et al. (“’535 Patent”)
`Prosecution File History for the ’535 Patent
`Expert Declaration of James A. Storer
`Japanese Patent Application Publication No. H11331305 to Imai
`et al. (“Imai”).
`Certified English Translation of Imai
`U.S. Patent No. 6,507,611 to Imai et al. (“Imai ’611”)
`U.S. Patent No. 5,675,789 to Ishii et al. (“Ishii”)
`Excerpt from Andreas Spanias et al., Audio Signal Processing
`and Coding (John Wiley & Sons, Inc., 2007)
`Excerpt from Raymond Westwater et al., Real-Time Video
`Compression Techniques and Algorithms (Kluwer Academic
`Publishers, 1997)
`Excerpt from David Salomon, A Guide to Data Compression
`Methods (Springer-Verlag New York, Inc., 2002)
`International PCT Application Publication WO 00/51243 to Park
`U.S. Patent No. 5,873,065 to Akagiri et al.
`Memorandum Opinion and Order, Realtime Data, LLC v.
`Rackspace US, Inc. et al., No. 6:16-CV-00961, Dkt. 183 (E.D.
`Tex. June 14, 2017)
`Memorandum Opinion and Order, Realtime Data, LLC v. Actian
`Corp. et al., No. 6:15-CV-00463, Dkt. 362 (E.D. Tex. July 28,
`2016)
`U.S. Patent No. 6,195,024 to Fallon
`Notice of Interested Parties, Realtime Adaptive Streaming, LLC
`v. Hulu LLC, No. 2:17-CV-07611, Dkt. 18 (C.D. Cal. Oct. 24,
`2017)
`
`- iii -
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`I.
`
`INTRODUCTION
`Petitioner ARRIS Solutions, Inc., requests inter partes review of Claims 1-
`
`14 of U.S. Patent No. 8,934,535 (Ex. 1001). The ’535 Patent refers to methods for
`
`compressing data with an asymmetric data compressor. According to the ’535
`
`Patent, these techniques aim to increase the storage/retrieval bandwidth of mass
`
`storage devices which traditionally suffer from “profound read/write data rate
`
`limitations” that “severely limit” data-dependent applications. Ex. 1001 at 2:53-
`
`61.
`
`But the techniques of the ’535 Patent were known in the prior art well before
`
`the priority date of the ’535 Patent. Specifically, to obtain allowance of
`
`independent Claim 1, the Applicant added the feature of using “asymmetric data
`
`compression” to differentiate from anticipatory prior art. Ex. 1002 at 435, 411.
`
`Asymmetric compression algorithms and the ability to select between compression
`
`algorithms, however, were widely used in the compression field and extensively
`
`described in the prior art. Ex. 1003 at 74-78; see, e.g., Ex. 1005; Ex. 1007.
`
`II. GROUNDS FOR STANDING
`Petitioners certify that the ’535 Patent is eligible for inter partes review.
`
`Petitioners further certify that they are not barred or estopped from requesting this
`
`inter partes review on the grounds identified herein.
`
`1
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`III.
`
`IDENTIFICATION OF CHALLENGE
`
`A.
`
`Priority Date
`
`The application that led to the ’535 Patent was filed September 20, 2013 as
`
`U.S. Patent Application No. 14/033,245 and ultimately claims priority to U.S.
`
`Provisional Patent Application No. 60/268,394, filed February 13, 2001.
`
`Petitioners are unaware of any claim that the ’535 Patent is entitled to a priority
`
`date earlier than February 13, 2001.
`
`B.
`
`Prior Art1
`Exhibit 1004 – Japanese Patent Application Publication No. H11331305 to
`
`Imai et al. (“Imai”) is prior art under at least pre-AIA §§102(a) and (b) because it
`
`published November 30, 1999, which is over one year before the ’535 Patent’s
`
`earliest priority date (February 13, 2001). (Exhibit 1005 – certified English
`
`translation of Imai); (Exhibit 1006 – U.S. Patent No. 6,507,611 (“the Imai ’611
`
`Patent”) is the U.S. sibling of Imai). 2
`
`Exhibit 1007 – U.S. Patent No. 5,675,789 to Ishii et al. (“Ishii”) is prior art
`
`under at least pre-AIA §§102(a), (b), and (e) because it was granted and published
`
`1 The claims of the ’535 Patent claim the benefit of an application filing date
`before March 16, 2013. See Ex. 1001. Thus, the ’535 Patent is governed by pre-
`AIA 35 U.S.C. § 102. MPEP § 2159.02.
`2 The Imai ’611 Patent (Ex. 1006) claims priority to Imai and contains
`substantively identical figures and disclosures as Imai.
`
`2
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`as a patent on October 7, 1997, more than one year before the ’535 Patent’s earliest
`
`priority date (February 13, 2001).
`
`Statutory Grounds
`C.
`Petitioners request inter partes review on the following grounds:
`
`Ground
`No.
`
`References
`
`Statutory Basis
`
`Claims
`Challenged
`
`1
`
`Imai (Ex. 1005) in view of
`Ishii (Ex. 1007)
`
`Obviousness (§103)
`
`1-14
`
`This Petition is Not Redundant
`D.
`The factors identified in General Plastic Industrial Co., Ltd. v. Canon
`
`Kabushiki Kaisha, IPR2016-01357, Paper 19 (P.T.A.B. Sept. 6, 2017), do not
`
`provide a basis for denying institution of this petition. This is the first petition that
`
`challenges Claims 1-14 of the ’535 Patent. At this time, no patent owner
`
`preliminary response or institution decision has been filed in any proceeding
`
`challenging the ’535 Patent. Finally, Petitioners are unaware of any reason that the
`
`Board would be unable to timely issue a final written decision on this petition.
`
`3
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`IV.
`
`SUMMARY OF THE ’535 PATENT
`
`A.
`
`Overview
`
`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.” Ex. 1001 at 9:11-14, Abstract. Claims 1-13
`
`requires compressing audio or video data, while Claim 14 does not require “audio
`
`or video.” The ’535 Patent purports to identify and remediate “bottlenecks” in the
`
`throughput of a system by using different compression algorithms for data input to
`
`or output from a compression system. Ex. 1001 at 9:55-59. For example, the ’535
`
`Patent describes switching between asymmetric and symmetric algorithms, noting
`
`that asymmetric algorithms provide “a high compression ratio (to effectively
`
`increase the storage capacity of the hard disk) and fast data access (to effectively
`
`increase the retrieval rate from the hard disk).” Ex. 1001 at 13:6-8. On the other
`
`hand, symmetric routines “compris[e] a fast compression routine.” Ex. 1001 at
`
`14:17-20.
`
`Independent Claim 1 of the ’535 Patent attempts to claim the known concept
`
`of using different asymmetric encoders on different data blocks by using “access
`
`profiles” to select an encoder. The specification includes examples of access
`
`profiles in a table on Column 11, and explains that the system could detect the type
`
`of data being stored (via file extension, etc.) and select an appropriate algorithm by
`
`4
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`using the access profile information (such as the typical number of reads and writes
`
`for such files) to select a suitable compression algorithm based on the data type.
`
`Ex. 1001 at 14:36-45.
`
`The Examiner found the concept of access profiles to be anticipated during
`
`prosecution and the claims were only allowed after the concept of using
`
`“asymmetric” compression was added to Claim 1. See infra § IV.B. Similarly,
`
`independent Claim 14 was only allowed after adding the concept of using
`
`“asymmetric” compression. See infra § IV.B. Regardless, access profiles are
`
`taught by Ishii, which teaches using an access profile to selects a suitable
`
`compression algorithm based on the access frequency of a data block. Ex. 1003 at
`
`137-152.
`
`Although some dependent claims add the concept of storing compressed
`
`data blocks, that concept was well-known and disclaimed as being known in the
`
`prior art. Ex. 1001 at 2:44-46, cls. 5, 6, and 7.
`
`B.
`
`Prosecution History
`
`The application underlying the ’535 Patent was filed on September 20, 2013
`
`and claims priority to U.S. Provisional Patent Application No. 60/268,394, which
`
`was filed February 13, 2001. Ex. 1001. During prosecution, the claims of the ’535
`
`Patent were allowed after amendments to overcome rejections under 35 U.S.C.
`
`§§ 112(a) and 102 in response to one Office Action.
`
`5
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`Imai was not cited or considered during prosecution of the ’535 Patent.
`
`Although Ishii was cited by the Applicant during prosecution of the ’535 Patent,
`
`the Examiner did not rely on, cite to, or demonstrate any consideration of Ishii in
`
`any Office Action. Ishii was only referenced in an Information Disclosure
`
`Statement (“IDS”) submitted September 20, 2013 that listed 566 different US
`
`Patent documents, 848 different non-patent literature documents, and 27 different
`
`foreign patent documents. Ex. 1002 at 74-196.
`
`Petitioners are not aware of any objective evidence of non-obviousness for
`
`any of the challenged claims of the ’535 Patent.
`
`V.
`
`CLAIM CONSTRUCTION
`
`To the extent the Applicant has expressly defined a claim term in the
`
`specification, Petitioners have used that definition. For the purpose of deciding the
`
`grounds of invalidity presented by this petition,3 that the following terms should be
`
`construed: “asymmetric compression algorithm,” “data block,” and “access
`
`profile.”
`
`3 None of the claim construction issues that are necessary to resolve the invalidity
`grounds presented by this petition differ based upon the application of broadest
`reasonable
`interpretation versus
`the district court-type claim construction
`standards. Ex. 1003 at 90-91.
`
`6
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`A.
`
`Level of Ordinary Skill in the Art
`
`A person of ordinary skill in the art (“POSITA”) as of February 13, 2001
`
`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.
`
`B.
`
`“asymmetric compressors” / “compressors using asymmetric data
`compression”
`
`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.” See Ex. 1003 at 92-93. The claims
`
`recite, but do not define these terms. However, the specification defines these
`
`terms as: “[a]n asymmetrical data compression algorithm is referred to herein as
`
`one in which the execution time for the compression and decompression routines
`
`differ significantly.” See, e.g., Ex. 1001 at 9:62-10:8.
`
`7
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`Moreover, the specification gives examples of asymmetric and symmetric
`
`algorithms, stating that “dictionary-based compression schemes such as Lempel-
`
`Ziv” are asymmetric, while “table-based compression schemes such as Huffman”
`
`are symmetric. Ex. 1001 at 10:2-4 & 10:8-9.
`
`Accordingly,
`
`the Board should find
`
`that “asymmetric compression
`
`algorithm” means “a compression algorithm in which the execution time for
`
`compression and decompression differ significantly.” Ex. 1003 at 92-93.
`
`C.
`
`“data block”
`
`A POSITA would have understood that the term “data block” means “a unit
`
`of data comprising more than one bit.” See Ex. 1003 at 94-97. Starting with the
`
`claim language, “data block” is used consistently in the claims to refer to a unit of
`
`data that is compressed by a compression algorithm. Ex. 1001 at cls. 1, 14, 15, and
`
`27. The specification further explains that “[d]ata compression is widely used to
`
`reduce the amount of data required to process, transmit, or store a given quantity of
`
`information,” which indicates that a data block must be a unit large enough for
`
`there to be a chance to realize a reduction in size through compression. Ex. 1001
`
`at 2:40-46; Ex. 1003 at 94. The smallest unit of digital data representation is a bit,
`
`and the information contained in a single bit cannot be represented through
`
`compression with fewer bits. Ex. 1003 at 94. Therefore, a data block must be
`
`8
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`more than one bit in length so that it can be compressed as claimed. Ex. 1003 at
`
`94.
`
`The specification also supports this construction. It describes “block
`
`structured disk compression” as operating on blocks of data that are either “fixed”
`
`or “variable in size.” Ex. 1001 at 7:3-7. The ’535 Patent also states that data
`
`blocks can represent files, and that “[a] single file usually is comprised of multiple
`
`blocks, however, a file may be so small as to fit within a single block.” Ex. 1001
`
`at 7:5-7. The specification goes on to discuss the pros and cons of smaller and
`
`larger data block sizes. Ex. 1001 at 7:12-23. And it also contemplates units of
`
`data that comprise more than one bit that are stored in its system. Ex. 1001 at
`
`18:36-42, FIG. 4B (stating 2 bits are reserved for a sector map “type” definition,
`
`and 3 bits are reserved for “c type”). Thus, the discussion of various data block
`
`sizes, including file-sized data blocks and data units as small as 2 bits, are
`
`consistent with Petitioners’ proposed construction.
`
`The specification incorporates by reference U.S. Patent 6,195,024, which
`
`uses the term “data block” in a consistent manner:
`
`It is to be understood that the system processes the input
`data streams in data blocks that may range in size from
`individual bits through complete files or collections of
`multiple files. Additionally, the data block size may be
`fixed or variable. The counter module [] counts the size
`
`9
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`of each input data block (i.e., the data block size is
`counted in bits, bytes, words, any convenient data
`multiple or metric.
`
`Ex. 1015 at 7:5-15.
`
`In district court proceedings, the Patent Owner4 has twice stipulated to a
`
`similar, but narrower construction of this term. Ex. 1013 at 34; Ex. 1014 at 40
`
`(both evidencing Patent Owner’s agreement that “data block” means “a single unit
`
`of data, which may range in size from individual bits through complete files or
`
`collection of multiple files”). Thus, Petitioners’ proposed construction is
`
`consistent with Patent Owner’s own usage of the term.
`
`D.
`
`“access profiles”
`
`A POSITA would have understood that the term “access profile” means
`
`“information regarding the number or frequency of reads or writes.” Ex. 1003 at
`
`98. The term “access profile” appears in independent Claims 1 and 14, which both
`
`recite “determining a parameter or attribute of at least a portion of a data block”
`
`and then “selecting an access profile from among a plurality of access profiles
`
`based upon the determined parameter or attribute.” Ex. 1001 at cls.1, 14. In these
`
`claims, information from a portion of a data block is used to select an access
`
`4 The entity in those proceeding is Realtime Data, LLC rather than Realtime
`Adaptive Streaming LLC, the Patent Owner here. Ex. 1016.
`
`10
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`profile, and
`
`the “selected access profile” contains
`
`information regarding
`
`accesses—or a number or frequency of reads or writes—that is used to select the
`
`compression algorithm used to compress the portion of the data block. Ex. 1001 at
`
`cls. 1, 14. Thus, Petitioners’ construction is supported by the claim language.
`
`Furthermore, the ’535 Patent depicts each “access profile” as a description
`
`of the number or frequency of reads or writes of data:
`
`See Ex. 1001 at 8:4-13; 11:38-39, Tables on Columns 11 and 12.
`
`In specific examples, the specification makes clear that the “access profile”
`
`is used in conjunction with the detection of a data type:
`
`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. For
`
`11
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`instance, the user could indicate to the controller that the
`data being installed comprises an application program
`which the controller would determine falls under
`Access Profile 1. The controller would then command
`the compression engine
`to utilize an asymmetric
`compression algorithm employing a slow compression
`routine and a fast decompression.
`
`Ex. 1001 at 14:36-45. Thus, Petitioners’ construction is consistent with the
`
`intrinsic evidence. Ex. 1003 at 98-100.
`
`VI.
`
`SUMMARY OF THE PRIOR ART
`
`A.
`
`Overview of Imai (Ex. 1005)
`
`Imai is a Japanese Patent Application Publication filed by Sony that was
`
`neither cited nor considered during the prosecution of the ’535 Patent. Ex. 1001.
`
`Imai is directed to encoding digital data (including audio and video) for
`
`transmission to enable real time decompression and reproduction at a client.
`
`Ex. 1005 at [0001], [0006], [0172]. After receiving a request for data from a
`
`client, Imai’s “frame cutting circuit” cuts the requested data into “units of frame”
`
`having a length suitable for coding or for transmission on a network. Ex. 1005 at
`
`[0130], [0066]. Imai’s “units of frame” are units of data bits or digital data blocks
`
`on which Imai’s system operates on. Ex. 1003 at 103.
`
`12
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`Imai’s “selection instructing unit” chooses which encoder to use for each
`
`individual data block based on a number of factors. Ex. 1005 at [0100]-[0103].
`
`For example, in the context of audio data, Imai’s processor identifies portions of
`
`the digital data that have instrument sounds, and other portions that have vocal
`
`sounds. Ex. 1005 at [0102]. The selection instructing unit accounts for these
`
`variations in selecting and applying a suitable coding method. Ex. 1005 at [0102].
`
`Imai’s selection instructing unit also analyzes the client’s “processing ability” and
`
`the “transmission rate” of the network in order to select an encoder to use.
`
`Ex. 1005 at [0100]-[0103].
`
`In an additional embodiment, Imai teaches storing compressed data blocks in
`
`a variety of compression formats to simplify the transmission process by obviating
`
`13
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`the need to compress data blocks in real time. Ex. 1003 at 106; Ex. 1005 at [0165-
`
`0168].
`
`Imai explains that this embodiment is fully compatible with, and improves
`
`the operation of, the FIG. 5 configuration by “making the [server] processing
`
`simpler” so that the “scale of the server 1 is increased” or freed up for other tasks,
`
`“while the need of encoding [] in response to each request [] is eliminated.”
`
`Ex. 1003 at 106; Ex. 1005 at [0165], [0167], [0170].
`
`Imai describes that the available encoders include the MPEG layer 1, MPEG
`
`layer 2, and MPEG layer 3 compression algorithms, as well as the ATRAC and
`
`ATRAC2 compression algorithms. Ex. 1005 at [0067]. These encoders are
`
`asymmetric. See infra §VII.A.2(b); Ex. 1008 at 92 (stating that the underlying
`
`14
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`MPEG and ATRAC “architectures” are similar in that they are both asymmetric);
`
`Ex. 1009 at 8 (stating that the MPEG standard uses asymmetric compression
`
`algorithms); Ex. 1010 at 17 (stating that MPEG layer 3, or MP3, is an asymmetric
`
`algorithm); Ex. 1003 at 104.
`
`B.
`
`Overview of Ishii (Ex. 1007)
`
`Ishii is a U.S. Patent that teaches a file compression processor that enables
`
`effective
`
`file utilization by selecting a “suitable compression method
`
`corresponding to the access frequency and the type of the file.” Ex. 1007 at 1:50-
`
`55.
`
`15
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`Ishii describes a problem where data storage devices (which Ishii calls
`
`“databases”) were confronted with an “extremely large volume of data” to store on
`
`“large capacity storage media.” Ex. 1007 at 1:17-27. To increase the “virtual
`
`capacity” of the data bases, “conventional file compression systems” were used.
`
`Ex. 1007 at 1:24-27. But Ishii recognized that prior art systems compressed “all
`
`files” with the same compressor, without considering whether the storage device
`
`was full or that different files may require different compression types (or even no
`
`compression at all). Ex. 1007 at 1:32-46.
`
`Ishii’s
`
`solution
`
`“monitors
`
`the
`
`available file capacity, determines whether
`
`or not the file decompression is required
`
`depending on the difference between the
`
`available capacity and the threshold and
`
`selects the suitable compression method for
`
`a file corresponding to the access frequency
`
`and data attribute of the file.” Ex. 1007 at
`
`10:27-32. To do this, Ishii includes a “file
`
`status monitor” that continuously tracks the
`
`current available file capacity of a file unit.
`
`16
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`Ex. 1007 at 5:37-41; see FIGS. 2, 5-7. When the current available file capacity is
`
`below a threshold level (“Yes” at step 211), a “file search portion” searches for
`
`files to compress in order to increase available capacity over the threshold. Ex.
`
`1007 at 5:43-45.5 Specifically, Ishii looks for files that have a relatively low access
`
`frequency relative to other files. Ex. 1007 at 5:45-50, 7:24-31. Factors used to
`
`“select[] an appropriate data compression method for compression” of each file
`
`include the “access frequency” of the file to be compressed. Ex. 1007 at 5:60-65.
`
`Specifically, “[t]he file compression method with a shorter decompression time is
`
`selected for files with higher access frequency and the file compression method
`
`with a higher compression ratio is selected for files with lower access frequency.”
`
`Ex. 1007 at 7:25-34.
`
`When the file status monitor finds that the available file capacity has risen
`
`above the threshold again (e.g., by deletion or reduction of files), the file search
`
`portion searches “for files with high access frequency” to decompress. Ex. 1007 at
`
`8:35-42; 9:40-45; see FIG. 7. The process of monitoring the available file capacity
`
`to determine which files should be compressed and decompressed is a continuous
`
`one. Ex. 1007, FIGS.5-7 (depicting the monitoring loop that always returns to step
`
`5 The steps in FIGS. 5-7 that share the same number as those in FIG. 2 are
`described with respect to FIG. 2. Ex. 1007 at 8:43-45.
`
`17
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`210). Thus, files may be compressed, uncompressed, and recompressed as the file
`
`storage device is used. Ex. 1003 at 110.
`
`While Ishii was cited by the Applicant (along with 1,440 other references) in
`
`a voluminous IDS during prosecution of the ’535 Patent, the Examiner did not
`
`demonstrate any consideration of Ishii in any Office Action. See supra § IV.B; see
`
`generally Ex. 1002.
`
`VII. CHALLENGED CLAIMS 1-14 ARE UNPATENTABLE
`
`A.
`
`Ground 1: Claims 1-14 are Obvious in View of Imai and Ishii
`
`1.
`
`A POSITA Would Have Combined Imai and Ishii
`
`Imai and Ishii render obvious Claims 1-14 of the ’535 Patent. Ex. 1003 at
`
`111, 115. The combination would draw upon the teachings of Imai’s compress and
`
`transmit embodiment (FIG. 5 and corresponding disclosure) and the compress and
`
`store embodiment (FIG. 16 and corresponding disclosure). The combined system
`
`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 modify Imai’s compression algorithm selection logic to consider the
`
`frequency of access as taught by Ishii.
`
`A POSITA would have had ample motivation to build the combined system.
`
`Imai and Ishii are both directed to systems and methods of data compression.
`
`Ex. 1003 at 116; Ex. 1005 at [0177]; Ex. 1007 at 1:11-15. Imai and Ishii are
`
`18
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`directed to: (a) systems that select a compression algorithm from a plurality of
`
`compression algorithms (e.g., Ex. 1005 at [0067]; Ex. 1007 at 6:8-17), (b) systems
`
`that include asymmetric compression algorithms (e.g., Ex. 1005 at [0067];
`
`Ex. 1007 at 7:35-36), and (c) systems that account for the type of data to be
`
`compressed in their compression selection process (e.g., Ex. 1005 at [0102]-
`
`[0103]; Ex. 1007 at 5:62-65). Ex. 1003 at 116.
`
`A POSITA would have been motivated to combine the compression
`
`algorithm selection teachings of Imai and Ishii because it involves combining prior
`
`art elements (the selection criteria in Imai with the selection criteria of Ishii) in
`
`similar devices (data compression/decompression systems) to create an improved
`
`system with predictable results (a data compression system that is better at
`
`optimizing compression algorithm selection). Ex. 1003 at 117. Imai teaches a data
`
`compression system that selects among available compression algorithms to allow
`
`for compressing, storing, transmitting, and decompressing digital signal data in
`
`real-time. Ex. 1005 at [0051], [0167]; Ex. 1003 at 117. In Imai’s system, a variety
`
`of factors can be used to determine which compression algorithm is suitable for a
`
`set of data. Ex. 1003 at 117. These factors include the content of the data, the data
`
`type, the processing ability of the client, and the throughput of a communications
`
`channel. Ex. 1005 at [0088]-[0100] (processing ability of client), [0101]-[0102]
`
`19
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`(parameters or attributes of data), [0149]-[0160] (transmission rate); Ex. 1003 at
`
`117.
`
`As explained above, Ishii similarly teaches a data compression system that
`
`selects among compression algorithms to compress data. See supra § VI.B. Like
`
`Imai, Ishii teaches using multiple criteria to select a suitable compression
`
`algorithm. Ex. 1007 at 6:7-17; Ex. 1003 at 118. Those factors include a “data
`
`attribute (whether it is text data or binary data)” and “access frequency.” Ex. 1007
`
`at 5:66-6:6. The 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. Ex. 1003 at 119. Thus, a POSITA would have had a reasonable expectation of
`
`success in combining the factors used by Ishii (including access frequency) in
`
`combination with those in Imai to have a system that would allow for selection of a
`
`compression algorithm to be based at least in part on the access frequency of the
`
`data. Ex. 1003 at 119.
`
`In addition, a POSITA would have had reason to combine Ishii’s frequency
`
`of access of teachings with Imai because, as a part of the POSITA’s ordinary skill
`
`and creativity, a POSITA would have considered using a broad variety of selection
`
`criteria and would not merely limit herself to Imai’s specifically enumerated
`
`factors. Ex. 1003 at 120. A POSITA would have looked to another compression
`
`20
`
`

`

`IPR2019-00674 Petition
`U.S. Patent No. 8,934,535
`
`algorithm selection reference, like Ishii, to learn of additional criteria for selecting
`
`a suitable compression algorithm. Ex. 1003 at 120.
`
`A POSITA looking at Ishii would have been motivated to use the number of
`
`read/writes of the data in question, to enable selecting one algorithm for frequently
`
`accessed files and another algorithm for infrequently accessed files. Ex. 1003 at
`
`120. This would be the case because, as 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. Ex. 1005 at [0167]; Ex. 1003 at 120.
`
`Using 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. Ex. 1005 at
`
`[0170]; Ex. 1003 at 120-121. A POSITA would recognize this to be the case
`
`because Ishii teaches using more symmetric algorithms for use with more
`
`frequently accessed files, and less symmetric algorithms for use with less
`
`frequently accessed f