`
`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-00176
`Patent No. 7,161,506
`____________________
`
`
`
`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
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`Case IPR2017-00176
`Patent No. 7,161,506
`
`
`TABLE OF CONTENTS
`
`Introduction ...................................................................................................... 1
`
`Background of the ’506 patent and challenged claims .................................... 3
`
`I.
`
`II.
`
`III. Petitioner’s proposed combination does not teach or suggest
`“performing data compression with a single data compression
`encoder, if a data type of the data block is not identified,” as step
`104[c] requires. ................................................................................................ 5
`
`A.
`
`Franaszek only uses the alleged “single data compression encoder”
`when the data type is not identified. ...................................................... 5
`
`B. Hsu teaches a data analysis technique that always identifies the data
`type. .....................................................................................................10
`
`C.
`
`D.
`
`The proposed combination of Franaszek with Hsu would not include
`the claimed single data compression encoder. ....................................13
`
`Petitioner’s alternative combination with Sebastian does not remedy
`the defect in the combination of Franszek and Hsu. ...........................16
`
`IV. 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. .......................................................................17
`
`V.
`
`Petitioner’s combination theory with respect to Claim 105 must fail
`because the combination would never perform step 105[d2]........................19
`
`VI. Petitioner’s alternative combination of Franaszek and Hsu—described
`only in a co-pending petition—has not been proposed here and should
`not be considered. ..........................................................................................23
`
`VII. Conclusion .....................................................................................................30
`
`
`
`
`
`
`- i -
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`Exhibit No.
`
`EXHIBIT LIST
`
`
`
`Description
`
`2001
`
`2002
`
`Declaration of Kayvan B. Noroozi in Support of Motion for
`Admission Pro Hac Vice.
`Transcript from the Deposition of Charles D. Creusere taken in
`IPR2016-00972 and IPR2016-01002 (January 19, 2017).
`
`
`
`
`
`- ii -
`
`
`
`
`
`
`
`
`

`

`I.
`
`Introduction
`
`
`
`Case IPR2017-00176
`Patent No. 7,161,506
`
`
`Petitioner challenges Claims 104 and 105 of the ’506 patent. To attempt to
`
`carry its burden of demonstrating a reasonable likelihood of prevailing as to
`
`unpatentability, Petitioner relies on an obviousness theory that mixes and matches
`
`different references in a transparent attempt to re-create the challenged claims
`
`through hindsight. But Petitioner’s attempts give rise to fatal errors, as this Patent
`
`Owner Preliminary Response demonstrates.
`
`With respect to Claim 104, the result of Petitioner’s combination is a system
`
`that does not meet the “performing data compression with a single data
`
`compression encoder, if a data type of the data block is not identified” limitation of
`
`that claim. Specifically, Petitioner relies on Franaszek as purportedly teaching or
`
`suggesting that limitation. But Petitioner’s theory ignores the impact of its asserted
`
`combination between Franaszek and Hsu. If Hsu’s content analysis techniques,
`
`which always identify a data type, are employed in Franaszek’s data compression
`
`method, as Petitioner proposes in its Petition, then Petitioner’s proposed
`
`combination will always have data type information available and thus will never
`
`fail to identify a data type or perform compression with the “single data
`
`compression encoder” of Claim 104. Petitioner cannot rely on a combination
`
`between Hsu and Franaszek for some claim elements and then entirely ignore that
`
`
`
`
`
`
`- 1 -
`
`
`
`

