`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`TERADATA OPERATIONS, INC.,
`Petitioner,
`
`v.
`
`REALTIME DATA LLC,
`Patent Owner.
`____________________
`
`Case IPR2017-00806
`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
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`IPR2017-00806
`Patent No. 7,161,506
`
`
`TABLE OF CONTENTS
`
`Introduction ...................................................................................................... 1
`I.
`Background of the ’506 patent and challenged claims .................................... 3
`II.
`III. Petitioner’s proposed claim construction is irrelevant to the contested
`issues. ............................................................................................................... 5
`IV. 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. ................................................................................................ 6
`A.
`Franaszek only uses the alleged “single data compression encoder”
`when the data type is not identified. ...................................................... 6
`B. Hsu teaches a data analysis technique that always identifies the data
`type. .....................................................................................................10
`The proposed combination of Franaszek with Hsu would not include
`the claimed single data compression encoder. ....................................14
`Petitioner’s alternative combination with Sebastian does not remedy
`the defect in the combination of Franszek and Hsu. ...........................16
`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
`VI. Petitioner’s combination theory with respect to Claim 105 must fail
`because the combination would never perform step 105[d2]........................20
`VII. 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. ..........................................................................................24
`VIII. Conclusion .....................................................................................................31
`
`
`C.
`
`D.
`
`V.
`
`
`
`
`
`
`- i -
`
`
`
`

`

`
`
`
`
`IPR2017-00806
`Patent No. 7,161,506
`
`EXHIBIT LIST
`
`
`Exhibit No.
`
`Description
`
`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).
`
`
`
`
`
`2001
`
`2002
`
`- ii -
`
`
`
`
`
`
`
`
`

`

`I.
`
`Introduction
`Petitioner challenges Claims 104 and 105 of the ’506 patent. To attempt to
`
`
`
`IPR2017-00806
`Patent No. 7,161,506
`
`
`carry its burden of demonstrating a reasonable likelihood of prevailing as to
`
`unpatentability of those claims, Petitioner almost entirely regurgitates the same
`
`theories, expert testimony, and arguments presented by different petitioners in an
`
`earlier, pending petition. See IPR2017-00176. As in that earlier proceeding, the
`
`petition here attempts to puzzle together isolated pieces from different references
`
`in a transparent attempt to re-create the challenged claims through hindsight. That
`
`approach fails to demonstrate that Claims 104 and 105 were obvious. Instead, it
`
`gives 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 that it has urged
`
`modifying Franaszek based on the teachings of Hsu. If Hsu’s content analysis
`
`techniques, which always identify a data type, are employed in Franaszek’s data
`
`compression method, as proposed in the Petition, then Petitioner’s proposed
`
`combination will always have data type information available and thus will never
`
`
`
`
`
`
`- 1 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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
`
`combination for purposes of other elements. Nor does Petitioner’s proposed
`
`combination with Sebastian overcome the fact 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 modifying
`
`Franaszek with 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
`
`
`
`- 2 -
`
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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.
`
`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-00808.
`
`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;
`
`
`
`
`
`
`
`- 3 -
`
`
`
`

`

`
`
`
`
`IPR2017-00806
`Patent No. 7,161,506
`[b] performing content dependent data compression with a content
`dependent data compression encoder if a data type of the data block is
`identified; and
`
`[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,
`
`
`
`
`
`
`
`- 4 -
`
`
`
`

`

`
`
`
`
`IPR2017-00806
`Patent No. 7,161,506
`[d2] otherwise compressing said data block with a default data
`compression encoder, and
`
`[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 claim construction
`contested issues.
`Petitioner has proposed a claim construction for the term “data stream” as
`
`is
`
`irrelevant to the
`
`used in independent Claims 104 and 105. See Pet. at 11-12. Specifically, Petitioner
`
`urges that the term should be construed as “one or more data blocks.” Id.
`
`The Board does not construe claim terms unnecessary to resolve the
`
`controversy. Shenzhen Liown Electronics Co. v. Disney Enterprises, Inc.,
`
`IPR2015-01656, Paper 7 at 10 (Feb. 8, 2016) (citing Vivid Techs., Inc. v. Am. Sci.
`
`& Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999)).
`
`For purposes of this Patent Owner Preliminary Response, “data stream” does
`
`not require an express construction. This Response assumes arguendo that
`
`Petitioner’s proposed construction is correct, and nonetheless demonstrates that the
`
`cited references do not teach all of the limitations of the challenged claims.
`
`Accordingly, the Board should not engage in the needless exercise to construe any
`
`terms at this time.
`
`
`
`
`
`
`- 5 -
`
`
`
`

`

