`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`DELL INC., EMC CORPORATION, HEWLETT-PACKARD
`ENTERPRISE CO., and HP ENTERPRISE SERVICES, LLC
`Petitioner
`
`v.
`
`REALTIME DATA LLC
`Patent Owner
`____________________
`
`Case IPR2017-00179
`Patent No. 9,054,728
`____________________
`
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`IPR2017-00179
`Patent No. 9,054,728
`
`TABLE OF CONTENTS
`
`Introduction ..................................................................................................... 1
`
`Background of the ’728 patent and challenged claims ................................... 3
`
`
`
`I.
`
`II.
`
`III. Under Petitioner’s own theory, none of its references teaches or
`suggests compressing using “the single data compression encoder”
`when one or more “parameters or attributes” are not identified, as
`Claim 1[f] requires, and each cited reference instead only teaches
`using “content dependent compression,” which does not suffice. ................. 6
`A.
`Franaszek always identifies a “parameter or attribute” and
`selects the best compression technique for the data on that
`basis. ..................................................................................................... 9
`Hsu always identifies a “parameter or attribute” and always
`selects the compression technique for the data on that basis. ............ 19
`Sebastian always identifies a “parameter or attribute” and tries
`to select the compression technique for the data on that basis. ......... 23
`Because none of the Petition’s references teaches or suggests
`Claim 1[f], no combination of the references can prevail.................. 25
`
`B.
`
`C.
`
`D.
`
`IV. Even assuming arguendo that Franaszek teaches Claim 1[f],
`Petitioner’s proposed combination of Franaszek and Hsu fails because
`it lacks evidence of a motivation to combine or that a POSA would
`combine. ........................................................................................................ 26
`
`V.
`
`Petitioner’s modification to Franaszek based on Sebastian would
`eliminate Franaszek’s intended purpose, and thus lacks a motivation
`to combine as a matter of law ....................................................................... 33
`
`VI. Petitioner’s theory with respect to Claim 24 fails because it has no
`working theory as to the “otherwise compressing the data block with
`the default data compression encoder” limitation of Claim 24. ................... 36
`A.
`Petitioner’s theory 1: Franaszek alone. .............................................. 37
`B.
`Petitioner’s theory 2: Franaszek modified by Sebastian to use a
`single default encoder when faced with unknown data types. ........... 39
`
`
`
`
`
`
`- i -
`
`
`
`

`

`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`C.
`
`Petitioner’s theory 3: Franaszek modified by Sebastian to use a
`single default encoder when faced with recognized data types
`that are not associated with one or more encoders. ............................ 41
`
`VII. Aakre’s reference to real time compression is inapposite and does not
`teach or suggest the “real-time” compression dependent claims of the
`’728 patent. ................................................................................................... 42
`
`VIII. Conclusion .................................................................................................... 46
`
`
`
`
`
`
`
`
`
`- ii -
`
`
`
`

`

`
`
`EXHIBIT LIST
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`Description
` Declaration of Kayvan B. Noroozi in Support of Motion for
`Admission Pro Hac Vice.
`Transcript of Oral Deposition of Charles D. Creusere, January
`19, 2017 taken in IPR2016-00972 and IPR2016-01002.
`
`
`
`
`
`Exhibit No.
`2001
`
`2002
`
`
`
`
`- iii -
`
`
`
`

`

`
`
`IPR2017-00179
`Patent No. 9,054,728
`
`I.
`
`Introduction
`
`When the undisputed and indisputable evidence from Petitioner’s expert and
`
`its cited prior art establishes that the prior art does not teach or suggest a limitation
`
`of a challenged claim, institution as to that claim must be denied.
`
`According to Petitioner, limitation [e] of Claim 1 of the ’728 patent requires
`
`“content dependent compression” and limitation [f] of Claim 1 requires “content
`
`independent compression.” See Section III, infra. Petitioner defines “content
`
`dependent compression” as performing compression using an encoder selected
`
`“based in part on one or more attributes of the data block or parameters of the data
`
`block.” Pet., 21, 22; see Section III, infra. Petitioner defines “content independent
`
`compression” as performing compression using an encoder that “is selected
`
`independent of the content of the data block to compress [the data] block.” Pet. 25
`
`(emphasis added).
`
`As we show in this Patent Owner’s Preliminary Response, however, none of
`
`Petitioner’s cited references teaches “content independent compression” under
`
`Petitioner’s own definition of that term. Instead, each of the cited references only
`
`teaches “content dependent compression” under Petitioner’s definition of that term.
`
`Accordingly, the Petition fails with respect to limitation [f] of Claim 1, i.e.,
`
`“perform[ing] data compression with the single data compression encoder, if the
`
`one or more parameters or attributes of the data are not identified.” Institution as
`
`
`
`
`
`
`- 1 -
`
`
`
`