`

`combination for purposes of other elements. Nor does Petitioner’s proposed
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`combination with Sebastian overcome the reality that its combination with Hsu
`
`obviates any possibility of unrecognized data types. Moreover, Petitioner’s
`
`combination with Sebastian lacks a motivation to combine as a matter of law
`
`because it would render Franaszek inoperable for its intended purpose.
`
`Accordingly, institution as to Claim 104 should be denied.
`
`With respect to Claim 105, Petitioner’s combination again fails because it
`
`would not perform step 105[d2], the “otherwise compressing said data block with a
`
`default data compression encoder” limitation of that claim. Petitioner’s theory as to
`
`Claim 105 again attempts to ignore the consequence of its reliance on Hsu. If a
`
`POSA would indeed combine Hsu with Franaszek, the result would be a system
`
`that always identifies a data type, and thus step 105[d2] of the Claim would never
`
`be performed. And as with Claim 104, Petitioner’s alternative reliance on
`
`Sebastian does not change the outcome. Petitioner’s combination theory regarding
`
`Sebastian relies on a mischaracterization of Sebastian’s actual teaching, and
`
`Sebastian does not actually teach the modification that Petitioner ascribes to it. In
`
`any case, Petitioner’s proposed modification still fails to meet Claim 105[d2]
`
`because it would simply create an encoder that is “associated” with all identified
`
`data types, and the “otherwise” limitation of step 105[d2] would still never be met.
`
`
`
`
`
`
`- 2 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`Thus as Patent Owner demonstrates in detail below, institution should be
`
`denied as to both of the challenged claims.
`
`II. Background of the ’506 patent and challenged claims
`Petitioner challenges independent claims 104 and 105 of the ’506 patent.
`
`The ’506 patent relates to data compression and, particularly, the use of “a
`
`combination of content dependent data compression and content independent data
`
`compression.” Ex. 1001 at 15:66-16:2. The ’506 patent shares a common
`
`specification with U.S. Patent 9,054,728, which Petitioner has also challenged in
`
`co-pending inter partes review IPR2017-00179.
`
`Independent claim 104 of the ’506 patent recites:
`
`[pre] A computer implemented method for compressing data,
`comprising:
`
`[a] analyzing data within a data block of an input data stream to
`identify one or more data types of the data block, the input data stream
`comprising a plurality of disparate data types;
`
`[b] performing content dependent data compression with a content
`dependent data compression encoder if a data type of the data block is
`identified; and
`
`
`
`
`
`
`
`- 3 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`[c] performing data compression with a single data compression
`encoder, if a data type of the data block is not identified,
`
`[d] wherein the analyzing of the data within the data block to identify
`one or more data types excludes analyzing based only on a descriptor
`that is indicative of the data type of the data within the data block.
`
`Independent claim 105 of the ’506 patent recites:
`
`[pre] A computer implemented method comprising:
`
`[a] receiving a data block in an uncompressed form, said data block
`being included in a data stream;
`
`[b] analyzing data within the data block to determine a type of said
`data block; and
`
`[c] compressing said data block to provide a compressed data block,
`
`[d1] wherein if one or more encoders are associated to said type,
`compressing said data block with at least one of said one or more
`encoders,
`
`[d2] otherwise compressing said data block with a default data
`compression encoder, and
`
`
`
`
`
`
`
`- 4 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`[e] wherein the analyzing of the data within the data block to identify
`one or more data types excludes analyzing based only on a descriptor
`that is indicative of the data type of the data within the data block.
`
`III. Petitioner’s proposed combination does not teach or suggest
`“performing data compression with a single data compression encoder,
`if a data type of the data block is not identified,” as step 104[c] requires.
`
`The challenged claims require identifying a data block type using analysis
`
`beyond looking only at a descriptor (i.e., limitations 104[a] and 104[d]) and then,
`
`based on the result of that analysis, applying either a “content dependent data
`
`compression encoder if a data type of the data block is identified” or a “single data
`
`compression encoder[] if a data type of the data block is not identified” (i.e.,
`
`limitation 104[b] and 104[c], respectively). To meet the claimed “analysis”
`
`limitations, Petitioner proposes a combination of Franaszek and Hsu. Pet. at 31-36.
`
`As Patent Owner shows below, that combination fails on its merits because the
`
`combination would always identify a data type of the data block and so the
`
`combination would never apply the alleged “single data compression encoder.”
`
`A.
`
`Franaszek only uses the alleged “single data compression
`encoder” when the data type is not identified.
`
`Petitioner relies on Franaszek as its primary reference. Franaszek describes a
`
`block-by-block system for “compressing . . . data using a plurality of data
`
`compression mechanisms.” Ex. 1004 at Abstract. As Franaszek explains, its
`
`
`
`
`
`
`- 5 -
`
`
`
`

`