`
`
`IPR2017-00806
`Patent No. 7,161,506
`IV. 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” (i.e., limitation
`
`104[b]) or a “single data compression encoder[] if a data type of the data block is
`
`not identified” (i.e., limitation 104[c]). To meet the claimed “analysis” limitations,
`
`Petitioner proposes a combination of Franaszek and Hsu. See Pet. at 33-38. 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
`
`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
`
`
`
`
`
`
`- 6 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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. at 3:25-28, 4:14-17.
`
`To accomplish that objective, Franaszek discloses a data compressor 220
`
`that compresses data blocks as they are transferred to the second memory, which is
`
`illustrated in annotated Fig. 2 and reproduced below. Id. at 4:25-27.
`
`
`
`Franaszek explains (and shows in Fig. 2) 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. at 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. Id. at 5:49-54.
`
`
`
`
`
`
`- 7 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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 annotated Fig. 4A, reproduced
`
`below. At step 401, Franaszek determines whether a data type of the data block is
`
`available. Id. at 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, then Franaszek
`
`proceeds to step 404 where the preselected list of compression methods is used. Id.
`
`at 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. at 5:53-54.
`
`
`
`
`
`
`- 8 -
`
`
`
`
`
`

`

`IPR2017-00806
`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
`
`claimed “content dependent data compression encoder if a data type of the data
`
`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 22 (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
`
`
`
`
`- 9 -
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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. at 28 (emphasis added).
`
`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.
`
`B. Hsu teaches a data analysis technique that always identifies the
`data type.
`The petition uses Hsu as a secondary reference and proposes to add data
`
`analysis techniques from Hsu to Franasek’s step 401. See Pet. at 33-34. The
`
`Petitioner proposes that combination because Franaszek alone simply teaches
`
`relying on provided data type descriptors. See Pet. at 37 (referring repeatedly to
`
`“Franaszek’s descriptors”). Franaszek alone therefore does not satisfy claim
`
`limitation 104[d], which requires identifying the data type without “analyzing
`
`based only on a descriptor.” See id.
`
`
`
`
`
`
`- 10 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`Hsu describes a system that avoids any content independent compression
`
`
`
`
`
`and that instead uses 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 pattern of data contained” in
`
`each 512 byte segment. Id. Hsu compares each 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. at 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.
`
`
`
`
`
`
`- 11 -
`
`
`
`

`

