`
`––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––
`
`HULU, LLC,
`AMAZON.COM, INC., and
`NETFLIX, INC.,
`Petitioners,
`
`v.
`REALTIME ADAPTIVE STREAMING LLC,
`Patent Owner.
`
`––––––––––
`
`Case IPR2018-01170
`Patent 8,934,535
`––––––––––
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 8,934,535
`
`
`
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`V.
`
`I.
`II.
`III.
`
`TABLE OF CONTENTS
`Introduction ...................................................................................................... 1
`Grounds for Standing ....................................................................................... 2
`Identification of Challenge .............................................................................. 2
`A.
`Priority Date .......................................................................................... 2
`B.
`Prior Art ................................................................................................. 2
`C.
`Statutory Grounds.................................................................................. 3
`D.
`This Petition is Not Redundant ............................................................. 3
`IV. Summary of the ’535 Patent ............................................................................ 4
`A. Overview ............................................................................................... 4
`B.
`Prosecution History ............................................................................... 7
`Claim Construction .......................................................................................... 8
`A.
`Level of Ordinary Skill in the Art ......................................................... 8
`B.
`“asymmetric compressors” / “compressors using asymmetric data
`compression” ......................................................................................... 8
`“data block” ........................................................................................... 9
`C.
`VI. Summary of the Prior Art .............................................................................. 12
`A. Overview of Imai (Ex. 1005) .............................................................. 12
`B.
`Overview of Ishii (Ex. 1007) ............................................................... 15
`VII. Challenged Claims 15-30 are Unpatentable .................................................. 18
`A. Ground 1: Claims 15-23 and 30 are Obvious in View of Imai ........... 18
`1. Independent Claim 15 is Obvious .................................................. 19
`2. Dependent Claim 16 is Obvious .................................................... 35
`3. Dependent Claims 17 and 19 are Obvious ..................................... 36
`4. Dependent Claim 18 is Obvious .................................................... 39
`5. Dependent Claim 30 is Obvious .................................................... 40
`6. Dependent Claim 20 is Obvious .................................................... 41
`7. Dependent Claim 21 is Obvious .................................................... 42
`
`
`
`- i -
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`B.
`
`8. Dependent Claim 22 is Obvious .................................................... 44
`9. Dependent Claim 23 is Obvious .................................................... 45
`Ground 2: Claims 24-29 are Obvious in View of Imai and Ishii ........ 47
`1. Dependent Claim 24 is Obvious .................................................... 51
`2. Dependent Claim 25 is Obvious .................................................... 52
`3. Dependent Claim 26 is Obvious .................................................... 54
`4. Dependent Claims 27-29 are Obvious ........................................... 56
`VIII. Conclusion ..................................................................................................... 60
`IX. Mandatory Notices and Fees ......................................................................... 61
`
`
`
`
`
`- ii -
`
`
`
`IPR2018-01170 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”)
`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 (incorporated by reference
`into the ’535 Patent)
`Notice of Interested Parties, Realtime Adaptive Streaming, LLC
`v. Hulu LLC, No. 2:17-CV-07611, Dkt. 18 (C.D. Cal. October
`24, 2017)
`
`
`
`
`
`- iii -
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`I.
`
`INTRODUCTION
`Petitioners Hulu, LLC, Amazon.com, Inc., and Netflix, Inc. request inter
`
`partes review of claims 15-30 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 claim 27,
`
`the Applicant added the feature of using “asymmetric data compression” to
`
`differentiate from anticipatory art, while independent claim 15 recited “asymmetric
`
`compressors” as filed. Ex. 1002 at 435, 411.1 Asymmetric 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.
`
`
`1 Issued independent claim 15 was prosecuted as original claim 12 and issued
`independent claim 27 was prosecuted as original claim 28. Ex. 1002 at 597.
`
`
`
`1
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`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.
`
`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. See Ex.
`
`1001 at Face. Petitioners are unaware of any claim that the ’535 Patent is entitled to
`
`a priority date earlier than February 13, 2001, or that there is objective evidence of
`
`non-obviousness for any of the challenged claims.
`
`B.
`Prior Art2
`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
`
`
`2 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
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`translation of Imai); (Exhibit 1006 – U.S. Patent No. 6,507,611 (“the Imai ’611
`
`Patent”) is the U.S. sibling of Imai). 3
`
`Exhibit 1005 – 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
`
`as a patent on October 7, 1997, more than one year before the ’535 Patent’s earliest
`
`priority date (February 13, 2001).
`
`C.
`Statutory Grounds
`Petitioners request inter partes review on the following grounds:
`
`Ground
`No.
`1
`
`2
`
`References
`
`Imai (Ex. 1005)
`Imai (Ex. 1005)
`Ishii (Ex. 1007)
`
`Statutory Basis
`
`Obviousness (§103)
`
`Claims
`Challenged
`15-23 and 30
`
`Obviousness (§103)
`
`24-29
`
`D. This Petition is Not Redundant
`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 filed
`
`by the Petitioners that challenges Claims 15-30 of the ’535 Patent. In addition, the
`
`only other pending petition that challenges the ’535 Patent was filed by an unrelated
`
`
`3 The Imai ’611 Patent (Ex. 1006) claims priority to Imai and contains substantively
`identical figures and disclosures as Imai.
`
`
`
`3
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`party that is not a defendant to a claim of infringement of the ’535 Patent, challenged
`
`only six of the claims at issue in this petition (Claims 15-17, 19, and 22-23), and
`
`relies upon different prior art. See Case No. IPR2018-00883. At this time, no patent
`
`owner preliminary response or institution decision has been filed in that proceeding.
`
`Finally, Petitioners are unaware of any reason that the Board would be unable to
`
`timely issue a final written decision on this petition.
`
`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. 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:29-34. On the other hand, symmetric
`
`routines “compris[e] a fast compression routine.” Ex. 1001 at14:17-20.
`
`
`
`4
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`Independent claim 15, the first challenged here, adds little more than that the
`
`selected compressor is “asymmetric” and “storing” the compressed data blocks. But
`
`asymmetric compression algorithms, which admittedly include Lempel-Ziv
`
`(Ex. 1001 at 10:2-4), were already known in the prior art. Ex. 1001 at 1:35-40. And,
`
`regardless, selecting asymmetric algorithms is also taught by Imai.
`
`The ’535 Patent describes a prior art configuration that selects a compression
`
`algorithm based on a parameter or attribute of the data, and admits it was well-known
`
`in the prior art. The ’535 Patent incorporates into its specification the disclosure of
`
`US Patent No. 6,195,024 (“the ’024 Patent”)—a patent with an application filing
`
`date in 1998. Ex. 1001 at 5:33-38; Ex. 1015 at Face. The ’024 Patent admits that
`
`“there are many conventional content dependent” compression techniques in the
`
`prior art and presents the below “diagram of a content dependent high-speed lossless
`
`data compression and decompression system/method according to the prior art.”
`
`Ex. 1015 at 5:54-56, 2:41-45.
`
`
`
`5
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`
`
`Ex. 1015 at FIG. 1. The ’024 Patent describes a system that identifies an input data
`
`type, which is a parameter or attribute of the input data and compresses the data in
`
`accordance with the identified data type. Ex. 1015 at 2:42-45. Thus, the ’535 Patent,
`
`through the incorporated disclosure of the ’024 Patent, admits that this configuration
`
`embodying its claim limitations was in the “PRIOR ART.” Ex. 1015 at FIG. 1.
`
`The ’535 Patent also admits that storing compressed data blocks is well-
`
`known in the prior art and is widely used. Ex. 1001 at 2:44-46, cl. 15. Thus, although
`
`
`
`6
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`independent Claim 15 includes the concept of storing compressed data blocks, the
`
`concept of storing data (compressed or not) was known in the prior art. Ex. 1001 at
`
`2:44-46, cl. 15.
`
`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
`
`amending to overcome rejections under 35 U.S.C. §§ 112(a) and 102 in response to
`
`one Office Action.
`
`Imai was not cited or considered during prosecution of the ’535 Patent.
`
`Ex. 1001; Ex. 1003 at 98. 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 but one reference in an
`
`Information Disclosure Statement (“IDS”) submitted September 20, 2013 that listed
`
`another 565 different U.S. Patent documents, 848 non-patent literature documents,
`
`and 27 foreign patent documents. Ex. 1002 at 74-196.
`
`
`
`
`
`
`
`7
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`V. CLAIM CONSTRUCTION
`To the extent the Applicant has 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,4 the following terms should be construed:
`
`“asymmetric compression algorithm” and “data block.”
`
`A. Level of Ordinary Skill in the Art
`A person of ordinary skill in the art (“POSITA”) as of February 13, 2001
`
`would have had 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. Id.
`
`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
`
`
`4 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 89-90.
`
`
`
`8
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`compression algorithm in which the execution time for the compression and
`
`decompression routines differ significantly.” See Ex. 1003 at 91-92. 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.
`
`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 91-92.
`
`C.
`“data block”
`A POSITA would have understood that “data block,” in the context of the
`
`specification, means “a unit of data comprising more than one bit.” See Ex. 1003 at
`
`93-96. Starting with the claim language, “data block” is used consistently in each
`
`claim to refer to a unit of data that is compressed by a compression algorithm.
`
`Ex. 1001 at cls. 15 & 27. The specification explains that “[d]ata compression is
`
`widely used to reduce the amount of data required to process, transmit, or store a
`
`
`
`9
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`given quantity of information,” which suggests 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 93. 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 93. Therefore, a data block must be more
`
`than one bit in length so that it can be compressed as claimed. Ex. 1003 at 93.
`
`The specification also supports this construction. The specification describes
`
`“block structured disk compression” as operating on blocks of data that are either
`
`“fixed” or “variable in size.” Ex. 1001 at 7:3-5. The specification 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. The specification also contemplates units of
`
`data that comprise more than one bit that are stored in its system. Ex. 1001 at
`
`FIG. 4B (stating “2 bits” are reserved for a sector map “type” definition, and “3 bits”
`
`are reserved for “c type”). The specification’s discussion of various data block sizes,
`
`including file-sized data blocks and data units as small as 2 bits, are consistent with
`
`Petitioner’s proposed construction.
`
`
`
`10
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`The specification incorporates by reference U.S. Patent 6,195,024, a patent
`
`with the same named inventor, 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
`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:9-15.
`
`In district court proceedings, the Patent Owner5 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”).
`
`
`5 The entity in the cited proceedings is Patent Owner’s parent, Realtime Data, LLC,
`which owns Realtime Adaptive Streaming LLC. Ex. 1016.
`
`
`
`11
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`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 upon which Imai’s system
`
`operates. Ex. 1003 at 99.
`
`
`
`12
`
`
`
`
`
`IPR2018-01170 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
`
`the need to compress data blocks in real time. Ex. 1003 at 102; Ex. 1005 at [0165]-
`
`[0168].
`
`
`
`13
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`
`
`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 102;
`
`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 §0 (discussing claim 15); Ex. 1008 at 92 (stating that the
`
`underlying MPEG and ATRAC “architectures” are similar in that they are both
`
`asymmetric); Ex. 1009 at 8 (stating that the MPEG standard uses asymmetric
`
`
`
`14
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`compression algorithms); Ex. 1010 at 17 (stating that MPEG layer 3, or MP3, is an
`
`asymmetric algorithm); Ex. 1003 at 100.
`
`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.
`
`
`
`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
`
`
`
`15
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`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. 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
`
`
`
`16
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`threshold. Ex. 1007 at 5:43-45.6 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 Ex. 1007 at 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 at FIGS. 5-7 (depicting the monitoring loop that always
`
`returns to step 210). Thus, files may be compressed, uncompressed, and
`
`recompressed as the file storage device is used. Ex. 1003 at 103-104, 187-189.
`
`
`6 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
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`While Ishii was cited by the Applicant in a voluminous IDS during
`
`prosecution of the ’535 Patent, the Examiner did not demonstrate any consideration
`
`of Ishii in any Office Action. See infra §IV.B; see generally Ex. 1002. Indeed, it
`
`was but one of over one thousand references cited in the file history.
`
`VII. CHALLENGED CLAIMS 15-30 ARE UNPATENTABLE
`A. Ground 1: Claims 15-23 and 30 are Obvious in View of Imai
`A POSITA would have found the claims obvious in view of her own
`
`knowledge and the teachings of Imai. Ex. 1003 at 105.
`
`The challenged claims recite a preamble directed to “a method.” To the extent
`
`the preamble is a limitation, it is met because Imai teaches “methods” for
`
`compressing digital audio and video data by selecting one of a plurality of different
`
`coding methods for application. Ex. 1005 at [0001], [0067], [0171]; Ex. 1003 at
`
`110.
`
`
`
`
`
`
`
`18
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`1.
`
`Independent Claim 15 is Obvious
`
`15[a] determining a parameter of at least a portion of a data block;
`
`Imai teaches this limitation. In Imai, a client requests signals from a server as
`
`shown in FIG. 1:
`
`Ex. 1005 at [0086].
`
`Imai’s FIG. 5 depicts the compression system at the server:
`
`
`
`
`
`19
`
`
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`After receiving a request for signals, Imai describes forming data blocks containing
`
`audio or video data from the data input into Imai’s server. Ex. 1005 at [0066]. Imai
`
`teaches that the frame cutting circuit:
`
`cuts the audio signal (audio data) from the audio signal
`input circuit 31 in units of frame having a predetermined
`length (e.g., a length suitable for coding made by encoders
`531 to 53N, or a length suitable for packet (network packet)
`transmission via the network 2), and then supplies
`resulting frames to a switch 52.
`
`Ex. 1005 at [0066]. Thus, Imai’s frame cutting circuit receives digital data requested
`
`by the client and “cuts” the digital data into data blocks of a length suitable for either
`
`compressing or for creating network transmission packets. Ex. 1003 at 112. Each
`
`of Imai’s “units of frame” is a data block. Ex. 1003 at 113.
`
`Imai explains how to examine “portions” of data blocks to determine
`
`parameters or attributes of that data block. In one example, Imai considers the level
`
`of the voice as compared to a level of the instrument sounds in a portion of a data
`
`block:
`
`when the audio signal requested [by] the client terminal 3
`has one portion in which a level of the voice is relatively
`high and the other portion in which a level of the
`instrument sounds is relatively high, the coding method
`suitable for the voice is selected for one portion in which
`
`
`
`20
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`a level of the voice is relatively high, and the coding
`method suitable for the instrument sounds is selected for
`the other portion in which a level of the instrument sounds
`is relatively high.
`
`Ex. 1005 at [0102]. Thus, Imai analyzes the data to determine characteristics,
`
`parameters, or attributes about at least a portion of a data block. Ex. 1003 at 114-
`
`115.
`
`15[b] selecting one or more asymmetric compressors from among a plurality
`of compressors based upon the determined parameter or attribute;
`
`Imai teaches this limitation. Ex. 1003 at 116-125.
`
`(a)
`Imai teaches a plurality of asymmetric compressors
`Imai teaches a selection instructing unit 55 that selects an appropriate “one
`
`from a plurality of coding methods corresponding to the encoders 531 to 53N . . . and
`
`then instructs the encoding selecting circuit 56 to select the decided coding method.”
`
`Ex. 1005 at [0070].
`
`
`
`21
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`Imai’s encoders 531–53N are “different coding methods from each other.”
`
`Ex. 1005 at [0067]. Imai describes that the coding methods include:
`
`
`
`linear PCM (Pulse Code Modulation), ADPCM (Adaptive
`Differential PCM), layers 1, 2, 3 of MPEG (Moving
`Picture Experts Group), ATRAC (Adaptive Transform
`Acoustic Coding), ATRAC 2, and HVXC (Harmonic
`Vector Excitation Coding). Stated otherwise, in the
`embodiment, the encoders 531 to 53N are prepared by
`using encoders which perform encoding of the audio
`signal with various coding methods.
`
`Ex. 1005 at [0067], [0068]-[0071]. At least MPEG layers 1, 2, and 3, ATRAC, and
`
`ATRAC 2, are each asymmetric compressors. Ex. 1003 at 117-122; see Ex. 1012 at
`
`
`
`22
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`2:25-34 (describing ATRAC compression); Ex. 1011 at 4:19-21 (describing audio
`
`MPEG layers 1, 2, and 3 compression); Ex. 1005 at [0068] (stating that MPEG layer
`
`3 and ATRAC 2 provide a high compression rate). A POSITA would have
`
`understood that Imai teaches using compression encoders because coding is a term
`
`of art in the industry that encompasses compressors, and Imai states that at least
`
`ATRAC 2 and MPEG layer 3 are examples of compressors. Ex 1005 at [0068];
`
`Ex. 1003 at 117-118. With respect to ATRAC and MPEG layers 1 and 2, it was
`
`commonly known in the field that these were all compression algorithms. See
`
`Ex. 1012 at 2:25-34 (describing ATRAC compression); Ex. 1011 at 4:19-21
`
`(describing MPEG layers 1, 2, and 3 compression).
`
`A POSITA would have understood that each of the ATRAC and MPEG
`
`compressors are asymmetric because the execution time for the compression and
`
`decompression of these algorithms differ significantly. Ex. 1003 at 119; Ex. 1008
`
`at 92; Ex. 1009 at 8. The ATRAC family of compression algorithms, including
`
`ATRAC 2, use an asymmetric architecture that separates the implementation details
`
`of the encoder (such as psychoacoustic analysis and bit-allocation) from the decoder.
`
`Ex. 1003 at 119; Ex. 1008 at 92. This architecture allows for more sophisticated
`
`encoding strategies which are performed with access to higher performance
`
`computing
`
`resources
`
`(e.g.,
`
`a
`
`computing device or
`
`special purpose
`
`recording/encoding device) without modifying the complexity of the decoding
`
`
`
`23
`
`
`
`IPR2018-01170 Petition
`U.S. Patent No. 8,934,535
`
`str