` Case IPR2017-00176
`Patent No. 7,161,506
`
`objective is “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,” which “increase the number of data blocks that can be stored in
`
`the second memory 20 given a fixed second memory size.” Id., 3:25-28, 4:14-17.
`
`To accomplish this objective, Franaszek discloses and illustrates in Figure 2
`
`(annotated below) a data compressor 220 that compresses data blocks as they are
`
`transferred to the second memory. Id., 4:25-27.
`
`
`
`Franaszek explains (and shows in Figure 2 above) that “the uncompressed
`
`data 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
`
`
`
`
`
`
`- 6 -
`
`
`
`

`

`type information 205 is available, Franaszek uses a preselected list of compression
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`methods based on type information availability for a data block. Id., 5:49-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. Id.
`
`Franaszek’s binary decision is illustrated in Figure 4A, annotated below. At
`
`step 401, Franaszek determines whether a data type of the data block is available.
`
`Id., 5:49-50 (explaining that step 401 determines whether “a data type (e.g., text,
`
`image, etc.) . . . is available”). If a data type is available, Franaszek proceeds to
`
`step 404 where the preselected list of compression methods is used. Id., 5:50-53.
`
`Only if “no data type is available” at step 401 does Franaszek proceed to step 407
`
`where the default list of compression methods is used. Id., 5:53-54.
`
`
`
`
`
`
`- 7 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`
`
`
`
`Petitioner alleges that Franaszek’s step of determining whether a data type is
`
`available (i.e., Franaszek’s step 401) meets the claimed “analyzing data within a
`
`data block of an input data stream to identify one or more data types of the data
`
`block” (i.e., limitation 104[a]). See, e.g., Ex. 1002 at ¶ 91 (stating that “[a]s
`
`illustrated in Figure 4 of Franaszek annotated below, the data type of each block is
`
`identified, if available, by analyzing the type information 205 of each block 210”
`
`and annotating Figure 4A to draw a square around step 401).
`
`The Petition alleges that Franaszek’s use of a preselected list of compression
`
`methods when the data type is available (i.e., Franaszek’s step 404) meets the
`
`
`
`- 8 -
`
`
`
`
`

`

`claimed “content dependent data compression encoder if a data type of the data
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`block is identified” (i.e., limitation 104[b]):
`
`In the situation in which the data type is available, Franaszek’s system
`includes one or more encoders identified on the compression method
`list (CML) associated with the data block type that compress a data
`block “B.” The data type associated with the block, e.g., using the
`“data type” “entry in the type field 205,” gives insight to the
`compression system about the type of data that is in the block, making
`the encoder ultimately used to compress the data block “content
`dependent[.]”
`Pet. at 21 (internal citations omitted).
`
`
`
`Similarly, the Petition expressly equates Franaszek’s use of a default list of
`
`compression methods when the data type is not available (i.e., Franaszek’s step
`
`407) with the claimed “single data compression encoder[] if a data type of the data
`
`block is not identified” (i.e., limitation 104[c]):
`
`this [“single data compression encoder”]
`Franaszek discloses
`limitation because it uses 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., 26 (emphasis added).
`
`
`
`
`
`
`- 9 -
`
`
`
`

`

` Case IPR2017-00176
`Patent No. 7,161,506
`
`Accordingly, as shown in Franaszek and discussed in the Petition, Franaszek
`
`
`
`
`
`
`
`only uses the alleged “single data compression encoder” of its step 407 when data
`
`type information is not identified at step 401. The Petitioner, however, proposes
`
`modifying Franaszek’s data compression system by adding Hsu’s analysis
`
`techniques to Franasek’s step 401. As will be discussed below, Hsu always
`
`identifies a data type, and therefore the analysis at step 401 will always result in a
`
`data type being available. Thus, the proposed combination of Franaszek with Hsu
`
`will always proceed to the alleged “content dependent data compression” (i.e.
`
`Franaszek’s step 404) and will never fail to identify the data type and use the
`
`alleged “single data compression encoder” (i.e., Franaszek’s step 407).
`
`B. Hsu teaches a data analysis technique that always identifies the
`data type.
`
`The petition uses Hsu as a secondary reference. Hsu categorically teaches
`
`away from using any content independent compression and instead champions the
`
`merits of an entirely content-dependent approach.
`
`Hsu teaches the identification of a “block type” (i.e., data type) for each data
`
`block using a “new-file” procedure. Ex. 1005 at 1103-1104. Hsu’s “new-file”
`
`procedure—a variant of the Unix “file” command—analyzes 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
`
`
`
`
`
`
`- 10 -
`
`
`
`