`
`
`
`
`IPR2017-00806
`Patent No. 7,161,506
`
`
`
`Ex. 1005 at 1107.
`
`Petitioner specifically proposes using Hsu’s analysis technique in the
`
`combination of Franaszek and Hsu. See Pet. at 33-34 (summarizing Hsu’s
`
`technique and then stating that it would have been “obvious to modify Franaszek
`
`by looking 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. See id. at 33 (“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. at
`
`
`
`
`- 12 -
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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
`
`expressly acknowledges, Hsu’s encoders are always “content dependent.” See Pet.
`
`at 23 (“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.
`
`
`
`
`
`
`- 13 -
`
`
`
`

`

`
`
`IPR2017-00806
`Patent No. 7,161,506
`C. The proposed combination of Franaszek with Hsu would not
`include the claimed single data compression encoder.
`Petitioner recognizes that Franaszek alone 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. See Pet. at 37 (referring
`
`repeatedly to “Franaszek’s descriptors”).
`
`Petitioner thus proposes importing the data analysis techniques described in
`
`Hsu into Franaszek’s data compression system. See id. at 33-38. Petitioner
`
`suggests that a POSA “would have found it obvious to modify Franaszek by
`
`looking to Hsu’s analysis of the content of the data payloads within each data
`
`block.” Id. at 35.1
`
`
`1 As discussed in more detail in Section VII below: Petitioner’s co-pending
`
`challenge to U.S. Patent 9,054,728 proposes a somewhat different combination,
`
`which suggests only using Hsu’s analysis techniques on data that had already been
`
`tagged with Franaszek’s optional data type descriptor. See Teradata v. Realtime
`
`Data LLC, IPR2017-00808, Paper 1 at 32-37. The Petition in this proceeding,
`
`however, nowhere suggests a similar bifurcation of Hsu’s use in Franaszek. Any
`
`
`
`
`
`
`
`- 14 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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
`
`explained in Section IV.A above, Petitioner acknowledges that Franaszek only
`
`uses the alleged “single data compression encoder” when it does not have data type
`
`information available. See Pet. at 28 (“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 IV.B, Petitioner notes
`
`Hsu’s express statement that it will always identify a data type for each block. See
`
`id. at 33 (“Hsu discloses a ‘system [that] determines the type [. . .] of each data
`
`block.” (quoting Ex. 1005 at 1102; second emphasis added)).
`
`
`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 VII below, the
`
`partial combination of Hsu with Franaszek is completely unsupported.
`
`
`
`
`
`
`- 15 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`There can thus be no dispute about the results of combining Hsu with
`
`
`
`
`
`Franaszek as the Petition proposes: 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 meet the claimed step of “performing data compression with a single data
`
`compression encoder, if a data type of the data block is not identified.”
`
`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. See Pet. at 31-33. 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
`
`
`
`
`
`
`- 16 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`from a default list of encoders as Franaszek does when data type is not
`
`
`
`
`
`identified[.]” Id. at 32 (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
`
`with a single data compression encoder, if a data type of the data block is not
`
`identified.”
`
`Accordingly, there cannot be a reasonable likelihood that the Petition will
`
`prevail as to claim 104.
`
`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.
`Petitioner suggests, with respect to claim limitation 104[c] only, that a
`
`POSA would have been motivated to modify Franaszek with Sebastian.
`
`
`
`- 17 -
`
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`Specifically, Petitioner proposes that when a data block in Franaszek does not have
`
`
`
`
`
`a data type provided, Franaszek 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. See Pet. at 31-32. Petitioner’s sole justification for that dramatic
`
`proposed modification is to “speed up” Franaszek. Id.
`
`Franaszek’s intended purpose, however, 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”?
`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).
`
`
`
`
`
`
`- 18 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`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. at 87:9-17 (emphasis added).
`
`Petitioner’s proposed modification would frustrate Franaszek’s ability to
`
`meet its intended purpose of achieving the highest compression ratio. Petitioner
`
`admits as much, acknowledging “that compression ratio may be sacrificed in favor
`
`of speed by substituting Sebastian’s generic encoder for Franaszek’s more complex
`
`sampling system.” Pet. at 32 (emphasis added). Yet Petitioner presents 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 of that system
`
`(compression ratio) in order to pursue an entirely different purpose (speed) than
`
`Franaszek’s intended purpose.
`
`To the contrary, the Federal Circuit has held as a matter of law that a POSA
`
`would not “pursue [a] combination” that 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); see also In re ICON Health & Fitness,
`
`Inc., 496 F.3d 1374 (Fed. Cir. 2007).
`
`Moreover, Petitioner’s proposed modification makes no sense in light of its
`
`reliance on Hsu. Specifically, Petitioner proposes to add Sebastian to a system that
`
`already includes a combination of Franaszek and Hsu. As demonstrated, Hsu will
`
`
`
`
`- 19 -
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`always identify a data type. See Section IV.B. A POSA would therefore have no
`
`
`
`
`
`reason to further modify the system with respect to situations where it does not
`
`have a data type because such situations would not occur. Petitioner simply ignores
`
`that fact, despite having acknowledged that “Hsu discloses a ‘system [that]
`
`determines the type and compressibility of each block,’” i.e., always identifies a
`
`data type. Pet. at 33 (quoting Ex. 1005 at 1102).
`
`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.
`
`VI. Petitioner’s combination theory with respect to Claim 105 must fail
`because the combination would never perform step 105[d2].
`Like Claim 104, Claim 105 expressly requires analyzing the data to identify
`
`one or more data types where the analysis is not “based only on a descriptor” (steps
`
`[b] and [e]). Claim 105 further recites, at step [d], “[1] if one or more encoders are
`
`associated to said type, compressing said data block with at least one of said one or
`
`more encoders, [2] otherwise compressing said data block with a default data
`
`compression encoder[.]” (numbering and emphasis added).
`
`Because Claim 105 requires analyzing beyond looking only at a descriptor,
`
`Petitioner’s theory again proposes adapting the descriptor-based system of
`
`Franaszek using the teachings from Hsu. See Pet. at 46. But the combination of
`
`
`
`
`
`
`- 20 -
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`Franaszek and Hsu ultimately defeats Petitioner’s obviousness theory because, as
`
`
`
`
`
`explained below, the ensuing system would always perform step 105[d1] and
`
`would never perform step 105[d2].
`
`In discussing its theory with respect to element [d1], 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 41
`
`(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. at 42. 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. at 43-44.
`
`The data analysis approach of Hsu, as discussed previously in Section IV.B,
`
`will always recognize a data type. Given that Petitioner proposes modifying the
`
`system of Franaszek to incorporate the data type analysis approach of Hsu, it is
`
`therefore necessarily true that the ensuing combination system will always
`
`recognize a data type of a data block, will always have one or more encoders
`
`associated with each data block, and will ultimately always compress that data
`
`
`
`- 21 -
`
`
`
`
`

`

`IPR2017-00806
`Patent No. 7,161,506
`block using those one or more associated encoders. See Sections IV.C.
`
`
`
`
`
`Accordingly, in the combined system of Franaszek and Hsu, step 105[d1] will
`
`always occur.
`
`That is fatal for Petitioner’s theory as to Claim