`

`to Claim 1, and each of the claims that depend therefrom (Claims 2-10, 15, and
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`20), should thus be denied.
`
`Institution as to Claim 1 and its dependent claims should also be denied for
`
`the separate reason that Petitioner’s only articulated theory with respect to
`
`limitation [f] of Claim 1 relies on a combination theory that lacks any evidence
`
`whatsoever of a motivation to combine. Specifically, Petitioner’s own expert
`
`provides no support for Petitioner’s theory as to Claim 1 limitation [f], which is
`
`fatal to institution. Moreover, we demonstrate that no POSA would be motivated to
`
`pursue Petitioner’s proposed combination because it makes no sense and defies any
`
`reasonable logic. Petitioner asserts (through pure attorney argument) that a POSA
`
`would combine its base reference, Franaszek, with the secondary reference, Hsu,
`
`such that Franaszek would only use Hsu’s powerful data type recognition method
`
`when Franaszek already has a data type, and would not use Hsu’s data type
`
`recognition method when Franaszek does not have a data type. See Section IV,
`
`infra. And Petitioner’s only justification for that theory—a purported motivation to
`
`“speed up” Franaszek—is contradicted by its own expert, who has admitted that
`
`Franaszek’s compression approach “does not consider the speed of the
`
`compression algorithm.” Ex. 2002, 87:9-17. It is no wonder that Petitioner’s expert
`
`did not provide support for that desperate theory in this Petition.
`
`
`
`
`
`
`- 2 -
`
`
`
`

`

`With respect to Claim 24, the Petition likewise fails because Petitioner has
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`no working theory as to Claim 24’s “otherwise compressing the data block with the
`
`default data compression encoder” limitation. While Petitioner makes three
`
`attempts at presenting various arguments and combinations to meet that limitation,
`
`each of its attempts fails, as we show in detail in Section VI.
`
`Finally, the Petition also fails with respect to dependent Claims 4-8, which
`
`recite a “real-time” compression limitation. Petitioner relies on Aakre as
`
`purportedly teaching the “real-time” compression of Claims 4-8. But Aakre’s
`
`discussion relates entirely to providing a smooth and continuous flow of
`
`compressed data to the storage device to avoid unnecessary starts and stops of the
`
`tape writing mechanism, and says nothing about the time used to compress the data
`
`by the encoders, which is the relevant “real-time” compression for purposes of
`
`Claims 4-8. Moreover, Petitioner’s articulation of its combination theory lacks
`
`basic predicate facts and evidence, and thus fails on that additional basis.
`
`Accordingly, as we demonstrate in detail below, institution should be denied
`
`as to all challenged claims.
`
`II. Background of the ’728 patent and challenged claims
`Petitioner challenges claims 1-10, 15, 20, and 24 of the ’728 patent. The
`
`’728 patent relates to data compression. The invention claimed in the ’728 patent
`
`
`
`
`
`
`- 3 -
`
`
`
`

`

`uses “a combination of content dependent data compression and content
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`independent data compression.” Ex. 1001, 15:60-63. The ’728 patent shares a
`
`common specification with U.S. Patent 7,161,506, which Petitioner has also
`
`challenged in co-pending inter partes review IPR2017-00176.
`
`The claims of the ’728 patent have at least one notable difference as
`
`compared to the challenged claims of the ’506 patent, however, which is
`
`particularly relevant to this Petition: each of the challenged claims of ’728 patent is
`
`broadly directed to analyzing data within a data block to identify “parameters or
`
`attributes,” and not simply “data types.” By contrast, the challenged claims of the
`
`’506 patent are directed to identifying one specific type of parameter or attribute: a
`
`data type. Thus Claim 1 of the ’728 patent recites:
`
`[pre] A system for compressing data comprising:
`
`[a] a processor;
`
`[b1] one or more content dependent data compression encoders; and
`
`[b2] a single data compression encoder;
`
`[c] wherein the processor is configured:
`
`[d] to analyze data within a data block to (i) identify one or more
`
`parameters or attributes of the data wherein the analyzing of the data within
`
`the data block to identify the one or more parameters or attributes of the
`
`
`
`
`
`
`- 4 -
`
`
`
`

`

`data excludes analyzing based solely on a (ii) descriptor that is indicative of
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`the one or more parameters or attributes of the data within the data block;
`
`[e] to perform content dependent data compression with the one or more
`
`content dependent data compression encoders if the one or more parameters
`
`or attributes of the data are identified; and
`
`[f] to perform data compression with the single data compression encoder, if
`
`the one or more parameters or attributes of the data are not identified.
`
`The specification of the ’728 patent makes clear that identifying “parameters
`
`or attributes” may include, but is also far broader than, simply identifying a “data
`
`type.” For instance, the specification provides that “parameters or attributes” are
`
`“data types, data structures, data block formats, file substructures, file types, and/or
`
`any other parameters that may be indicative of either [1] the data type/content of a
`
`given data block or [2] the appropriate data compression algorithm or algorithms . .
`
`. to be applied.” Id., 16:22-28 (emphases and numbering added).
`
`
`
`
`
`
`
`
`
`
`- 5 -
`
`
`
`

`

`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`III. Under Petitioner’s own theory, none of its references teaches or suggests
`compressing using “the single data compression encoder” when one or
`more “parameters or attributes” are not identified, as Claim 1[f]
`requires, and each cited reference instead only teaches using “content
`dependent compression,” which does not suffice.
`
`As shown in Section II above, limitation [e] of Claim 1 requires that the
`
`system perform “content dependent compression” when the one or more
`
`parameters or attributes of the data are identified. Petitioner’s theory with respect
`
`to Claim 1[e] defines “content dependent compression” as choosing an encoder
`
`“based in part on one or more attributes of the data block or parameters of the data
`
`block.” Pet., 21, 22 (“Hsu’s encoders are ‘content dependent’ because an
`
`appropriate encoder is chosen based in part on one or more attributes of the data
`
`block . . . or parameters of the data block. . . .”) (emphasis added).
`
`Claim 1 limitation [f] (hereafter “Claim 1[f]”), by contrast, requires
`
`“perform[ing] data compression with the single data compression encoder, if the
`
`one or more parameters or attributes of the data are not identified.” The
`
`fundamental premise of Petitioner’s obviousness theory with respect to Claim 1[f]
`
`is that (1) the “single data compression encoder” of Claim 1 is a “content
`
`independent encoder,” Pet., 23-24, n.3 (relying on a construction of a “[s]ingle
`
`data compression encoder” as “[a] content independent encoder”) (emphasis
`
`added), and (2) that a “content independent encoder,” according to Petitioner, is an
`
`
`
`
`
`
`- 6 -
`
`
`
`

`

`encoder that “is selected independent of the content of the data block to compress
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`[the data] block.” Id., 25 (emphasis added). Thus Petitioner asserts that Franaszek
`
`teaches the “single data compression encoder” of Claim 1 “because it uses a [sic]
`
`one encoder selected from a ‘default’ list of encoders when data type information
`
`is not available, and that single default encoder is selected independent of the
`
`content of the data block to compress block B into B’ when data type information
`
`is not provided.” Id. (emphasis added).
`
`Thus according to Petitioner’s own theory, in order to show a reasonable
`
`likelihood that its Petition will prevail (as it must), Petitioner must show that at
`
`least one of its cited references teaches: selecting an encoder to compress a data
`
`block where the encoder “is selected independent of the content of the data block.”
`
`Id., 25; 24 n.3. That reality is not a claim construction argument by Patent Owner,
`
`nor any expression of agreement with Petitioner’s interpretation of the “single data
`
`compression encoder” of Claim 1. Rather, it is simply the path that Petitioner has
`
`set out for itself and to which it is bound. Patent Owner need not agree or disagree
`
`with Petitioner’s claim interpretation position to demonstrate a lack of reasonable
`
`likelihood that Petitioner will prevail. Rather, it suffices to show that the Petition
`
`lacks any merit under its own articulated claim theory. In this section, we do
`
`precisely that.
`
`
`
`
`
`
`- 7 -
`
`
`
`

`

`As we demonstrate in each of the following sub-sections, none of the three
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`references Petitioner relies on with respect to Claim 1—Franaszek, Hsu, and
`
`Sebastian—ever teaches or suggests selecting an encoder to compress a data block
`
`where the encoder “is selected independent of the content of the data block,” as
`
`Petitioner’s theory of Claim 1 requires. Id., 25.
`
`To the contrary, as we show below, each of Petitioner’s references is
`
`directed to always performing data compression using an encoder chosen “based in
`
`part on one or more attributes of the data block . . . or parameters of the data
`
`block,” i.e., what Petitioner defines as “content dependent” compression. See id.,
`
`21-22. (“Hsu’s encoders are ‘content dependent’ because an appropriate encoder is
`
`chosen based in part on one or more attributes of the data block . . . or parameters
`
`of the data block. . . .”) (emphasis added).1
`
`
`1 As noted, we neither embrace nor refute Petitioner’s asserted claim
`
`interpretations with respect to Claim 1, nor are we required to do so. Rather, we
`
`simply show that Petitioner’s theory rests on specific premises that the Petition
`
`itself and the prior art fundamentally refute, and the Petition must therefore fail.
`
`
`
`
`
`
`- 8 -
`
`
`
`

`

`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`Franaszek always identifies a “parameter or attribute” and selects
`the best compression technique for the data on that basis.
`
`A.
`
`Petitioner relies on Franaszek as its primary reference with respect to both
`
`asserted Grounds, and specifically with respect to Claim 1[f]. See id., 40-41.
`
`Franaszek describes a block-by-block system for “compressing . . . data
`
`using a plurality of data compression mechanisms.” Ex. 1004, Abstract. As
`
`Franaszek explains, its objective is to “to dynamically compress data blocks by
`
`using the best of a given set of methods, and for dictionary-based compression, by
`
`using the best of a given set of dictionaries,” id., 3:25-28, which “increase the
`
`number of data blocks that can be stored in the second memory 20 given a fixed
`
`second memory size.” Id., 4:14-17.
`
`To accomplish this objective, Franaszek discloses a data compressor 220
`
`that compresses data blocks as they are transferred to the second memory, which is
`
`illustrated in the annotated Fig. 2 and reproduced below. Id., 4:25-28.
`
`
`
`
`
`
`
`
`
`
`- 9 -
`
`

`

`Franaszek explains (and shows in Fig. 2 above) that “the uncompressed data
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`blocks 210 [] can optionally contain type information 205. The type information
`
`can be, for example[], image data encoded in a given format, source code for a
`
`given programming language, etc.” Id., 4:30-35. When the optional data type
`
`information 205 is available, Franaszek uses a preselected list of compression
`
`methods based on type information availability for a data block, as shown in step
`
`404 of Fig. 4A, below. Id., 5:48-54. When the optional data type information 205
`
`is not available, Franaszek sets its Compression Method List (CML) to a default
`
`list of compression methods, as shown in step 407 of annotated Fig. 4A below. Id.
`
`
`
`
`
`
`- 10 -
`
`
`
`
`
`

`

` Case IPR2017-00179
`Patent No. 9,054,728
`
`Critical to understanding Franaszek is that—regardless of whether a data
`
`
`
`
`
`type is available for a data block or not—Franaszek’s method will always select a
`
`specific compression technique from a list of possible techniques in the same way.
`
`This is shown in Fig. 4A above, beginning in step 409, where the paths for data
`
`blocks with data type information and without data type information converge.
`
`
`
`Specifically, Franaszek tests each compression method (M) or compression
`
`method and dictionary pair (M, D) on a sample taken from the uncompressed data
`
`block 205. Id., 5:18-21, 6:11-26. Franaszek then selects the best compression
`
`method (M) or best compression method and dictionary pair (M, D) for that data
`
`block based on the results of the sampling and testing that was performed. Id.,
`
`5:21-23, 5:26-28, 6:33-40. In particular, Franaszek makes clear that the best
`
`compression method (M) or best compression method and dictionary pair (M, D) is
`
`one that results in the smallest compressed sample data block, i.e., one that results
`
`in the highest compression ratio. Id.
`
`
`
`Assuming that the compression ratio for the determined best compression
`
`method (M) or compression method and dictionary pair (M, D) is above a 30-
`
`percent compression threshold condition, id., 5:29-36, 6:33-45, Franaszek then
`
`compresses the entire data block by using the previously determined best
`
`
`
`
`
`
`- 11 -
`
`
`
`

`

` Case IPR2017-00179
`Patent No. 9,054,728
`
`compression method (M) or best compression method and dictionary pair (M, D),
`
`
`
`which is illustrated in FIG. 4C reproduced below. Id., 5:33-39, 6:43-50.
`
`
`
`
`
`As noted, Franaszek will always perform its sampling and testing approach,
`
`and will always select a specific “best” compression algorithm for a given data
`
`block from among several possible compression algorithms, based on an analysis
`
`of the compressibility of the data block using each of the different potential
`
`compression techniques. This is illustrated, for instance, in step 429 of Fig. 4A, as
`
`well as the top of Fig 4B, reproduced below.
`
`
`
`
`
`
`- 12 -
`
`
`
`

`

`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`
`
`
`
`And there is no possibility of a factual dispute in this proceeding as to the
`
`fact that the availability or unavailability of a data type in Franaszek changes
`
`nothing about how Franaszek ultimately selects the compression technique to be
`
`applied to a data block. That is because Petitioner’s expert in this proceeding, Dr.
`
`
`
`
`- 13 -
`
`
`

`

` Case IPR2017-00179
`Patent No. 9,054,728
`
`Charles Creusere, has already admitted to these facts in a recent deposition in
`
`
`
`another related proceeding regarding the Franaszek reference.
`
`Q. And regardless of whether or not the data type is known in that
`section of Figure 4A, the process will always lead down to step 409, correct?
`A.
`Correct.
`*
`*
`*
`Q.
`Regardless of whether or not the data type is available in step 414, the
`process diagrammed in Figure 4A will always lead down to step 429, where
`it says, “Was E Last Entry in CML?” Right?
`A. Yes. It will always lead down to step 429.
`Q. And what’s diagrammed here in Figure 4A runs a sufficient number
`of times, until the answer to the question in 429 is “yes,” right?
`A.
`That is correct.
`Q. And so at some point, the answer to 429 will always be “yes,”
`correct?
`A.
`Correct.
`Q. And from there, the process states that the testing, using different
`compression techniques, will always occur, right?
`Yes. The testing, using different compression techniques, will occur
`A.
`regardless of whether the data type is known or unknown.
`Ex. 2002, 125:4-126:11 (emphasis added).
`
`As Franaszek itself makes clear and Dr. Creusere’s admissions confirm,
`
`Franaszek will always perform its sampling and testing approach, and will always
`
`select a specific “best” compression algorithm for a given data block from among
`
`
`
`
`
`
`- 14 -
`
`
`
`

`

`several possible compression algorithms, based on an analysis of the
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`compressibility of the data block using each of the different potential compression
`
`techniques. These steps occur regardless of whether data type information 205 is
`
`provided for the data block.
`
`Thus, under Petitioner’s own definition of “content dependent”
`
`compression—i.e., choosing an encoder “based in part on one or more attributes of
`
`the data block . . . or parameters of the data block,” Pet., 21-22—Franaszek utilizes
`
`an entirely content dependent compression approach in all instances. The ’728
`
`patent’s specification makes clear that “parameters or attributes” includes “any [ ]
`
`parameters that may be indicative of either [1] the data type/content of a given
`
`data block or [2] the appropriate data compression algorithm or algorithms . . . to
`
`be applied.” Ex. 1001, 16:22-28 (emphases and numbering added). In Franaszek,
`
`the compressibility of the data block will always determine “the appropriate data
`
`compression algorithm to be applied” and is necessarily “indicative” of at least the
`
`content of the data block. If Franaszek does not receive a data type, it will select
`
`and use one of the default compression techniques from step 407 based on testing
`
`that identifies the compressibility of the content of the data block using each of
`
`those compression techniques. If Franaszek does receive a data type, it will select
`
`and use one of the preselected compression techniques from step 404 based on
`
`
`
`
`
`
`- 15 -
`
`
`
`

`

`testing that identifies the compressibility of the content of the data block using
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`each of those compression techniques. Accordingly, the compressibility of the data
`
`block in Franaszek is a “parameter or attribute” for purposes of Claim 1, and since
`
`Franaszek always selects a specific compression technique for the data block based
`
`on that “parameter or attribute,” Franaszek’s approach is exclusively “content
`
`dependent” under Petitioner’s interpretation of “content dependent compression.”
`
`See Pet., 21-22 (interpreting “content dependent compression” to mean
`
`compressing using an encoder chosen “based in part on one or more attributes of
`
`the data block or parameters of the data block.”).
`
`Stated conversely, Franaszek will never select an encoder to compress a data
`
`block “independent of the content of the data block,” as Petitioner’s theory with
`
`respect to the “single data compression encoder” of Claim 1[f] requires. See id., 25
`
`(asserting that Franaszek teaches the “single data compression encoder” of Claim 1
`
`“because it uses a [sic] one encoder . . . selected independent of the content of the
`
`data block. . . .”) (emphasis added).
`
`In attempting to show otherwise, the Petition expresses or suggests two
`
`arguments, both of which are without merit.
`
`First, Petitioner suggests that Franaszek does select an encoder to compress
`
`a data block “independent of the content of the data block” because Franaszek
`
`
`
`
`
`
`- 16 -
`
`
`
`

`

`teaches a default list of compression techniques, which default techniques are used
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`“when the data type is unknown,” as shown in step 407. Id., 24. But that argument
`
`fails because Claim 1[f] does not simply require selecting a default list of
`
`compression techniques based on whether a parameter or attribute (such as a data
`
`type) is not identified. Rather, Claim 1[f] specifically requires “perform[ing] data
`
`compression with the single data compression encoder, if the one or more
`
`parameters or attributes of the data are not identified.” While the lack of a data
`
`type causes Franaszek to select a default list of possible compression techniques, it
`
`does not cause Franaszek to “perform” data compression using either a specific
`
`technique or any content independent encoder. Rather, Franaszek only performs
`
`data compression using a compression technique after identifying a parameter or
`
`attribute of the data—the data block’s compressibility. And while the compression
`
`technique ultimately “selected to compress the entire data block is a ‘single’
`
`encoder,” as Petitioner contends, id., 23-24 n.3, that “single” encoder is always
`
`selected based on a “parameter or attribute” of the data, not on the failure to
`
`identify “one or more parameters or attributes,” as Claim 1[f] requires.
`
`Second, Petitioner attempts to obfuscate and conflate the issues by arguing
`
`that Franaszek must have a “single data compression encoder” because
`
`Franaszek’s method is, according to Petitioner, “conceptually indistinguishable
`
`
`
`
`
`
`- 17 -
`
`
`
`

`

`from the ’728 patent.” Id., 26-28. As a threshold matter, that argument is
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`irrelevant: the only proper inquiry is whether the prior art teaches each and every
`
`limitation of the challenged claims of the’728 patent, not whether the prior art
`
`shares similarities with certain portions of the ’728 patent’s specification.
`
`In any case, Petitioner’s argument also fails because the ’728 patent’s
`
`specification does teach “content independent” compression under Petitioner’s
`
`interpretation of that term in a manner that is notably different than Franaszek. In
`
`Petitioner’s own words: “The ’728 patent discloses compressing each data block
`
`using a series of encoders and then determining whether the compression ratio for
`
`each data block exceeds a certain threshold. If at least one block exceeds the
`
`threshold, the compressed data block with the greatest compression ratio is
`
`output.” Id., 26 (emphasis added) (internal citations omitted). In other words, the
`
`’728 patent’s approach fully compresses each data block using several different
`
`compression techniques, with each compression technique applied independent of
`
`the content of the data block. That process yields several fully compressed data
`
`blocks. The data block that is the most compressed is then output, provided its
`
`compression ratio meets a threshold. That teaching satisfies Petitioner’s definition
`
`of “content independent” compression “because it uses a [sic] one encoder . . .
`
`selected independent of the content of the data block. . . .” Id., 25. In other words,
`
`
`
`
`
`
`- 18 -
`
`
`
`

`

`under the teachings of the ’728 patent, the compressibility of the data block
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`determines the data block that is output, but not the encoder or technique used to
`
`compress the data block.
`
`By contrast, Franaszek does not fully compress one data block using
`
`multiple compression techniques. Rather, it compresses only a sample of the data
`
`block with multiple techniques, and then uses the results—the data block’s
`
`compressibility—to select a specific encoder that is then used to compress the
`
`entire data block in full. Accordingly, the compression technique that is used in
`
`each instance under Franaszek’s approach depends entirely on the compressibility
`
`of the data block—a “parameter or attribute”—and Franaszek is thus entirely
`
`content dependent, not content independent, under Petitioner’s own interpretation
`
`of those terms.
`
`
`
`Franaszek thus fails to teach or suggest limitation [f] of Claim 1.
`
`B. Hsu always identifies a “parameter or attribute” and always
`selects the compression technique for the data on that basis.
`
`The petition uses Hsu (Ex. 1005) as a secondary reference for all of the
`
`challenged claims and with respect to both asserted Grounds. Like Franaszek, Hsu
`
`categorically teaches away from using content independent compression, and
`
`instead uniquely champions the merits of its entirely content-dependent approach.
`
`
`
`
`
`
`- 19 -
`
`
`
`

`

`Hsu teaches the identification of a “block type” for each data block. Pet. 32;
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`Ex. 1002, 1103. It then teaches that a “new-file” procedure to achieve block type,
`
`i.e., data type, identification. Id., 1104. Under this “new-file” procedure, the
`
`method of Hsu looks to three 512 byte segments within the block: 512 bytes in the
`
`beginning, 512 bytes in the middle, and 512 bytes in the end. Id. During that
`
`analysis, Hsu’s method looks for “the pattern of data contained” in each 512 byte
`
`segment. Id. In other words, Hsu’s approach looks to identify three attributes of the
`
`data block, i.e., three data patterns derived from three different segments within the
`
`block. In the event that two patterns point to one data type and the third to another,
`
`Hsu uses “majority vote” to reconcile the discrepancy. (Id.) Where each of the
`
`three patterns points to different data types, Hsu uses “the first data type detected.”
`
`Id. Notably, Hsu will always identify at least one pattern, i.e., “an attribute,” for
`
`each data block. And as Petitioner acknowledges, Hsu will always identify a data
`
`type for each block. Pet., 9, 32. Specifically, Petitioner states: “Hsu discloses a
`
`‘system [that] determines the type and compressibility of each block.’” Pet. 32.
`
`That statement is unequivocal, and there is no doubt that by determining the type
`
`of each data block, Hsu necessarily always determines a data type for every data
`
`block.
`
`
`
`
`
`
`- 20 -
`
`
`
`

`

`Moreover, Hsu will also always identify three other “attributes” of the data
`
`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`block, all falling within the broader heading of a “redundancy metric.” Id., 11-13.
`
`These attributes are the degree of variation in character frequency or alphabetic
`
`distribution, the average run length of the block, and the string repetition ratio of
`
`the block. Id., 11.
`
`Once Hsu has detected the data type of the block based on its data pattern
`
`analysis approach, and calculated a redundancy metric based on the three other
`
`attributes noted above, Hsu will also always apply a content dependent
`
`compression technique. This is illustrated in Hsu’s Table I, which shows that Hsu
`
`always maps the determined data type (shown in the table’s rows) and the
`
`“redundancy metric” of the data (shown in the three columns) to select a content
`
`dependent compression technique (as shown in the table’s entries, e.g., run-length
`
`encoding). And critically, even where the table does not state a compression
`
`technique, but instead contains an asterisk, Hsu teaches using the content
`
`dependent compression technique associated with “the next highest [redundancy]
`
`metric.” Ex. 1005, 1106.
`
`
`
`
`
`
`- 21 -
`
`
`
`

`

`
`
` Case IPR2017-00179
`Patent No. 9,054,728
`
`
`
`
`
`
`Id., 1107, Table 1.
`
`There is no need for any further factual development on these issues because
`
`Petitioner explicitly acknowledges that Hsu’s redundancy metrics are “parameters
`
`of the data block,” and that Hsu’s encoders are always “content dependent.” Pet.,
`
`22 (Hsu’s encoders are ‘content dependent’ because an appropriate encoder is
`
`chosen based in part on one or more attributes of the data bloc