`

`pattern of data contained” in each 512 byte segment. Id. Hsu compares each
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`segment to a collection of known data patterns from Unix and other operating
`
`systems. Id. Correlating with known patterns, Hsu identifies the data type of the
`
`block as one of the ten possible classifications shown in Table I, reproduced below.
`
`Id., 1103, 1107. In the event that two of the tested segments point to one data type
`
`and the third to another, Hsu uses “majority vote” to reconcile the discrepancy. Id.
`
`Where each of the three segments points to different data types, Hsu uses “the first
`
`data type detected.” Id.
`
`Ex. 1005 at 1107.
`
`Petitioner specifically proposes using Hsu’s analysis technique in the
`
`combination of Franaszek and Hsu. Pet. at 32-33 (summarizing Hsu’s technique
`
`
`
`
`
`
`
`
`- 11 -
`
`
`
`

`

`and then stating that it would have been “obvious to modify Franaszek by looking
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`to Hsu’s analysis of the content of the data payloads within each data block”).
`
`Notably, as Petitioner acknowledges, Hsu expressly states that it will always
`
`identify a data type for each block. Id., 32 (“Hsu discloses a ‘system [that]
`
`determines the type [. . .] of each data block.’”) (quoting Hsu at 1102; second
`
`emphasis added). It is indisputable that a system that determines the type of each
`
`data block necessarily always determines a data type for every data block.
`
`Once Hsu has detected the data type of the block based on its data pattern
`
`analysis approach, and calculated three other redundancy metric for the data (id.,
`
`11-13), Hsu will 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). 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 at 1106.
`
`Hsu thus teaches a data analysis technique that always identifies a data type
`
`and the data type’s associated content dependent encoder. Indeed, as Petitioner
`
`
`
`
`
`
`- 12 -
`
`
`
`

`

`expressly acknowledges, Hsu’s encoders are always “content dependent.” Pet. at
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`22 (“Hsu’s encoders are ‘content dependent’ because an appropriate encoder is
`
`chosen based in part on the data type of the data block.”).
`
`
`
`Accordingly, Hsu neither teaches nor suggests a scenario where “a data type
`
`of the data block is not identified,” as Claim 104[c] requires, nor does it ever teach
`
`or suggest “performing data compression with a single data compression encoder,”
`
`as Claim 104[c] also requires.
`
`C. The proposed combination of Franaszek with Hsu would not
`include the claimed single data compression encoder.
`Petitioner recognizes that Franaszek does not satisfy, inter alia, the claim
`
`requirement of identifying a data type using analysis other than looking only at a
`
`descriptor (i.e., limitation 104[d]). As Petitioner acknowledges, Franaszek analyzes
`
`only its optional data type tags, and those data type tags constitute the descriptors
`
`expressly excluded by the claim language. Pet. at 35 (referring repeatedly to
`
`“Franaszek’s descriptors”).
`
`Petitioner thus proposes importing the data analysis techniques described in
`
`Hsu into Franaszek’s data compression system. Id., 31-36. Petitioner suggests that
`
`
`
`
`
`
`- 13 -
`
`
`
`

`

`a POSA “would have found it obvious to modify Franaszek by looking to Hsu’s
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`analysis of the content of the data payloads within each data block.” Id., 33.1
`
`But Petitioner’s attempt to add Hsu’s data analysis techniques to Franaszek,
`
`to meet the analysis limitations, results in a combination that does not teach or
`
`suggest the claimed “performing data compression with a single data compression
`
`encoder, if a data type of the data block is not identified” (i.e., step 104[c]). As
`
`
`1 As discussed in more detail in Section VI below: Petitioner’s co-pending
`
`challenge to U.S. Patent 9,054,728 proposed a somewhat different combination,
`
`which suggested only using Hsu’s analysis techniques on data that had already
`
`been tagged with Franaszek’s optional data type descriptor. See Dell Inc. v.
`
`Realtime Data LLC, IPR2017-00179, Paper 1 at 34-39. The Petition in this
`
`proceeding, however, nowhere suggests a similar bifurcation of Hsu’s use in
`
`Franaszek. Any attempt by Petitioner to later urge in this proceeding the partial,
`
`bifurcated combination of Hsu with Franaszek presented in the co-pending
`
`proceeding would be improper—as a matter of law, the review is limited to the
`
`grounds set out in the Petition. And in any event, for the reasons discussed in
`
`Section VI below, the partial combination of Hsu with Franaszek is completely
`
`unsupported.
`
`
`
`
`
`
`- 14 -
`
`
`
`

`

` Case IPR2017-00176
`Patent No. 7,161,506
`
`explained in Section III.A above, Petitioner acknowledges that Franaszek only uses
`
`
`
`
`
`the alleged “single data compression encoder” when it does not have data type
`
`information available. Pet. at 26 (“Franaszek discloses this [‘single data
`
`compression encoder’] limitation because it uses one encoder selected from a
`
`‘default’ list of encoders when data type information is not available.”) (emphasis
`
`added). And as further explained in Section III.B, Petitioner notes Hsu’s express
`
`statement that it will always identify a data type for each block. Id., 32 (“Hsu
`
`discloses a ‘system [that] determines the type [. . .] of each data block.”) (quoting
`
`Ex. 1005 at 1102; second emphasis added). Accordingly, there can be no dispute:
`
`if Hsu’s content analysis techniques, which always identify a data type, are
`
`employed in Franaszek’s data compression method, which only uses the alleged
`
`“single data compression encoder” when data type information is not available,
`
`then Petitioner’s proposed combination will always have data type information
`
`available and thus will never fail to identify a data type and use the alleged “single
`
`data compression encoder” of Franaszek’s step 407.
`
`Accordingly, Petitioner’s combination of Franaszek and Hsu would yield a
`
`system that would always identify the data type of the data block and therefore
`
`never perform the claimed step of “performing data compression with a single data
`
`compression encoder, if a data type of the data block is not identified.”
`
`
`
`
`
`
`- 15 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`D.
`
`Petitioner’s alternative combination with Sebastian does not
`remedy the defect in the combination of Franszek and Hsu.
`
`Petitioner, while discussing step 104[c]’s “single data compression
`
`encoder,” suggests that alternatively Sebastian may be combined with Franaszek to
`
`meet that limitation. Pet. at 29-31. Petitioner points to Sebastian’s teachings
`
`regarding a single “generic filter,” and suggests that it could be used as an
`
`alternative to “undertaking the time-consuming effort of sampling the data block
`
`and compressing samples of that data block to identify the best default encoder
`
`from a default list of encoders as Franaszek does when data type is not
`
`identified[.]” Id., 30 (emphasis added).
`
`The Petition thus expressly states that the proposed combination of
`
`Sebastian with Franaszek still only uses the alleged “single data compression
`
`encoder”—whether that be Franaszek’s default list of encoders or Sebastian’s
`
`generic filter—when the “data type is not identified.” As discussed above,
`
`however, a data type will always be identified if Hsu’s analysis techniques are
`
`included in Franaszek’s data compression method. And thus Petitioner’s proposed
`
`substitution of Sebastian’s generic filter for Franaszek’s default list of encoders
`
`does not affect the combination’s fatal defect. If Hsu’s analysis techniques are
`
`incorporated in Franaszek’s method, the system will always have data type
`
`information and will never meet the required step of “performing data compression
`
`
`
`
`
`
`- 16 -
`
`
`
`

`

`with a single data compression encoder, if a data type of the data block is not
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`identified.”
`
`Accordingly, there cannot be a reasonable likelihood that the Petition will
`
`prevail as to claim 104.
`
`IV. 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.
`
`Petitioner states, only with respect to claim 104[c], that a POSA would have
`
`been motivated to modify Franaszek such that, when Franaszek did not have a data
`
`type provided to it, it would no longer undertake its testing and sampling approach
`
`to select the “best” compression technique from among the default list 407, but
`
`instead would simply use Sebastian’s single, “generic encoder” in all such
`
`instances. Pet. at 29-30. Petitioner’s sole justification for that dramatic proposed
`
`modification is to “speed up” Franaszek. Id.
`
`Franaszek’s intended purpose is to achieve the highest possible compression
`
`ratio allowed by its available encoders, so long as compression would exceed a 30
`
`percent minimum threshold. Dr. Creusere has previously so admitted in a related
`
`proceeding.
`
`(BY MR. NOROOZI) Does any particular specific criterion
`Q.
`come to mind when I ask about “appropriately optimized”?
`
`
`
`
`
`
`- 17 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`A. Well, if we -- if we go back to the -- if we go to the Franaszek
`patent, it’s clear that Franaszek’s was, for the most part, trying to
`achieve a high degree of compression, so trying to maximize storage.
`So I guess if that is appropriate, if -- I mean, I think it might be
`appropriate, perhaps. But certainly it appears to be a major goal of
`Franaszek is to maximize the amount of data that could be stored
`in a storage media.
`Ex. 2002 at 118:15-25 (emphasis added).
`
`And as Dr. Creusere has also previously admitted, “Franaszek does not
`
`consider the speed of the compression algorithm in its decision to – on whether
`
`or not to choose that compression algorithm.” Id., 87:9-17 (emphasis added).
`
`Petitioner’s proposed modification would certainly impact Franaszek’s
`
`ability to meet its intended purpose of achieving the highest compression ratio.
`
`There is no evidence to the contrary or any reason to believe otherwise. Indeed,
`
`Petitioner implicitly admits as much. Pet. at 30-31 (“A POSITA would also have
`
`recognized the possibility of design trade-offs, namely, that compression ratio may
`
`be sacrificed in favor of speed by substituting Sebastian’s generic encoder for
`
`Franaszek’s more complex sampling system.”) (emphasis added). And Petitioner
`
`has no evidence as to why a POSA, having selected to work with Franaszek’s
`
`speed-agnostic system, would be motivated to fundamentally gut a central feature
`
`
`
`
`
`
`- 18 -
`
`
`
`

`

`of that system to pursue an entirely different purpose (speed) at the expense of
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`Franaszek’s intended purpose.
`
`The Federal Circuit has held as a matter of law that a POSA would not be
`
`motivated to combine references when the combination would render the primary
`
`reference inoperable for its intended purpose. Plas-Pak Indus., Inc. v. Sulzer
`
`Mixpac AG, 600 F. App’x 755, 759–60 (Fed. Cir. 2015); In re ICON Health &
`
`Fitness, Inc., 496 F.3d 1374 (Fed. Cir. 2007).
`
`Accordingly, the Petition fails for the additional reason that a POSA would
`
`not be motivated to modify Franaszek and combine it with Sebastian in the manner
`
`proposed by the Petition, and there is no evidence to the contrary.
`
`V.
`
`Petitioner’s combination theory with respect to Claim 105 must fail
`because the combination would never perform step 105[d2].
`
`With respect to Claim 105, Petitioner’s theory again rests on a combination
`
`of Franaszek and Hsu. Pet. at 43-44. Petitioner relies on Hsu because Claim 105,
`
`like Claim 104, expressly requires analyzing the data to identify one or more data
`
`types where the analysis is not based only on a descriptor (step [e]). But the
`
`combination of Franaszek and Hsu ultimately defeats Petitioner’s obviousness
`
`theory because the ensuing system would always perform step 105[d1] and would
`
`never perform step 105[d2], as Patent Owner shows in this section.
`
`
`
`
`
`
`- 19 -
`
`
`
`

`

` Case IPR2017-00176
`Patent No. 7,161,506
`
`Step 105[d1] recites: “wherein if one or more encoders are associated to said
`
`
`
`
`
`type, compressing said data block with at least one of said one or more encoders.”
`
`In discussing its theory with respect to this element, Petitioner asserts that when
`
`Franaszek has a data type, it will use a compression Method List (CML) of
`
`compression methods that has been “preselected for that data type.” Pet. at 39
`
`(emphasis added). In such circumstances, Petitioner asserts that Franaszek meets
`
`step 105[d1], stating: “in the event that a data type is present, ‘one or more
`
`encoders’ are associated with that data type and are used to select ‘at least one of
`
`said one or more encoders,’ which are then used to compress the entire data
`
`block.” Id., 40. Thus as Petitioner recognizes, Franaszek’s teaching is that, so long
`
`as it has a data type, there will always be “one or more encoders [ ] associated to
`
`said type” and that the data block will always be compressed “with at least one of
`
`said one or more encoders.” Id., 41-42.
`
`Because Petitioner relies on a combination of Franaszek and Hsu for its
`
`theory with respect to Claim 105, it is necessarily true that the ensuing system will
`
`always recognize a data type, will thus always have one or more encoders
`
`associated with each data block, and will ultimately always compress that data
`
`block using those one or more associated encoders. See Sections III.B & C.
`
`
`
`
`
`
`- 20 -
`
`
`
`

`

`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`That is fatal for Petitioner’s theory as to Claim 105, because step 105[d2]
`
`provides: “otherwise compressing said data block with a default data compression
`
`encoder.” By “otherwise,” step [d2] clearly refers to a scenario where step [d1]
`
`does not occur. Petitioner has only two theories as to why it purports step 105[d2]
`
`would be performed under its proposed combination. Both fail.
`
`First, Petitioner argues that step [d2] could occur because Franaszek
`
`expressly contemplates a scenario where the data type information is not provided
`
`in the type field. Pet. at 40-41. But that assertion deliberately ignores Hsu.
`
`Petitioner cannot rely on Hsu when it is convenient for some limitations and then
`
`entirely ignore the combination when it is inconvenient for other limitations. If a
`
`POSA would indeed combine Hsu with Franaszek, the result would be a system
`
`that always identifies a data type. Section III.B & C. Accordingly, step 407 of
`
`Franaszek would never be used or performed, and thus step 105[d2] of the Claim
`
`would never be performed. Since Petitioner relies on Hsu for step 105[e],
`
`Petitioner is also bound by the consequences for purposes of step 105[d2]. Thus, to
`
`meet the “otherwise” limitation of Claim 105, Petitioner cannot ignore Hsu or rely
`
`on aspects of Franaszek that would never be performed in light of Hsu.
`
`Second, Petitioner asserts that a POSA could have modified Franaszek such
`
`that—when “a data type has been included in the ‘type’ field, but is not associated
`
`
`
`
`
`
`- 21 -
`
`
`
`

`

`with a particular encoder”—Franaszek would use a default encoder, as purportedly
`
`
`
`
`
` Case IPR2017-00176
`Patent No. 7,161,506
`
`
`taught by Sebastian. Pet. at 42-43. That assertion also fails. As a threshold matter,
`
`Petitioner’s characterization of Sebastian’s teaching is expressly refuted by
`
`Sebastian’s actual teaching. Petitioner claims that “Sebastian makes a decision
`
`about whether a ‘filter’ is associated with the data type, and if not, it compresses
`
`the data using the generic filter.” Id., 42 (emphasis added). But in fact, Sebastian’s
`
`teaching is that there is always an encoder associated with the data type, but that
`
`encoder may not always be installed, which is why a default filter exists. Ex. 1030
`
`at 1:55-60, 4:9-15 (explaining that the generic filter is used when a filter matching
`
`the format of the data is not installed).
`
`Accordingly, Sebastian’s teachings could not have motivated a POSA to use
`
`a generic encoder where Franaszek had a data type that is not recognized by its
`
`system, as Petitioner contends, because